Why Vanilla JavaScript

guseyn 118 points 71 comments July 12, 2026
guseyn.com · View on Hacker News

Discussion Highlights (20 comments)

benoau

Some good history of the JS ecosystem here but the underlying message is all the same, frameworks scale and provide structure but you don't need them. Very easy to agree up to this point. Author then elaborates in the absence of using a common-knowledge framework you can create some tighter solution that achieves just the part you need. This is "fun" programming, and the author is suitably impressed with themselves for solving problems they created just by convincing themself not to use a framework. Sometimes that's fine, although I don't think there's much appetite for this anymore. Article doesn't really elaborate on what "scaling" and "providing structure" means, I think it downplays the benefits because when you use <framework> you are really establishing ground rules for how all future developers are going to work on that software. You don't know exactly what they'll write, but you know they'll always gravitate towards the top 2 or 3 solutions for that framework at any given time. When you bust out a bespoke solution that carves out that one thing you needed and does it oh so elegantly and perfectly, you're creating art but most of the canvas is left blank for future developers and they're effectively going to scribble on it with crayons.

Gualdrapo

I wish there was some sort of "use strict-typed" or something that let you use in-browser interpreted typescript

hoppp

Did anyone else notice the pattern that ever since the LLMs got popular the "I hate javascript" kind of posts or comments have decreased? It could be attributed also to typescript dominance of course, since people don't use plain js anymore. As for the blog post, I agree, I also implemented my own js framework when I code in vanilla js and it works fine. The problem is not inventing frameworks, the problem is that everyone invents frameworks, so people all know different things and they are hard to hire.

mircerlancerous

Any framework that requires me to learn custom syntax, is a problem in my opinion. I agree with the author that the browser is already the framework, and a powerful one at that. I don't really struggle with views and dom thanks to my own libraries, so maybe those without appreciate thw guilded gardens of these frameworks. Problem is that if these frameworks fall out of favour or stray from their original quality, you're stuck with worthless knowledge and maybe code as well

doginasuit

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 presentation philosophy and the more you try to cover it up, the more awkward your code becomes at the edges. The killer application of LLMs is their ability to inform and adapt to a particular API, and analyze the code that you write. They are garbage at producing functionality for which they don't have a thousand examples, but provide documentation and intent and they will help you fill in the gaps. This is the real 10x opportunity, and the best part is that you can still write all the code yourself. I'm certain this doesn't just apply to javascript and the web. I predict that the need for frameworks will slowly go away.

WhyNotHugo

I appreciate the sentiment, but can't agree fully. I used vanilla JS for many years before AngularJS even existed (and I also tried AngulasJS when it was the new thing). Vue is just a huge convenience over raw JavaScript for large, complex view. Sure, I don't get to do direct DOM manipulation, but when I write C code I also don't get to pick which variable goes in which CPU register. I accept giving up control that ASM would give me, for all the improvements that C brings on top of it, even if C just compiles to ASM and is an abstraction on top of it.

jagged-chisel

What’s the Idiomatic Vanilla JavaScript way to bind data and UI in a web browser?

prokopton

It’s been a minute since someone ranted about frontend frameworks. Take a shot.

danielvaughn

I've been considering going back to vanilla javascript, given the current power of LLMs. It could become unreadable spaghetti, but it does that anyway with frameworks.

teaearlgraycold

Sad to see no mention of @ts-check. I love being able to write native browser JS modules with nearly all of the functionality from TypeScript.

uzyn

Author's EHTML "framework" reminds me of HTMX. https://e-html.org/html/vs-others.html misses comparison with HTMX. Curious on the similarities and differences.

hexasquid

> NO, YOU CANNOT JUST USE GLOBAL STATE. USE THIRD-PARTY LIBRARY WITH FANCY FUNCTIONAL DESIGN. window.i = 0; // initialize all my for loops in one go!

umvi

Even better: vanilla TypeScript + golang middleware (esbuild) on the backend that converts to JS on the fly. Like vanilla JS but with all the benefits of a type system and no bundler or npm required.

jv22222

4 years doing this before AI. Then I felt my tool was not quite right for the AI environment. Now I'm building something else with AI.

shams93

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.

sheept

Vanilla JavaScript makes sense for personal projects, but if you're working on a team, I wouldn't trust other team members to not create their own frameworks that may not be as well documented. Especially nowadays with LLMs, the team would benefit more from the LLM innately knowing a widely used library/framework than having to spend context each session teaching the agent your custom setup through context files and skills.

brutaljokerz

*vanilla typescript

motoxpro

My take is that the take that vanilla js is better because developers love coding more than they love building the thing. See all the frameworks/packages built as an example. This person re-invented form handlers, frameworks, ui helpers just to be able to do some basic things. All power to you if you like it, its just funny.

adamtaylor_13

Did I misunderstand or was that whole rant just to establish that, actually, we do need super tiny frameworks for the front end, but they're super tiny so it's not a big deal and they're not bad like React?

tisdadd

I have to admit that I really love web components ever since Polymer 1, and agree with the article sentiment (this post was starting to get to be a mirror of many of the authors thoughts, so cut it down) It is very interesting watching the Web cycles, and found it curious how many people here were sad that typescript was not mentioned. There are some fun (though I suppose dangerous) things you can do without it, and I've found it has had very many instances not helped me where expected like a fully matured typed language has. And I've worked with a lot of people who just went I added types and don't know how to use generics. I guess if you have it poorly implemented, then it's best to leave as JavaScript. And, web components you can keep things very simple... Which helps keep many errors down.

Semantic search powered by Rivestack pgvector
14,015 stories · 131,331 chunks indexed