In his recent article, Josh Comeau predicts AI won’t overtake frontend development (at least not soon). I agree, but something else Mr. Comeau wrote made me write this post.
“And by the way, frontend is still complicated and hard even when it doesn’t involve a JS framework. I have a tremendous amount of respect for folks who specialize in producing high-quality websites using HTML, CSS, and vanilla JS, focused on usability and accessibility.”
At first, this statement sounded very flattering. I fall into this category, and I thought it was very kind that Mr. Comeau highlighted how he respects people who don’t use JS frameworks and can still produce top-notch sites.
But then it started to sound odd.
“…even when it doesn’t involve a JS framework.”
Is it really that unusual for a frontend developer not to use a JS framework?
I’m sure Mr. Comeau didn’t mean harm (really, I have the utmost respect for Mr. Comeau and his work), but his statement raises questions about the current state of frontend development. Are JS frameworks now considered the standard, and are developers who don’t use them rare? In my experience of over ten years, I have never used a JS framework to build a website, only for web apps. Web app - sure (although a long time ago), but websites - never.
According to my research (an actual job search), finding a frontend position that doesn’t require JS framework knowledge is a true rarity. Nine of ten frontend job ads require some JS framework skill, maybe even more. Perhaps the reason is that these JS frameworks are taking us as hostages, as noted by EmNudge.
“And so my current job is React. My next job will be React. The one after might as well.”
— EmNudge
JS frameworks have their purpose and place, but I don’t think a regular website should have ~65k lines of code (it is fine for Mr. Comeau because his site is his playground, and I totally get it). However, for most regular sites, vanilla JS is sufficient.
Zach Leatherman’s recent chronologically ordered list of React’s criticisms highlights performance as a central pain point when using React. I wish every React developer reads this. Not only reads - understands.
“An analysis of Core Web Vitals across 9.3 million websites as of February 6, 2023 shows that Core Web Vitals for both React and Next.js shows that both perform worse than the aggregation of all other sites in the archive for both mobile and desktop.”
Every developer should strive to ship as little code as possible and avoid shipping entire frameworks for a simple website. The JS ecosystem’s diversity is excellent, but developers should consider building websites without JS frameworks. I am sure they will soon be amazed that it is even possible. But it is possible, and it will always be possible.
Chris Ferdinandi recommends using vanilla JS if your priority is long-term resilience and maintainability, and I couldn’t agree more.
“It will never become obsolete, or suffer from a breaking version change. It’s fast and performant, results in less code sent over the wire, and generally has a smaller footprint of things to break.
It does sometimes require a bit more wiring of things together for the developer, but often it’s actually less work (and less work in the long term) than using a library.”
While JS frameworks are currently prevalent, they will eventually become a thing of the past. However, vanilla JS will always remain a core language and embrace every developer who returns to it.
Latest comments (11)
always js with framework, practicality is everything.
If you are building a portfolio website, just use Vanilla JS, but if you are building an enterprise project like a front end CMS, with a team of 20 Devs, then an opinionated approach is your friend. I spent 15 years using Vanilla JS & resisted frameworks, until I could no longer get a job. I spent a few years learning Angular & React. I tend to do more Angular contracts now, but I am never out of work. I love learning more about topics like TypeScript and state management [NgRx]. And I believe I am now a better team player, because of these frameworks.
It would be practically much harder to create an enterprise project with a large team, using Vanilla Js, although it is not impossible with the correct amount of preparation & planning.
I remember marvelling at the HighCharts code base, which was done using Vanilla JS, and classes. Similarly, TinyMCE is another great example of a Vanilla JS project, that is incredibly well organised.
My feeling, is use a mixture of approaches, depending on the requirements.
FYI FrontendMasters.com doesn’t use a framework. We use Hugo/Go for templating and vanilla JS on top. The website is incredibly fast as a result.
I’ve documented some patterns here: github.com/1Marc/modern-todomvc-va...
For a few larger dynamic components, we started using lit-html for rendering. There’s an example branch in the repo.
An interesting discussion topic. For clarity, do you mean ES5 when you say vanilla JS (for maximum compatibility)? And do you have all JS in a single file?
I'm ok with ES5.
I think it comes down to where the differentiation between website and web-app lies, as you mentioned.
I've hand built several all-in-one (i.e. JS+CSS in a single HTML file) mini interactive ES5 web pages before (that support IE11), including using d3. It's possible, but I would have preferred a bit more infrastructure to help. For example, using
findon a array is so much simpler than having to write an ES5-compatibleforloop that does the same thing.A colleague I once knew built something similar that ended up near ~10,000 lines long and was a nightmare to debug.
But for simpler sites, yes - I agree with your point of view.
The main reason JS frameworks are prevalent is because they are filling a gap left open by sluggish development of web standards and even slower adoption of them by browser vendors or their understandable unwillingness to look beyond their own problem space.
Web Components are cool as a technology, but also complex and cumbersome. They have no native server-side rendering and need a lot of boilerplate to set up.
On the other hand, frameworks are moving fast. Between the request for simple signals in Angular and their implementation were only a few months. Some developments are measured in weeks rather than years – and you don't need to wait for browser companies to adopt the changes. Frameworks won't ever become a thing of the past: there will always be new gaps.
But you're right, a lot of the larger frameworks are mostly aimed at developers with their claims "do more in less time" meaning development speed rather than the performance for the end user. Luckily, some of the newer frameworks make less compromises when it comes to end user experience to achieve a worthwhile DX. Especially solid.js, Astro and qwik aim to deliver less JS to improve performance. Other frameworks, like preact and Angular have taken up signals as a way to increase performance. Just the react devs don't want to break their dogma of immutable state, even though it's shown not to scale well.
Well, maybe that's one thing that could be a thing of the past at some point.
Agree with all of that. Just had an additional point.
Performance for me is often not how fast the front end renders - who cares, if it's fast enough on the target hardware then no one really cares if it could be faster; if it isn't then there's a problem for sure - so this kind of performance metric is app specific. In my apps performance is probably down to the size of the code and the ease with which it can be split apart - I can't predict the network speed with anywhere near the same accuracy as I can the other specifications in the my user community.
I'm building a new platform for a niche in the b2b space; so for me the most important thing I can do is get software in front of my users and iterate on complex requirements, frameworks help me do that, and help me do that better with several teams contributing to the same code based effectively, due to an IoC architecture for which I would have had to build a framework myself, if I hadn't co-opted React.
Maybe your target is wrong. If you only target top-tier hardware less than two years old, you may lose customers.
Also, it's not nice to drain your users' batteries if they're on their mobile browsers.
You're just driving my point about speed of development over speed of user home for me.
A large part of this is the ecosystem. The react ecosystem is in a strange state right now. Many packages are orphaned, some even no longer support the newest react versions. New packages have varying quality and maintenance. At the same time, established devs like TanStack are becoming more framework-agnostic.
I don't know which one you mean, but there are several framework-agnostic options that play well with the newer frameworks.
My target is fine. It's my target market, well known and understood. Our app is mostly running on a laptop, the mobile version would infrequently be used during a day, and does not drain battery life to any level that has ever caused a comment, let alone a loss of a sale. My users reduce massive costs in their organisation, keep people safe and stay out of jail by using our software and content - better I improve that quickly than get stuck on a detail about how some other framework would save me some small amount of battery life, which is clearly negligible.
I don't rely on a 3rd party framework, beyond React. The IoC framework we use could be implemented on Solid, Vue, Svelte or whatever, we chose React. We have a balanced DX to UX that works for us. It seems you wanted to jump to a conclusion about this, I didn't mention it at all, I wonder why that is?
In our market, and for our customers, our ability to quickly implement features and adapt to changes in the law and the environment is much more important than low level performance improvements - they simply don't pose a challenge for us in our current situation.
Just to satiate my curiosity: how do you measure lost sale?
Congratulations.
I explicitly wrote that I did not know about your solution, so which conclusion do you mean I jumped to?
That being said, you seem to work under the assumption that other frameworks would have better performance at the expense of worse DX or slower development. This is not necessarily the case.