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.
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.
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.
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.
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.
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.
Writing programs in C has simplified developer experience over Assembly. Issue with JS frameworks is that many find them complex, i.e. complexity has not been abstracted away (which should be goal of abstractions). Maybe DOM manipulation has, but many new complex ideas had to be introduced to achieve it.
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
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.
Well, you could use jsDoc to hold your types instead of writing them in typescript. The typescript compiler can still check types in jsDoc comments but you do not need a build step and the javascript you ship to the browser would be the same you write in your editor.
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.
We practice engineering. As engineers, we need to understand the realities of each project we take on. Those realities are not limited to the marketing bullet points we might apply to the imagined product someday, which is what early career folk might naively call "the requirements".
Among the most critical realities to consider exist outside the product definition entirely, and have to do with the environment in which it will exist during and after development. These are things like plausible scaling curves and limits, code lifetime, team size, deployment options and preferences, etc. Others are things like available runway, team fluency and talent, available tools and licenses, etc.
One of the big eyeroll moments of the last 15 years or so was when folks started blindly cargo culting global-scale 10,000-engineer enterprise practices on projects that would obviously only ever be touched by 1-2 technicians and deployed on a far far far more modest scale. Instead of actively considering any of those environmental requirements above, "engineers" would try to treat every project as though it would someday service 10,000,000 DAU under the hand of dozens or hundreds of churning technicians.
Akin to the joke about some Americans who see themselves as "temporarily embarassed millionares", making foolish choices at their own obvious expense, many engineers during this era would seem to see themselves as "temporarily embarassed Facebooks".
In countless cases, this was simply very dumb and very wasteful and at best amounted to inadvertent (or perhaps intentional) resume-padding for the people involved, while their projects bloated and sagged and lurched under unwarranted complexity.
Sometimes (in fact: often), just doing the thing well with simple, clear, stable tools -- and nothing more -- is the right choice.
It is truly insane that this still continues to happen today, I mean the entire cloud industry is built on overcharging clients for compute they will never ever realistically use.
Not too mention how damaging it all is to environment in exacerbating the climate catastrophe.
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 head. Whereas pages in our legacy PHP codebase look completely different depending on who implemented them.
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.
> 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!
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.
It’s been a minute since someone ranted about frontend frameworks. Take a shot.
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.
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.
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.
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.
Is it mainly the reactivity part of Vue that you benefit from, or are there other aspects which are important?
Writing programs in C has simplified developer experience over Assembly. Issue with JS frameworks is that many find them complex, i.e. complexity has not been abstracted away (which should be goal of abstractions). Maybe DOM manipulation has, but many new complex ideas had to be introduced to achieve it.
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.
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
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.
I wish there was some sort of "use strict-typed" or something that let you use in-browser interpreted typescript
Well, you could use jsDoc to hold your types instead of writing them in typescript. The typescript compiler can still check types in jsDoc comments but you do not need a build step and the javascript you ship to the browser would be the same you write in your editor.
I built some modules with jsDoc because I didn't want to have a build step but wanted type support.
Works fine.
It works really really well. No one should be writing untyped JS anymore.
"use stricter";
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.
You can say that without being demeaning. These are random people acting in good faith.
Also - sometimes it is actually useful to make a mini-thing instead of bringing in enterprise messes.
These people are perfectly fine with depicting React developers as corporate zombies that can't think for themselves. Good faith is bidirectional.
We practice engineering. As engineers, we need to understand the realities of each project we take on. Those realities are not limited to the marketing bullet points we might apply to the imagined product someday, which is what early career folk might naively call "the requirements".
Among the most critical realities to consider exist outside the product definition entirely, and have to do with the environment in which it will exist during and after development. These are things like plausible scaling curves and limits, code lifetime, team size, deployment options and preferences, etc. Others are things like available runway, team fluency and talent, available tools and licenses, etc.
One of the big eyeroll moments of the last 15 years or so was when folks started blindly cargo culting global-scale 10,000-engineer enterprise practices on projects that would obviously only ever be touched by 1-2 technicians and deployed on a far far far more modest scale. Instead of actively considering any of those environmental requirements above, "engineers" would try to treat every project as though it would someday service 10,000,000 DAU under the hand of dozens or hundreds of churning technicians.
Akin to the joke about some Americans who see themselves as "temporarily embarassed millionares", making foolish choices at their own obvious expense, many engineers during this era would seem to see themselves as "temporarily embarassed Facebooks".
In countless cases, this was simply very dumb and very wasteful and at best amounted to inadvertent (or perhaps intentional) resume-padding for the people involved, while their projects bloated and sagged and lurched under unwarranted complexity.
Sometimes (in fact: often), just doing the thing well with simple, clear, stable tools -- and nothing more -- is the right choice.
It is truly insane that this still continues to happen today, I mean the entire cloud industry is built on overcharging clients for compute they will never ever realistically use.
Not too mention how damaging it all is to environment in exacerbating the climate catastrophe.
>"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 head. Whereas pages in our legacy PHP codebase look completely different depending on who implemented them.
What’s the Idiomatic Vanilla JavaScript way to bind data and UI in a web browser?
Web components, invoker commands API, etc.
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.