And the craziest part is that it is built on top of JS/HTML which is an extremely stable technology at heart.
15 years ago I wrote a small (5KLOC) vanilla JS webapp that is still in daily use by around 10 people without a single line changed.
It held up better then my Win32 applications!
Almost all of the front end churn is simply a political/organizational failure.
I build simple applications for personal use like issue tracker, day planner, etc,. By default if you ask Claude it will generate React for frontend but I ask it to use HTML/CSS/JS instead. Because as a backend developer that makes sense to me. I find it hard to read the react code and want to avoid having dependency on npm.
It's surprising how well the core technology works without fancy front end frameworks. Claude does most of the grunt work related to CSS/JS allowing me to focus on more interesting things. I only have to do few minor changes here and there which I am happy to do.
Yes, 100% this. I’ve seen this idea before somewhere, but I wouldn’t be surprised if people started to basically develop more of their own software from first principles like this.
I was doing it today to create a gantt chart from mermaid.
I’ve built other applications inside react components as react seems relatively stable - I don’t really care about react though, only that it has a lot of training data for it.
Yeah it's surprising how easy many things really are. I asked Claude to spice up another vanilla JS/HTML app with a Material UI like touch ripple effect and... it simply did.
Was just around 100 lines of CSS/JS. No need to rewrite everything.
Of course it works without frontend frameworks, but if you develop a frontend application using plain JS your core problem is still the one frameworks solve: syncing your application state with the DOM.
At first you can do this manually using selectors, but a complex app will need to be capable of doing this to hundreds of elements whenever state changes. At that point you will build some kind of abstraction because manually updating every element would be insanity. That abstraction might be a simple virtual DOM, and now you are halfway to building your own React.
I did that a few years ago and it was fascinating: not only did it remove near-weekly React dependency churn, it produced significant performance improvements (multiple orders of magnitude better update speed - and yes, I did the usual incantations), and the total lines of code in our repo actually went down and it was easier code because it just did what was necessary without having to deal with layers of abstractions designed to work around earlier problems created by the framework.
One of the things I realized while working on it was that it was easy because I’ve learned the web platform over the years and was able to use builtin features rather than reaching for more libraries, but a lot of younger developers only ever really learned React and are stuck the IE6 era it was designed around. That allows them to be productive, of course, but it often means that people take on layers of dependencies because once they’ve invested a lot in that path the cost of switching is really high.
It may be hard to remember now that we’ve had frequently-updated browsers for so long but not everyone updated promptly. That lead to a lot of now-vestigial frontend culture where developers would build around the oldest browser they couldn’t afford not to support.
That colored a lot of low-level decisions about how events were implemented, false claims about virtual DOMs being fast or efficient, and especially the culture of adding dependencies because you need a feature which wasn’t in Internet Explorer. Once that trend is established, it’s hard to change without breaking compatibility and so you end up with people in 2025 using slower code based on the support matrix set over a decade earlier.
(And to be clear, I’m not saying that React has no redeeming values - only just it’s healthy to reconsider decisions made in previous decades to see whether the cost/benefit ratio has changed. I think we’re going to see some really interesting shifts as funding for open source shifts in a non-boom economy, but also as LLMs adjust the working style & relationship many people have to maintenance.)
That said, I was on a team that was still supporting IE6 around 2014. We had clients, mostly in China from what I heard, that were required to use it because internal tooling had developed around it and their IT teams wouldn't let them upgrade.
Yeah, I worked on things geared towards the general public so we had to support, say, a senior citizen who was using old computers at the underfunded library or senior center. They weren’t a high percentage of total traffic but it was still millions of people.
It was definitely frustrating knowing that a better world was possible but not quite there.
If you are in the US, it's more likely than not that your local/state court system is managed by software that runs almost entirely on VBScript within an IE7 wrapper.
This stability does mean that old React (or Knockout, or whatever) applications will still work just fine for the end users, likewise without a single line changed.
The instability is on the tooling side (and peer deps). Getting back into a project that uses Broccoli and Bower is a nightmare. And that was just a handful of years ago. You have to become a detective, finding what combination of package versions and Homebrew dependencies were expected on the last git commit date.
> This stability does mean that old React (or Knockout, or whatever) applications will still work just fine for the end users, likewise without a single line changed.
Not in the current enterprise cyberops environment of needing to pass dependency security scans at all times.
I also haven’t seen it in any other place. Game dev and backend which I’ve worked in uses the same technologies for decades. It’s like someone trying to write a book but instead of writing a new chapter each month they mess about with their ink choice and their font choice and their paper roughness and get very little actual progress
15 years ago I wrote a small (5KLOC) vanilla JS webapp that is still in daily use by around 10 people without a single line changed. It held up better then my Win32 applications!
Almost all of the front end churn is simply a political/organizational failure.