No, and not before that either. It’s a bizarre thing to say, honestly. React is used near universally, despite there being alternatives that are better in almost every way. That is the opposite of being under appreciated. Hype about a new technology, deserved or not, doesn’t mean that everyone is throwing their old code away, especially not their jobby job code.
back
5 comments
I think it's because around 2015 or so there was a lot happening with front end frameworks, and the sentiment comes from then and people have just not updated their priors since.
AngularJS was pretty popular at the time, Angular 2 migration was looming, backbone still existed, jQuery (standalone or paired with both) was going strong, Polymer hit 1.0 and it looked like Web Components might actually be something and useful, React was gaining a lot of popularity, Vue was gaining a small amount of popularity, svelte an even smaller amount, Meteor was somewhat popular and had its own front end library.
Of course in addition to all that, traditional server rendered sites were more popular then than now and there were even more options there.
However, React quickly became pretty much the default. Not that there's 0 churn there. The "right way" to do React has changed quite a bit in the last decade. And early on before all the libs people liked to glue together somewhat matured/settled it was common to have to replace stuff that just got abandoned.
More than once I had to pick up someone's old unmaintained project to do a bug fix only to find I couldn't even get the project to install/run because it was in the pre auto lock file era and nobody ever ran `npm shrinkwrap`
Let's not conflate the two things that were said.
It is absolutely true that companies were rushing to rewrite their code every few years when the new shiny JS library or framework came out. I was there for it. There was a quick transition from [nothing / mootools?] to jQuery to Backbone to React, with a short Angular detour about 13 years ago. If you had experience with the "new" framework you could pretty much get a front-end gig anywhere with little friction. I rewrote many codebases across multiple companies to Backbone during that time per the request of engineering management.
Now, is React underappreciated? In the past 10 years or so I've started to see a pattern of lack of appreciation for what it brings to the table and the problems it solved. It is used near universally because it was such a drastic improvement over previous options that it was instantly adopted. But as we know, adoption does not mean appreciation.
> React is used near universally, despite there being alternatives that are better in almost every way.
Good example of under-appreciation.
Having worked in both over the years the main technical thing React had going for it over Vue, in my humble opinion, was much better Typescript support. Otherwise they are both so similar it comes down to personal preference.
However 0 of the typescript projects (front and back end) I've worked one (unless I was there when they started) used strict mode so the Typescript support was effectively wasted.
No, I was also around when React was new, moving to it from tangles of jQuery and Backbone. I absolutely know React brought several lasting innovations, in particular the component model, and I do appreciate that step change in front-end development. But other frameworks have taken those ideas and iterated on them to make them more performant, less removed from the platform, and generally nicer to work with. That is where we are today.
I agree that there was a period where many organizations did rewrite their apps from scratch, many of them switching to React, but I think very few did it ”every couple of years”, and I think very few are doing it at all today (at least not because of hype - of course there might always be other reasons you do a big rewrite). We should not confuse excitement about new technologies for widespread adoption, especially not in replacing existing code in working codebases.
I read parent's comment as an assertion that the current "fast-moving JavaScript world" expects everyone to rewrite their app. Personally I've never seen this, but since React became popular ~13+ years ago, I struggle to believe this has actually been true for others in any meaningful way.
Mootools is still around! "Copyright © 2006-2025". I don't know anyone who uses it, but glad it see it's still going.
MooTools also features in the infamous SmooshGate:
> the opposite of being under appreciated
> despite there being alternatives that are better in almost every way.
This right here is the under appreciation. The new way to signal to others on forums that you are a really really great dev seems to be to bring up how much better some bizarro templating engine that abuses a niche JS language feature is.
React has fundamental problems that lead to both:
- horrible performance characteristics
- needless complexity
These are not tradeoffs, these are bugs. We don't gain anything from them.
That's why React introduced a compiler. Because problem 1 is a big deal. But it's not a code problem, it's a React problem. Other tools simply do not have that bug. Which is why the exact same react code can be compiled and run much faster.
You haven't described those "fundamental problems" that you call bugs, but I think these are irrelevant for me from a ClojureScript point of view. As an example, immutable data structures mean that equality comparisons are cheap and I can often avoid re-computing and re-rendering huge parts of the tree.
More importantly, I don't have a React performance problem. I don't really need "much faster".
> More importantly, I don't have a React performance problem. I don't really need "much faster".
Sure, but ultimately you're using a library with performance bugs that lead to orders of magnitude more rendering than necessary.
If you don't mind the buggy software, that's fine. It's still buggy.
I'm curious what makes a template language bizarro, and why JSX is or is not bizarro?
JSX is just sugar around JavaScript, and interops nicely with it. I'm okay with that. The more I write JSX, the better I become at the programming language I'm using. Concepts and patterns in JS can be adopted in my components.
If I learn Vue's templating language, then I'm spending my time learning a system with no wider applicability, a much narrower tooling space, that doesn't utilise my previous or future experience from JS. That's not a good calculus for me.
I don't understand how Jsx is syntax sugar in a way that vue templates aren't. Neither of them are valid JavaScript but they both compile to it.
A concrete example then. Commonly want to prevent form submission default behaviour.
Vanilla
<script>
const form = document.getElementById("form");
form.addEventListener("submit", event => event.preventDefault())
</script>
<form id="form">...</form>
<form onSubmit={event => event.preventDefault()}>...</form>
<form @submit.prevent="onSubmit">...</form>
Vue's API has reinvented the wheel. There's one place this syntax is useful and one place alone - Vue itself. It hasn't used my existing knowledge, or pushed me to become more familiar with the platform upon which I'm building. That's not sugar, that's a new language.
I've probably got the vanilla example wrong - when you don't do it frequently it's not the most ergonomic thing in the world. React takes that API, doesn't deviate far from it, and makes it easier to use. Sugar.
Fun example! Strange conclusion. React actually uses a synthetic event system that is subtly different from the native one in all kinds of little ways. In reading the docs it’s hard to even get an overview of what’s different. Bubbling is a bit different, onChange works like the input event for some reason, various props and methods have been added. This is not the case for Vue! It just uses standard events.
The .prevent modifier in Vue is completely optional, you can call .preventDefault() yourself. Note that React also uses a kind of modifier but only for capturing events (onClickCapture etc). It does not have any way that I know to add a passive event, for some reason.
Vue is the one that actually offers syntax sugar, and does so much more consistently, with the semantics identical to the browser. React changes the semantics for unclear, historical reasons, and then adds half-baked syntax sugar on top.
I'm not claiming React is perfect by any means, and like any popular relatively longstanding project is is bound by sometimes unwise historical decision. It just seems to be currently in vogue to take a pop at it. If you want to extol the virtues of Vue/Svelte/whatever then great, but React is still IMO a great option and deserves some defense.
This seems like a very hostile and uninformed take on the alternative tools.
Have you tried building anything with Vue or Svelte recently?
Can you provide some concrete issues you ran into beyond them being “bizarro”?
I consider this example fundamentally broken, in a non-obvious way that reflects, in my opinion, a poor API choice.
<script>
let numbers = $state([1, 2, 3, 4]);
function addNumber() {
numbers.push(numbers.length + 1);
}
const sum = numbers.reduce((x, y) => x + y, 0);
</script>
<p>{numbers.join(' + ')} = {sum}</p>
<button onclick={addNumber}>
Add a number
</button>React often gets lumped into general JavaScript hatred of the form “the entire ecosystem of tooling/frameworks/libraries changes every few months.” That’s despite React existing for one third the lifetime of the World Wide Web. React is older now than jQuery was when React was first released.
Although aside from JSX, so much has changed it could’ve been a new framework at least once, and part of its longevity is that it doesn’t bundle a router, form handling, etc, and the popular ones of these have changed many times.
The "in some circles of the fast-moving Javascript world" is important - they're not saying everyone or even most, they're saying proponents of the "better" systems (who do rewrite regularly) dismiss React's stability as unimportant or indicating it's dead when it's not.