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.
> 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.
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.
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.
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?
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 think the complaints attenuated in the last in the last 10-15 years because javascript itself became a much better language. Things really started to change with ES5. The introduction of let / const, modules, async, .?, template strings, etc. transformed it from an ugly kludge to a really capable language.
Of course, if you use old syntax you still deal with weird scoping and casting, but you don't have to any more.
Also, I think the framework churn has slowed considerably in the last 5 years.
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?
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.
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.
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.
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.
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.
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.
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
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 like this article because it feels so pre-AI. This is what people were arguing about on HackerNews back in the day! How so very nostalgic it makes me feel.
But in response to the article: no, vanilla JS is a nightmare to keep your code organized, and battle tested frameworks do quite a good job at that. It's otherwise mostly a waste of time, or an intellectual exercise at most, to build an app with vanilla JS
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.
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.
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.
JSDoc is not as powerful as TypeScript types but that might be fine for your use case. However, if you are already using tsc I don't see why you'd care about a build step, and if you care that the JS in the browser is the same as the editor, tsc can do that too without minifying and changing the JS output, merely stripping the types instead.
I know posts like this get a lot of whinging, but you are 100% right. The browser is in itself a platform; frameworks are not like some kind of hyper abstracted Web Scrinting Language for people too important to deal with "raw" CSS/DOM. They're a an awkward, alternate abstraction, slow as molasses, and they leak like a sieve.
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.
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.
The whole thing boils down to creating objects (the constructor is built-in) and using functions on objects. Functions are objects, too. In fact, everything except primitive values are objects.
IMHO knowledge of C++, Python, or pretty much everything that's not a lisp variant, doesn't translate well to JavaScript.
There's such a nice language with its own silly warts, readily available to pretty much anyone with a computer regardless of form factor, being misunderstood by the vast majority of programmers.
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.
you just agree on a set of conventions for components and state management, it's not that hard. This is basically how Rails works...
yes it's still a framework, duh. it's just less abstraction than react etc.
Sure, and if you like working with the conventions and abstraction Rails offers that's great.
Other people make different choices. That doesn't mean they're wrong.
> 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.
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.
Is it mainly the reactivity part of Vue that you benefit from, or are there other aspects which are important?
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.
> 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!
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?
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 think the complaints attenuated in the last in the last 10-15 years because javascript itself became a much better language. Things really started to change with ES5. The introduction of let / const, modules, async, .?, template strings, etc. transformed it from an ugly kludge to a really capable language.
Of course, if you use old syntax you still deal with weird scoping and casting, but you don't have to any more.
Also, I think the framework churn has slowed considerably in the last 5 years.
It’s been a minute since someone ranted about frontend frameworks. Take a shot.
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?
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.
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.
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.
Sure, when I wrote JavaScript for a living I wouldn't trust my employer to get hiring or training right either.
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.
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.
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.
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.
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
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 like this article because it feels so pre-AI. This is what people were arguing about on HackerNews back in the day! How so very nostalgic it makes me feel.
But in response to the article: no, vanilla JS is a nightmare to keep your code organized, and battle tested frameworks do quite a good job at that. It's otherwise mostly a waste of time, or an intellectual exercise at most, to build an app with vanilla JS
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.
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.
You still need a build tool, and that tool is likely broken if you need to return to the project in a year or two.
TypeScript benefits can be had without a build step by leveraging JsDoc.
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.
JSDoc is not as powerful as TypeScript types but that might be fine for your use case. However, if you are already using tsc I don't see why you'd care about a build step, and if you care that the JS in the browser is the same as the editor, tsc can do that too without minifying and changing the JS output, merely stripping the types instead.
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";
Based and Vanilla JS pilled.
I know posts like this get a lot of whinging, but you are 100% right. The browser is in itself a platform; frameworks are not like some kind of hyper abstracted Web Scrinting Language for people too important to deal with "raw" CSS/DOM. They're a an awkward, alternate abstraction, slow as molasses, and they leak like a sieve.
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.
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.
What’s the Idiomatic Vanilla JavaScript way to bind data and UI in a web browser?
The whole thing boils down to creating objects (the constructor is built-in) and using functions on objects. Functions are objects, too. In fact, everything except primitive values are objects.
IMHO knowledge of C++, Python, or pretty much everything that's not a lisp variant, doesn't translate well to JavaScript.
There's such a nice language with its own silly warts, readily available to pretty much anyone with a computer regardless of form factor, being misunderstood by the vast majority of programmers.
What are you really asking? You use data to populate content or inform your logic.
With webcomponent each tag is a component instance that can hold data and there are hooks for attributes change
Web components, invoker commands API, etc.
*vanilla typescript
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.
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.