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.
Was just around 100 lines of CSS/JS. No need to rewrite everything.
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.
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.
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.
If the underlying technology hasn't really changed, why constantly break the tooling and compatibility in general?
This collective lack of discipline is exactly why I don't work in FE. It's just tiresome for no actual reason.
Not in the current enterprise cyberops environment of needing to pass dependency security scans at all times.
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.
Last release of IE6: 2008
Concerted campaign to make everybody stop using IE6: 2009
Microsoft joins that campaign: 2011
First release of React: 2013
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.
It was definitely frustrating knowing that a better world was possible but not quite there.
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.