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

41–50 of 176 posts

Re: Why Vanilla JavaScript

#41

Post by d--b »

I think OP is mainly right about this, but the tone of the article is going to annoy people very much. I believe many of us have done both the self-serving homemade framework and the industry standard framework. And many of us know the pros and cons of both approaches.

I don’t like react very much and dislike the other ones even more. Yet, it’d be stupid to say you can’t make them work. They come with a large community and pckages and solve a ton of problems that a homebrewed framework doesn’t even conceive of. And you can just start writing the stuff you need right away.

On the other hand, a homemade framework doesn’t require the extra overhead of knowing the framework, and maintaining it overtime. You don’t need to track down why the code gets run a gazillion times more than it needs to, you can debug through your events, etc.

They’re just different ways of doing things.

But mainly: react is a pain in the butt but if time is your constrain, it should get you to where you want to be faster than if you’re not using it.

Re: Why Vanilla JavaScript

#43

Post by LostInTheWoods »

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.

Re: Why Vanilla JavaScript

#44

Post by socketcluster »

I love vanilla JavaScript. All my personal projects are plain JavaScript. No Typescript. But in a company setting, it's almost impossible to find plain JavaScript roles.

Plain JS is also a lot better with AI. I don't recall Claude ever making any mistakes in terms of getting the type wrong with plain JS since I started using it. It's just not the kind of mistake that AI makes.

I feel somewhat vindicated by this. I've been saying for years that coding isn't the hard part, type correctness isn't the hard part. I also made a point that complex interfaces are a greater danger and that Typescript tends to encourage people to design complex interfaces... And look, this certainly seems to be reflected in the training data because my AI token usage at work (Typescript) is far greater than on my side projects for the same task complexity.

This is kind of proving my point that plain JS code is better architeted overall than Typescript code... It makes sense to me, any complex plain JS code MUST be well architecture because JS is unforgiving. The spaghetti doesn't go very far in JS.

Re: Why Vanilla JavaScript

#45

Post by mrugge »

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…

LLMs are non-deterministic and can benefit from guardrails which frameworks happily provide.

Re: Why Vanilla JavaScript

#46

Post by thisoneisreal »

austin-cheney wrote: post #40
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.

I write in vanilla TypeScript. I do not have any build step in my application. Since Node now supports native type stripping I don't have a compile step either. I just write my code and then point node at the main file, and this even includes front-end code for the browser.

Can you explain more about how the front end aspect works? I'm not clear how the front end code could by TypeScript without a build step, unless I'm misreading.

Re: Why Vanilla JavaScript

#47

Post by doginasuit »

mrugge wrote: post #45
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…

LLMs are non-deterministic and can benefit from guardrails which frameworks happily provide.

If you are relying on a LLM to write the code, sure. But no amount of guardrails can maintain the quality of a primarily LLM generated codebase.

Re: Why Vanilla JavaScript

#48

Post by nilirl »

> The idea of reactivity came from or was popularized by Angular.js

No, spreadsheets popularized reactivity. And the general point is incredibly weak.

Don't use frameworks and make your own? Sure, have your fun. But then try teaching your framework to your company of 1000 and see how quickly you realize your view of the "problems" are only a slice of the pie.

Re: Why Vanilla JavaScript

#49

Post by onion2k »

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 the code so verbose?'

The massive advantage of a framework is that the people who choose it have agreed to share a solution to the common problems. This cannot be overstated - as soon as your team grows to more than one developer you move from 'solve the problem' to 'solve the problem in a way that people agree on', and that is far more complicated than just solving a problem. Sometimes you get lucky and work with people who think the same way as you, or with people who are willing to compromise on their ideal solution and accept yours, and then things still work, but if they're 'passionate' about being right then it's horrible, slow, and results in bad code.

A framework is an upfront agreement about how to build something. That has no practical advantage for a dev working alone. It's incredibly useful for two or more devs working together. Which framework doesn't really matter, except the ones with more devs behind them make it a lot easier to find people who've already accepted that way of working. That's helpful.

Post reply on HN