Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Vanilla JavaScript

guseyn.com

Post reply on HN
Print view View original

121–130 of 176 posts

Re: Why Vanilla JavaScript

#121

Post by austin-cheney »

root_axis wrote: post #119
austin-cheney wrote: post #110

Earlier quoted context omitted.

I am aware and it’s not what I said.

You literally said "this even includes front-end code for the browser". So what exactly are you referring to here?

I write all my application code in TypeScript, even if it is for the browser. I then import all that code into Node regardless of whether it will execute in Node. All code that will not execute in Node needs to be wrapped in a function for safety, because global references like "document" or "window" will not work in Node.

Re: Why Vanilla JavaScript

#122

Post by FpUser »

wett wrote: post #14
FpUser wrote: post #6

Earlier quoted context omitted.

>"frameworks scale and provide structure" Web Components and vanilla JS scale just as well. Been doing this for ages.

Asking in good faith: how is your experience working with vanilla JS on a team? While I’m not the biggest fan of Nextjs for my own solo projects, I really enjoy using it at work. Leaning into the opinionation it provides/encourages keeps my team from bickering too much about how to structure things. It’s really nice to say “this is the idiomatic way of doing it according to the docs” and for everyone to nod their hea…

Team or not makes no difference.

Front ends works like this - main app split into few smaller ones callable from a menu. Each sub-app is dynamically imported module (no need for building, code mutilation, direct dependency etc). Sub-apps in turn can consist from the other sub apps. Each can be worked on completely independently by different team member with virtually no interaction needed. Apps can share some approved libraries (like for graphics etc) and HTML components responsible for particular bits and pieces. Components and libs go into common pool. Once component is in a pool modifying behavior is punishable by death. Only internals. If change is breaking then simply new version is developed and deployed.

The whole thing is super scalable organization wise (nearly everything is decoupled) and resource wise as well since everything is loaded strictly on on need basis.

Re: Why Vanilla JavaScript

#123

Post by dreamcompiler »

React was invented to make multiple DOM changes quicker and set up DOM event dependencies declaratively. Fine. Some websites benefit from this. Most do not.

Since React's invention, it has gotten more bloated, browsers have made living DOM changes a lot faster, and the vast majority of websites still only change one or two DOM objects in response to events. Those could easily be handled much faster with plain old AJAX. The latency overhead React adds to a website is quite noticeable and unnecessary. Airbnb.com for example would be a great deal more pleasant to use if they would ditch React.

The fact that React had to reinvent server-side rendering is all you need to know to see that React has jumped the shark.

Re: Why Vanilla JavaScript

#124

Post by [deleted] »

austin-cheney wrote: post #121
root_axis wrote: post #119

Earlier quoted context omitted.

You literally said "this even includes front-end code for the browser". So what exactly are you referring to here?

I write all my application code in TypeScript, even if it is for the browser. I then import all that code into Node regardless of whether it will execute in Node. All code that will not execute in Node needs to be wrapped in a function for safety, because global references like "document" or "window" will not work in Node.

[deleted]

Re: Why Vanilla JavaScript

#125

Post by root_axis »

austin-cheney wrote: post #121
root_axis wrote: post #119

Earlier quoted context omitted.

You literally said "this even includes front-end code for the browser". So what exactly are you referring to here?

I write all my application code in TypeScript, even if it is for the browser. I then import all that code into Node regardless of whether it will execute in Node. All code that will not execute in Node needs to be wrapped in a function for safety, because global references like "document" or "window" will not work in Node.

You write all your code in TS - great.

You run node with the TS support - great.

That doesn't explain how your front-end TS code is transformed into JS. You seem to be suggesting that node does it automatically, but it doesn't. The explanation of your setup isn't adding up.

Re: Why Vanilla JavaScript

#126

Post by [deleted] »

simondotau wrote: post #97
JodieBenitez wrote: post #86

> Multi-page applications are slow to load and navigate. A bit tired to see this... No it's not. We do this all the time. It's as simple as using proper HTTP headers for your css/js/pictures/whatever. You can even have smooth page transitions now.

A browser can load a singular page within tens of milliseconds of receiving the packets. It literally cannot get faster. Single page applications only feel faster because there's no risk of white flashes. Multi-page applications are slow if you load in 20 libraries from 10 different CDNs, a page tracking system, a click tracking system, a "performance metrics" system, a chat bot overlay, an advertising platform, all…

[deleted]

Re: Why Vanilla JavaScript

#127

Post by interf4ce »

JodieBenitez wrote: post #86

> Multi-page applications are slow to load and navigate. A bit tired to see this... No it's not. We do this all the time. It's as simple as using proper HTTP headers for your css/js/pictures/whatever. You can even have smooth page transitions now.

100%

The author is reinforcing the false dichotomy between using front end frameworks and hand-rolled JS, as if rendering data from JSON APIs is the only way to display information from the server.

Almost as an aside, he says

> Server Side Rendering is also no better, because while they can do certain things in more straightforward way, they break browser behaviour [...]

but he provides no examples or supporting evidence, so it's difficult to know what browser behaviour he's referencing. "SSR" is just how the web has worked since the beginning and it works very well. Maybe he's specifically talking about SSR as provided by Next? I've never used it, so I'm not sure what browser behaviour it might be breaking.

Re: Why Vanilla JavaScript

#128

Post by austin-cheney »

root_axis wrote: post #125
austin-cheney wrote: post #121

Earlier quoted context omitted.

I write all my application code in TypeScript, even if it is for the browser. I then import all that code into Node regardless of whether it will execute in Node. All code that will not execute in Node needs to be wrapped in a function for safety, because global references like "document" or "window" will not work in Node.

You write all your code in TS - great. You run node with the TS support - great. That doesn't explain how your front-end TS code is transformed into JS. You seem to be suggesting that node does it automatically, but it doesn't. The explanation of your setup isn't adding up.

> That doesn't explain how your front-end TS code is transformed into JS.

Node will do that at run time. Its automatic. Functions do not have to execute to receive this benefit. They just have to be imported. Ensure you are using a very recent version of Node.

Re: Why Vanilla JavaScript

#129

Post by Rohansi »

Kon5ole wrote: post #95
onion2k wrote: post #49

So many more problems solved… Those problems aren't 'solved'. The author has an implementation of a solution. It's one that they think is good, which is ace and I'm happy for him, but if he ever introduces a second developer to his project those 'solved' problems will become a point of friction. They'll go from 'solved' to 'solved, but in the wrong way' or 'solved, but not for this edge case', or 'solved, but why is…

>if he ever introduces a second developer to his project those 'solved' problems will become a point of friction. They'll go from 'solved' to 'solved, but in the wrong way' or 'solved, but not for this edge case', or 'solved, but why is the code so verbose?' I agree with the problems you list, but I don't think a framework solves them. The same complaints can be made by the second developer because the first develope…

> The same complaints can be made by the second developer because the first developer chose the "wrong" framework.

Exactly this. There's so much fragmentation within the browser ecosystem that there is no guarantee your second developer will be comfortable/familiar with what the first developer chose. Even if you went with React you could be using state management they don't understand, a styling system they don't understand, etc... Even if you choose the most popular everything at the start of the project there is a lot of churn where things eventually fall out of favour.

I'd also be skeptical of web developers who work with React but aren't familiar with vanilla JavaScript. It's probably a good indicator that they aren't the best candidate but we can't all be picky.

Re: Why Vanilla JavaScript

#130

Post by interf4ce »

ChadNauseam wrote: post #116
bfjvibybd6cuvu6 wrote: post #93

Earlier quoted context omitted.

My sites with htmx have less latency for ui interactions and page transitions work like every page on the internet. As for offline, yeah, my Internet web page doesn't work offline. Shocker.

> As for offline, yeah, my Internet web page doesn't work offline. That's really too bad honestly. What about your users who want to use your site when they're offline? Sympathy with those users is why I made sure that my site works well when offline.

Whether this is actually beneficial (let alone possible) depends heavily on the type of site.

Web apps that are valuable to use offline also tend to be the kind that really do warrant client-side logic and rendering (a spreadsheet web app is a classic example).

If the site's focus is providing information (e.g. Wikipedia), then working offline really just means loading all the backing data into the browser, which quickly becomes impossible.

I'm sure there are cases where offline availability is a huge plus (your site might be a good example), I just don't think it's universally applicable.

Post reply on HN