Why the least enterprise solution may be the best for enterprise.

Lobsters is a community-driven platform for sharing and discussing links to articles, tutorials, and projects related to technology and programming. Readers can learn about a wide range of topics, from software development and system administration to cybersecurity and artificial intelligence. With user submissions, comments, and voting, Lobsters provides a platform for collaborative learning and knowledge sharing among technology enthusiasts.

Lobsters

A developer argues for using Vanilla JS and native browser APIs over SPA frameworks like React for production web apps. The core argument is that React's abstraction leaks heavily (hooks, hydration, component trees), browser APIs are stable and well-documented, and plain JS is simpler to maintain long-term. The author shares personal experience abandoning Preact mid-project in favor of direct DOM manipulation, finding it easier and more reliable. The post challenges the assumption that modern frameworks are necessary or superior for most use cases.

The Business Case for Vanilla JS

I more or less agree with the author. Modern JS is powerful and if you use web components you can encapsulate functionality and make it easily reusable. It also removes dependencies and makes projects leaner. There is maybe a bit more setup at first (to make the app cohesive) but once that is done it can work just like any other react/vue app. With very little effort you can also make the app reactive and make it add/remove event listeners by itself so it really feels like one of the common frameworks/libraries.

Currently porting a huge React application to vanilla JS and HTML. The performance improvement is absolutely huge and it is far easier to maintain. Absolutely agree with the author.

For speed and optimization frameworks are back bone

My bet is that this is either something small or author didn’t consider how it will work out in few years or when team grows. We use frameworks to abstract out web app elements and concepts and then pass them around and reason about them with different people. We also use them for their APIs, interfaces and ability to handle complex scenarios without the need of coding everything, each time from zero. They of curse have their drawbacks also called “leaks in abstractions” but this is always a tradeoff. Why didn’t the author went with Assembly or Rust? That would be even better. Right? :)
On the other hand I sympathize with the idea of writing in pure JS/TS but that was not possible at the time when frontend frameworks were born - about 15 years ago. They are still valid to this day from exactly the same reason for what they were created. They give space to bridge the gaps and cover shortcomings of different technologies.
I use React for about 10 years and to this day I remember how to write a todo app in vanilla JS+HTML+CSS but I would never ever want to work with vanilla JS in many years and teams lasting project.

JS is well capable now - and the author is perfectly correct - native JS is much more maintainable.