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

91–100 of 176 posts

Re: Why Vanilla JavaScript

#91

Post by rimliu »

ciconia wrote: post #84
pikeangler wrote: post #83

I use Svelte 5 (without SvelteKit) for my SPA's, after doing my first SPA in vanilla JS. Then I discovered Svelte. Svelte is very close to the platform and still solves a lot of problems: for reactivity, modularity and CSS cascading (and in version 5 it is not too "magical"). A lot of the critique of frameworks in this article does not apply to Svelte.

How so? Svelte provides a bunch of (very nice, no doubt) abstractions for building web UIs, and there's a build step. In that regard, Svelte is no different from other JS frameworks.

The hint how Svelte is different is in the word "different".

Re: Why Vanilla JavaScript

#92

Post by rerdavies »

doginasuit wrote: post #13

This hit so close to home. For the last eight months I've been building a web app without any major framework like react or angular. Angular taught me a lot of important lessons about best practices for structuring UI. But eventually you run into boilerplate that doesn't jive with what you want to do. The author frames this as artificial complexity, and that's the best framing I've seen. The browser has a particular…

Claude 4.6+ seem to work fine with my React/typescript apps.

Re: Why Vanilla JavaScript

#93

Post by bfjvibybd6cuvu6 »

ChadNauseam wrote: post #75
didip wrote: post #57

If we are going to rant like this… i’d say even most of JS is unnecessary. Just use server side template rendering with HTMX. LLM can see server side request flow better anyway.

As a user I don't really appreciate sites that do this as they tend to have worse latency for UI interactions and less pleasant page transitions. And of course, they are unusable offline

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.

Re: Why Vanilla JavaScript

#94

Post by megous »

prokopton wrote: post #61
lezojeda wrote: post #27

Earlier quoted context omitted.

And he ended up... creating frameworks himself. I fail to see the whole point of the article tbh. It's a rant against JS frameworks/libraries and the frontend in general all to end up admitting he did the same?

I checked out before getting to that. He even wrote his own HTML variant called EHTML. https://e-html.org Well played. You got me to visit your version of the thing you complained about. :clapping-emoji:

It's not a html variant. It's just a bunch of web components. Takes like 30s of looking at actual source code to figure that out.

Re: Why Vanilla JavaScript

#95

Post by Kon5ole »

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 developer chose the "wrong" framework. Solved the wrong way, not covering the edge cases of your domain, too verbose etc.

Additionally a framework will likely be bloated and inefficient because they try to solve every problem for everyone, and you introduce a random breaking point where any framework update could in theory break your system.

Re: Why Vanilla JavaScript

#96

Post by tancop »

shams93 wrote: post #31

The power of web components is having the ability to develop complex front end without the need for a build tool in 2026. In 2008 when I got started with heavy javascript jquery was a must have tool to fill in for all the horrible browser api incompatibilites at the time. But because we are just developing custom elements with vanilla it works fine with vue and rust and all the others.

> develop complex front end without the need for a build tool

zero build on complex front ends is disrespectful to your users. when you dont minify and code split you are basically saying "got a slow connection? tough luck, go wait for 10 seconds while this page loads 1.5mb of code that could be 5x smaller but i dont care enough to spend a couple minutes on a basic vite setup."

you might get away with it when its a mostly static page with a couple lines of script but when its a bigger app users will notice. "just write less code" is not an option most of the time. and tsc is also a build tool so if you take it strictly you either get no type safety or get stuck with awful looking jsdoc comments that take up space in your final script file.

Re: Why Vanilla JavaScript

#97

Post by simondotau »

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 the crap loaded by the ad intermediate, all the crap loaded by the ad itself, an ad "traffic quality" montor, a Stripe.com thing (even though this isn't a payment page), something from Facebook, something else from fbcdn...

Re: Why Vanilla JavaScript

#98

Post by megous »

LostInTheWoods wrote: post #43

This article misses the point of frameworks like Angular. Its never been about whether a framework is qualitatively better that vanilla or some other framework. The issue is when your codebase and your team reach a certain size you need the baseline, predictability and the guard rails that a framework provides. Otherwise you risk your project spiraling into chaos.

All projects spiral into chaos unless there's a person or more who try to reduce the growth of entropy, all the time, framework or not.

And these days, LLM agent will just re-use existing patterns if prompted correctly, regardless of who in the team is using it or whether or not there's a public well known framework in place or not. So consistency should not really be an issue anymore even in a team.

Re: Why Vanilla JavaScript

#100

Post by inigyou »

ganzsz wrote: post #72
umvi wrote: post #67

Earlier quoted context omitted.

Not everyone is building complex UIs like google sheets. Most people are building static pages with a sprinkle of interactivity, or maybe form pages for doing CRUD.

It starts as simple crud, but then product introduces a business rule where some fields need to be hidden when another option is selected somewhere. O, but not when this checked, etc. Having a reactive framework when this happens is very much needed to keep all these effects working without a lot of vanilla JS. This can be solved later, but is a lot harder when you have an entire application that needs to bee kept wo…

Your first thought might be to use React, but in prior eras we wrote a function updateFieldVisibility() and that worked fine. Straightforward code can be faster than using a state management framework to determine exactly which fields' visibility changed.
Post reply on HN