React is winning because its really good. Even if the cost is an extra few milliseconds of render time and few extra hours of dev time figuring out things like hook dependencies.
If React starts taking a backseat, it'll be because its no longer really good. And, to be fair: I've started to see this happen. Next & Vercel have totally taken over the React world, and they've proven to make quite poor architectural decisions. All great empires are destroyed from the inside, not out, and I think its possible Vercel could do this to React. But, also, even as Next seppukus itself, people will likely just fall back to React on Vite (or, there's Remix 3 that's I think still under development, but might end up being big).
apsurd · 15m ago
+1 React DX is really great. It started really great and it got weird and bloated but it's still really great relative to the JS landscape hell.
But, also yes, it's a pain in the ass and a frustrating kind of necessary evil. So there is room for improvements.
Nextjs is a living hell. The ironic thing is AI makes it dramatically more tolerable to the point it's actually pretty good. But that can't be a good thing in terms of architectural design can it? We're in odd times.
Of course, it's easy to be a hater on the sidelines. I am guilty. Nextjs likely just does too much in it's own made-from-scratch clever way. use-client vs server is just out-of-the gate ridiculous. But then I suppose the real question is "well if you want isomorphic environment, how else are you going to do it?". My answers is "I wouldn't!" but then vercel and the powers that be seem to have won the mindshare of the product crowd. At least for now.
sapiogram · 5m ago
What is Vercel doing to React? I just know them as a simple hosting solution.
CBLT · 57s ago
Vercel is anything but simple. Easy, sure.
postalrat · 47s ago
They developed next.js
tshaddox · 51m ago
This is mostly just a complaint about how good React is. It's so good that it's difficult for the technical benefits of alternatives to outweigh the social benefits of choosing React.
Note that this is neither a major compliment to React's technical merits nor a criticism of React's competitors. In fact, I don't even disagree with the author on some of his claims, such as:
> React is no longer winning by technical merit. Today it is winning by default.
> That reflex creates a self-perpetuating cycle where network effects, rather than technical fit, decide architecture.
I agree! But teams are still largely choosing the better option, because the benefits of React are indeed outweighing the benefits of choosing an alternative. What the author is missing is simply that the technical benefits of an alternative are small except in narrow use cases. And I suspect most competent teams do in fact identify if they're in those narrow use cases and correctly choose an alternative.
j45 · 45m ago
React is great at solving complex problems.
Not all problems are complex to begin with, and having a complex tool as default otherwise adds complexity to the project and also inflexibility to iterate quickly.
This is in addition to having to maintain a relatively brittle ecosystem from past feature as well as future features but that can be true for more than one area of JavaScript or other technologies.
Looking for the next curve to emerge out of the current generation of web app building.
wk_end · 7m ago
I think (at least part of) the reason why React has been so successful is that is scales so well: it's actually a relatively simple tool that works well for small problems. Pair it with a Vite template or something and you can be up-and-running in minutes. But it continues working pretty well as your app gets bigger, too.
But where React fails is actually in more complex scenarios. Prop drilling becomes tedious or intractable, so now we have all these different ways to manage state (Context, Redux, MobX, Recoil, Zustand, Jotai...). Your re-rendering gets slow, so now you need to start sprinkling React.memo() all over the place and adding reselect (or re-reselect!) queries and restructuring or denormalizing your store data, but then it turns out some of your props are objects that are regenerating each render cycle, so you need to memoize those too, and you end up on a wild goose chase there. Or your engineers were sloppy and accidentally put some side-effects into your components, so you've got subtle bugs you're not sure how to fix. And there's a lot of complexity or even unanswered questions around things like robustly fetching data your component needs, and maybe React Router answers them but then you end up down a whole other rabbit hole, especially when a new version of React Router comes out and breaks everything.
throwaway-0001 · 32m ago
And the moment you need to increase complexity in your app, you need to add back react.
j45 · 24m ago
Maybe, maybe not. It's not the only sponge, unless it's the only sponge I know.
mhitza · 54m ago
The javascript people should stop innovating for a couple of years. To much innovation that lead nowhere. How many ways can one build a web javascript project?
Browser people should pick up slack and start developing sane components for the web. How about a backend-supporting combobox, or a standardized date picker across browsers? Then we wouldn't need to constantly innovate how we manage the state of those fundamental operating controls that browser still don't have in 2025.
mrsilencedogood · 44m ago
I think part of the problem is that browsers don't really serve their original purpose anymore.
Google functionally controls just enough of a monopoly via chrome that they can generally do whatever they want (and not do whatever they don't want to do). So that standards still mostly can't do anything google isn't enthusiastic about dumping dev time into.
And they're just barely not enough of a monopoly that they can't just go wild and actually turn the browser into a locked down capital-P Product. Safari and Firefox (in that order... much to my chagrin) are holding them back from that.
So browsers just kind of hang out, not doing too terribly much, when obviously there are strong technical forces that want the browser to finally finish morphing from a document viewer to an application runtime. Finally fulfill the dream of silverlight and java applets/JNLP and so on. But nobody wants to bother doing that if they don't get to control it (and firefox doesn't have the dev power to just trailblaze alone in OSS spirit).
So instead the js people just have to plow along doing their best with the app-runtime version of NAND chips since the incentives don't want to offer them anything better at the browser/platform level.
jgalt212 · 25m ago
> there are strong technical forces that want the browser to finally finish morphing from a document viewer to an application runtime
I really hope that never happens if only because the web dev on ramp will discourage anyone without preexisting technical chops.
kketch · 13m ago
React is the front end framework I've used the most when doing front end. It is and was sold as a simple and performant library to build interactive web apps, but things like its virtual dom was a very memory-hungry abstraction that immediately needed fixing.
Over the years we've had a cascade of APIs to convince us that React was easy: shouldComponentUpdate, hooks / useEffect's manual dependency array. It always felt like React spent most of its time solving problems it didn't need to solve in the first place if he didn't create itself those problems by having a not so great hard to use API. State derivation and computed properties and dependency graphs were already solved problems before React came and tried to explain to everyone that it knew better. The irony is that the ecosystem is now going back on signals / observer approach.
Now that I've finished complaining, I will probably keep using it in the future! (or Preact! which i feel always done a better job of reimplementing React or more, the fresh framework from the same author while I think still WIP is really promising too).
gagabity · 58m ago
To replace something with the momentum of React both as tech and an industry "standard" you are going to need something which provides an incredible leap forward and is pushed by someone with very deep pockets, its hard to see it happening. The negatives if any of React simply aren't big enough to go for a less popular framework
theturtle32 · 1h ago
I feel this with every fiber of my being. I used to do a TON of front-end work, some of it quite cutting edge, delivering highly performant user experiences in the browser that had previously been only thought possible in a native app. Back in like 2009-2015. I was deeply connected with the web standards fundamentals and how to leverage them mostly directly.
I detoured into heavier focus on backend work for quite a while, concurrent with the rise of React, and watched its rise with suspicion because it seemed like such an inefficient way to do things. That, and JSX's limitations around everything having to be an expression made me want to gauge out my eyes.
Still, React pushed and laid the foundation for some really important paradigm shifts in terms of state management. The path from the old mental models around state to a unidirectional flow of immutable data... re-learning a totally new mental model was painful, but important.
Even though it's been chaotic at times, React has delivered a lot of value in terms of innovation and how we conceptualize web application architecture.
But today, when you compare it to something like SolidJS, it's really clear to see how Solid delivers basically all the same benefits, but in an architecture that's both simpler and more performant. And in a way that's much easier to organize and reason about than React. You still get JSX, server components, reactive state management (actually a MUCH better and cleaner foundation for that) and any React dev could move to Solid with fairly little mental re-wiring of the neural pathways. It doesn't require you to really change anything about how you think about application architecture and structure. It just basically does everything React does but better, faster, and with drastically smaller bundle sizes.
Yet I still have to begrudgingly use React in several contexts because of the industry-wide inertia, and I really wish I didn't have to.
ironmagma · 55m ago
> It just basically does everything React does but better
SolidJS still has some major pain points; the one I found was not knowing whether a prop was a signal or needed to become one. The type system doesn't help much. In React, you know for sure that if your reference changes, the component reading that reference as a prop will re-render. In Solid, it's less clear whether the update will be observed.
dottjt · 51m ago
> Yet I still have to begrudgingly use React in several contexts because of the industry-wide inertia, and I really wish I didn't have to.
I think you'll find a lot of people begrudgingly have to work and really wish they didn't have to. That means using what they know, which means React. Which I totally get. People want to spend time with their kids, hobbies etc. Worst case, they might be caring for others, like their elderly parents.
EGreg · 56m ago
You don’t have to! I wonder what you think of this framework my company (mostly me) developed over the last decade, I am open sourcing it under MIT license: https://github.com/Qbix/Q.js
rimunroe · 3h ago
> Hooks addressed class component pain but introduced new kinds of complexity: dependency arrays, stale closures, and misused effects. Even React’s own docs emphasize restraint: “You Might Not Need an Effect”. Server Components improve time-to-first-byte, but add architectural complexity and new failure modes.
There are a lot of valid criticisms of React, but I don't think this is one of them. These problems are not really new with hooks. They're actually problems which existed in some form in the class component API. Taking them one at a time:
Dependency arrays: I cannot count the number of bugs I encountered which were due to a lifecycle containing some code which was supposed to be called when certain props or bits of state changed, but completely forgot to check one of them.
Stale closures: the second argument to setState allowed this exact bug. Also, people would bind methods in incorrect spots (such as in lifecycle methods) which has the same result.
Misused effects: at varying point, class components had access to the class constructor and the lifecycle methods componentWillMount, componentDidMount, componentWillReceiveProps, shouldComponentUpdate, componentWillUpdate, componentDidUpdate, componentWillUnmount (this is from memory and is definitely only partially complete). Misuse of these was incredibly common. An article like "You Might Not Need an Effect" but titled "You Might Not Need Lifecycle Methods" or "You Might Not Need the Second Parameter to setState" would have been very helpful in the past.
Hooks reduced the number of opportunities for making mistakes, make enumerating those opportunities easier, and, critically, made them easier to detect and warn users about.
typpilol · 23m ago
Prop testing with fast-check helps alot I've found for when little things change
bangaroo · 21m ago
realistically i've worked at very few companies whose delivery is held back meaningfully by the framework something is built in.
when there's friction, it's much more likely to come from poor planning, or constantly adding more functionality without stopping to reconsider architecture, or one of a thousand more organizational issues.
the innovation delivered by basically anyone working in software is extremely rarely a function of the tools they use to build the software, and many extremely successful products effectively started as CRUD apps, just organized in a way that really served a specific use case well.
the stuff i recall that truly transformed the way i've experienced the web - (what was at the time) AJAX, webGL, the canvas tag, websockets - tend to be shipped in the browser, and function equally well in basically any framework. i don't really think that i can point to a single new framework that truly changed the way i experience the web meaningfully.
react is probably the closest i can recall, but primarily because it was the one that caught on and made building really rich SPAs fashionable after the long slushy period of knockout and angular and backbone and handlebars and the thousand other disparate things cobbled together by every company. it catching on and taking over most of the industry meant people could move between jobs easier, contribute more quickly, and take easier advantage of countless libraries because they were either natively made for react or there was plenty of documentation and support for integrating them.
having that broad a universe of support might actually be a main source of innovation, when you think about it. having it be effortless to integrate basically anything in the js universe into your project because it's well-documented and has been done a thousand times means you can focus more easily on the unique parts of your project.
i'm definitely a little jaded, and 20ish years into my career i'm more business-minded than i was when i started, but i struggle to imagine a framework so profoundly and uniquely enabling of new things, that would have such a meaningful impact on my bottom line, that i would choose it and the trouble of hiring experienced engineers comfortable with it (or training new ones) when i could just bring on literally anyone in the entire industry, because basically all front-end devs are comfortable in react.
Alex_L_Wood · 3h ago
Good. I remember the times when there was a weekly new framework that would absolutely revolutionize the web frontend development.
Mobile development forums were having all-out wars regarding MVP vs MVVM vs VIPER vs ... vs ... yadda yadda.
Now I can just enjoy stable predictable tooling and I can benefit from tons of examples and documentation.
tracker1 · 3h ago
There's still a lot of new options that pop up... it's just that React is a "safe" choice for a lot of places/apps. I've pretty much stuck with React + Redux + MUI for close to a decade now. Currently working with Mantine instead of MUI, honestly similar enough that I don't mind.
But no one will use it, so it can be safely ignored. It's both a good thing and at the same time a shame.
zsimjee · 9m ago
The network effect gets compounded by LLMs/vibecoding. I'm not just talking about v0 or replit either. Fire a prompt at ChatGPT to build a web app and most of the time it will give you react components in return.
jgalt212 · 2m ago
Makes sense to me. I've read that LLMs are more competent in React than other frameworks.
the_other · 3m ago
Even if you tell it not to use React?
danielvinson · 3h ago
I think this article discounts the reasons behind frontend decisions... priorities are absolutely fast execution time and ease of hiring. There is very, very little reason to care about optimizing frontend performance for a vast majority of apps. Users just don't care. It doesn't make the company more money.
If a framework is easy to use and everyone knows it, it's simply the best choice for 90%+ of teams.
cosmic_cheese · 54m ago
> There is very, very little reason to care about optimizing frontend performance for a vast majority of apps. Users just don't care. It doesn't make the company more money.
There’s plenty of users who care, but when the competition is also all slow and heavy they don’t get any choice in the matter.
jonny_eh · 44m ago
It's usually not the framework that causes apps/sites to be slow.
cosmic_cheese · 41m ago
Not directly, but when you have devs who only know how to build with the framework and don’t have a grip on what’s going on under the hood or how it all interacts in the browser environment (increasingly common), performance is sure to take a hit.
croes · 3h ago
The UX for me went downhill the last 5-7 years.
I don’t know if it’s react but something changed. Pages load slow or even don’t, strange display errors, slow reaction times etc.
tracker1 · 3h ago
Too few run output analysis on their bundles or even track bundle sizes. There's a lot of kitchen sink repos, not to mention any number of other bottlenecks between the front end and back end. Worse across split teams for larger apps.
kjuulh · 27m ago
There is always a "better" thing. I do think that it is fine to have a bit of stability in the frontend space. Should react stay the default for the future, probably not, but it is fine if it stays that way for a while.
React is a good enough choice for a lot of problems, heck, going without a framework is often a good enough choice, we don't always have to choose the "best" option, because what we value might not actually be that important, over other important metrics. Signals might have performance, elm elegance and purity, etc, etc. But for 95% problems, and teams React is just fine.
A bonus is that I can come back to my project in a year, and not have to rewrite it because everything changed since then.
In Danish we say
> Stop mens legen er god
Stop, while you're still going strong (ish). React is plenty equipped to solve a lot of problems, it doesn't need to solve all of them.
hackingonempty · 1h ago
React (and Elm and the many other inspired frameworks) is a beautiful model for writing apps but because it is not the browser's model it is an instance of the "Inner Platform Effect" anti-pattern. The performance is never going to be as good as embracing the built in features of the browser and using minimal JS to accomplish the interaction you need.
Maybe it can be justified for real apps like desktop apps but the vast majority of web pages that use React could probably provide a better experience to users without it.
jauntywundrkind · 34m ago
To some degree, and to madlib your statement, alike how: C code is never going to be good as embracing the built-in features of the x86 asmcode and using minimal code to accomplish what you need.
Which is to say, that isn't really a goal or objective, imo: it's an unhealthy prediction for misoptimizations, to worship the vanilla.js performance above all past.
More-so, there were so many very very very unperformant web apps before React. So many incredibly bad ways to manipulate DOM. And the spiralling combinatorial possibilities of updating state yourself were gnarly, create enormous cognitive load on every dev in the org.
I know I've just written a pretty big anti- post.
But I feel both sides really strong. I don't want either extreme to be accepted. Inner Platform I see as good and necessary. But also I definitely hope for better someday, see us making lots of Inner Platforms, that might be much smaller / better organically interweaving Inner Platforms. Reacts flaws are significant, a full extra DOM, diffs, coarse grained updates (which I think maybe React Compiler tries to seek out?) all do so much but are a huge abstracting for an Inner Platforms, not necessary imo to what Inner Platforms would have to be. It's amazing how much React gets us, how much consistency & clarity of code & it's purpose (with its immediate mode ish rendering scheme), and the performance is overall stunningly good. But there certainly is significant overhead, lots of code to load & execution time for it. Rather than looking to return back, I want to look onwards.
The "Inner Platform" idea is an amazing & useful framing. I want WebComponents to let us escape this, to be some common system we can agree too, but I suspect even with WebComponents—if they get any broader traction—we will eventually see "inner platforms", paradigms for use and interlinkage that go beyond the very basics of HTML (although Invokers radically and excitingly open up the space of component interacting with components in standard ways!).
Maybe it's not so clear cut a decade+ later, but pieces like The Extensible Web Manifesto speak to a clear loud vocal acceptance of the web as a lower level platform, as a tool that can have higher level expressions built stop it. Theres an expectation of going further, architectures above. https://github.com/extensibleweb/manifesto
Imo it sucks that we near a decade of React Uber Alles, stealing the oxygen that would nourish the web's flourishing. And there's hope for using more of the putter platform: that React as an Inner Platform does a lot of reinvention that maybe ought not be necessary. I guess the question I want to ask is, how little can we make our Inner Platforms, while still retaining the legibility of architecture? Can we decompose that Inner Platform into smaller interoperable pieces, protocols, for how things signal and flow, rather than it being a monolithic platform? What of the Outter Platform could be better used for performance and inter-op, to de-interiorize?
It is dangerous and bad to me to demonize Inner Platforms, to attend only to notions of pure performance as the guiding factor. The karmic wheel imo needs to be going around faster harder, creating and destroying the inner platforms. We have a lot more to explore, have only a couple examples of what web architecture could be and right now the React Inner Platform is a thick boy of an Inner Platform. But it's not just getting rid of Inner Platform that's the goal.
maelito · 3h ago
Rewrite the first paragraph replacing "React" by "HTML".
React is mostly HTML driven by data. "HTML killed front end innovation". Well that enabled standards to build real use cases on it with a common ground.
Before React, the Web world was a mess. In 2025, you have lots of frameworks to explore. React did not kill front end innovation at all, it just became a standard that gives more common understanding to building a website.
skrebbel · 3h ago
> React is mostly HTML driven by data.
I wish! Mostly though, React is a terrible mess of hooks with weird rules, suspense, “use client”, pedantic docs, and millions of other idiosyncrasies that have no business being this mainstream.
I think most people agree that the core ideas are great. Eg composable components, props, unidirectional data flow etc. There’s a reason that all other reasonably popular frontend frameworks adopted these ideas. It’s great that React established them. It’s just a bit sad that React established them.
webstrand · 2h ago
I thought the way React did suspense was pretty elegant?
The component render function is pure, meaning you can re-render component without unwanted side-effects. So on encountering an unresolved promise, halt and throw the promise, then have the runtime catch the promise and re-execute the render when it resolves. I thought this was really an elegant way to introduce an asynchronous dependencies.
recursive · 57m ago
It only achieves purity by re-defining the pre-existing concept of "pure". Component state is not passed as an argument, and can affect the output of a render function. It's only by playing semantic games that react claims to be pure, which I find to be of dubious value in this domain anyway.
rimunroe · 2h ago
> pedantic docs
Are you referring to something in particular here? I've had my issues with the docs in the past, but I don't think I'd describe any of them being related to pedantry.
skrebbel · 2h ago
Yeah stuff like useEffect which is supposedly a function that "lets you synchronize a component with an external system" [0]
So eg when you want to focus an input, how do you do that? That's the input itself right, that's my core UI, that's not synchronizing, it's not an external system so I'm not supposed to use useEffect for that, right? That'd be bad, no?
Turns out I do need useEffect, and in fact it's the only way, barring using 3rd party hooks or components that, themselves, use useEffect for this. And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app! That's not an external system at all. It's as non-external as things can get and I'm not synchronizing anything, I'm focusing an input.
This entire "external system" story isn't at all about what useEffect is, it's not what it does, it's merely what the React designers have decided you should use it for.
useEffect lets you run side effects. That's it, that's all there is to it. But they rewrote the docs with total beginners in mind, and put them so full of dos and donts that they forgot to explain what stuff actually does. Gaaah.
And half the documentation is like this. It dances around the actual behavior, never really explicitly saying what things do or how they work, with huge rants about what I ought to do and no info, except maaayybe hidden in some expando, about how things actually work and why.
What's the condition in which you're trying to focus that input? Usually you're doing that in response to some sort of user action, in which case the time to handle that is within an event handler.
> And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app!
External systems usually means stuff like an event system, network requests, or something else not managed directly by React. Unless you're reaching outside the area of the DOM React is managing, you can usually do this in event handlers or (for spookier cases) ref callbacks. There are certainly exceptions, but it's often an architectural smell.
Further down in the docs you'll see[0]:
> Effects are an “escape hatch”: you use them when you need to “step outside React” and when there is no better built-in solution for your use case.
Actually, React's problem is that it's the inverse of how HTML and JavaScript works in terms of how to handle callbacks. Of the major UI frameworks, it is the only one with this quality (Vue, Svelte, Angular, Solid, etc. use signals).
This inverted behavior is the cause of most of the pain and footguns in React and React Hooks because the way state behaves in a React component is not the way state behaves in any other front-end JS one would normally write.
That's why I think for some folks who started with HTML + vanilla JS, React Hooks just feels wrong. It points the reactive callback to the component function whereas every other framework/library uses some sort of signal to point the reactive callback to a handler. Because React points the callback to the component function, then you have to be really cautious about where you put state inside of a component[0][1][2]
Even You wrote this about React's design choice which I think sums it up best:
> The pain and suffer[ing] of hooks all roots from the mismatch between a dogmatic belief in the superiority of immutability and the harsh reality of the host language that is JavaScript
If you want to "feel" this for yourself, here are a series of JSFiddles:
It should be obvious that Vanilla and Vue behave like how one would expect callbacks to work. React, because it points the callback to the component function, then requires that you be cognizant of state inside of the component function (placement, memoization, immutability, etc.). All of the pain of React is self-imposed from this design decision.
Technically in React, the reactive callback is still the event handler. It's a two-step process where your event handler is evaluated first, then re-evaluates the component tree which changed as a result of the handler. In your JSFiddle example, if you modify `onChange` to print a console log instead of setting state, you'll see that it doesn't run the component function again.
So really, the key difference between React and Vue is that your function component is not the setup, it's the template.
mrits · 3h ago
I disagree with everything you said and too emotional to respond right now
yladiz · 3h ago
Next time I would recommend to just wait until you’re less emotional and respond then. Your comment now doesn’t really add anything to the conversation, whereas one with a level head might.
jonny_eh · 45m ago
I make myself less emotional about internet comments by first assuming they're all written by bots :D
skrebbel · 3h ago
HN has a button exactly for that!
rendall · 3h ago
Enh. That button is often used for "your post gives me bad feelings" but it's supposed to be for "your post is bad for the community"
sarchertech · 19m ago
Go read pg’s comments on downvoting. HN has always been fine with using downvotes to signify disagreement.
scotty79 · 3h ago
Which one? Maybe there should be "reply later" button that would keep the spot for your future comment so you don't lose track of it?
webstrand · 2h ago
I sometimes use "favorite" for that.
rossant · 17m ago
In simple applications, can we replace JS frameworks by a document with guidelines and best practices?
What if I want to avoid frameworks and stick to vanilla JS, following instead good strategy and coding conventions for managing state, reacting to events, etc, all in pure JavaScript while avoiding spaghetti code. Does a document like this exist?
lbreakjai · 5m ago
It exists. It's called a framework.
ikrenji · 10m ago
so you want to avoid using a framework in order to basically code something in pure JS that does what the framework does? whats the point of that?
gdotdesign · 3h ago
With Mint (https://mint-lang.com/) I'm trying to move away from frameworks in a language to the language being the framework — having abstractions for things which are done by packages and frameworks like components, localization, routing, etc... done in the language itself.
This means that in theory the backend/runtime can be replaced (and was replaced ones from React to Preact (0.7.0 -> 0.8.0) then to use hooks and signals instead of class components (0.19.0 -> 0.20.0), and the code will remain the same.
This has one drawback which deters framework creators from choosing the language since there is no reason to innovate on something that is already "done", which leads to fewer people using it in general and hinders adoption, but I'm still optimistic.
theturtle32 · 3h ago
The Mint website is quite lovely! Props for making something so nice and pleasant and clean and easily navigable and informative.
gdotdesign · 3h ago
Thank you! And it's written in Mint :D
frabonacci · 38m ago
Really thoughtful piece. It reminds me of how Angular once dominated by default, until its complexity and inertia gave space for React. The same dynamic could be repeating now - React’s network effects create stability, but also risk suffocating innovation
nathan11 · 2h ago
"React by Default is Killing Front End Innovation" is probably a better headline for the post. It looks towards the present and the future, not how we got here.
All in all, this story has played out many times before, and will again. I think you either have adoption or you have a modern solution without technical debt. React had constraints that don't exist anymore that shaped its architecture, and now it has an enormous community that cannot turn on a dime.
Svelte, Solid, and Qwik have the benefit of hindsight and browser advancements. In 10 to 15 years time we'll be talking about a new batch of frameworks that have the same advantages over Svelte/Solid/Qwik.
djmashko2 · 20m ago
For what it's worth, very happy with React and excited to keep the inertia going. "Good enough" in this case is quite good.
duxup · 3h ago
With these articles I'm a little tired of them in that if your workplace can't possibly consider anything else and that's a big deal to you ... kinda feel like you've got a choice to make. Does that make sense for a given individual? Maybe.
Otherwise the front end land is still very dynamic and so on, I think it's great, there are lots of options.
If some boring insurance company doesn't pick the coolest new framework and picks react instead. I don't think that's a problem. Gotta go be with the cool kids to do the cool new things.
chairmansteve · 3h ago
Plus, I have no interest in front end innovation. I think HN and Craigslist are as good aw it gets.
appreciatorBus · 3h ago
The day we stop "innovating" in front end by inventing new UI's every month, global productivity is going to skyrocket.
efnx · 3h ago
I don’t think that will happen. There are still problems with React and folks are going to address those problems, sometimes by rolling a completely new UI layer.
jmcgough · 3h ago
> React didn’t win purely on technical merit
A sentence written by someone who clearly hasn't worked on a large Angular 1.x project.
johnfn · 3h ago
Yes, this is probably the wrongest statement. When React was launched, it was one in a pool of thousands of web frameworks. For any axis you want to claim that React won by "default", there was another framework that dominated React in that axis and lost anyways. Some frameworks had more resources and lost (Angular), some of which were more popular and lost (jQuery, Backbone), and some of which were even more hyped than React and lost (remember Meteor?).
React didn't win by default, it won because developers tried it and found it was better. It absolutely won on technical merit.
There's a bit of a question of whether React would still win on technical merit today, versus all the next-generation frameworks. I personally think it is still better than Svelte, Vue, etc, but I'm a bit of a React apologist.
ipaddr · 3m ago
It won by marketing and the angularjs to Angular breaking change. If they kept going with angularjs or had an upgrade path react wouldn't be default in the enterprise stack. That's all on Google.
Meteor was node framework. jQuery is probably still more popular but it is only a lib. Vue had a Chinese language problem.
React won because a framework by Facebook felt safe.
RussianCow · 3h ago
This. React was incredibly innovative at a time where the alternatives were some combination of:
* Two-way data binding spaghetti
* Boilerplate-heavy reactivity
* Opaque, framework-specific magic
* Manual state updates/transitions
React didn't win "by default" (whatever that means), it won because it was better than most of the other options at the time.
I agree that, on purely technical grounds, it isn't as strong of a framework as other competitors anymore, but React is and has always been Good Enough™ for most companies, to the point that it's not worth reaching for anything else most of the time. And I say this as someone who doesn't like most things about modern React.
andy_ppp · 3h ago
“Opaque, framework-specific magic”
Have you ever looked at the React source code…
AstroBen · 2h ago
Yeah, that's where the complexity is supposed to be
johnfn · 2h ago
All framework code has magic in it. But I posit that React uses magic internally so that we can write magic-free code. It's like how the Rust compiler contains unsafe code.
RussianCow · 2h ago
React was actually pretty simple in the early days. It's gotten significantly more complex because of hooks, suspense, SSR, and other features they've introduced more recently. But I would still take modern React over AngularJS 1 and I think it's far more explicit.
rimunroe · 2h ago
The source code for hooks when they were initially released was actually really straightforward too. It's been many years since I've read through other parts of the source code though.
OtherShrezzing · 56m ago
I always thought Angular 1.x was _fine_, so long as you had incredible discipline in your team and stuck to predefined patterns.
React’s main benefit wasn’t technical, it was organisational. It’s so opinionated that it’s difficult for an incompetent developer to introduce very low quality code into the project. Meanwhile in AngularJS, a developer with a clever implementation idea was a terrifying prospect for future productivity.
magundu · 3h ago
You are 100% right.
Maintaining angular.js for large scale app is pain.
sitzkrieg · 3h ago
here here, being involved with porting a huge angular 1 project to the first angular2 RCs (golden dev choice) was the worst frontend project i ever witnessed in my not short career :-)
spoiler · 3h ago
I'm working with a large Angular app, and my dev experience has been abysmal. TS language server running out of memory, Angular language server frequently crashes or freezes leaving weird half line diagnostics in its wake. Go to definitions are so slow in the proje too.
I've worked on 2x, if not 3x larger React codebase without these issues. I can't tell a single instance where language tooling was failing me so severely that I've contemplated turning it off because it's creating more uncertainty than its helping.
I'm relatively new to Angular 20 itself—only used Angular 1, and also migrated that project to React. So I'm not yet qualified to make big statements about it (but a preliminary gut feeling is that it often feels complex in the wrong places). C'est la vie though
sitzkrieg · 52m ago
i wasn't on the project for the entirety, but i certainly remember the new ng tooling getting heavier and heavier. once the apis settled down a bit people really started cranking uis out though
teaearlgraycold · 3h ago
If React is guilty of anything it’s being the first framework that was good enough to last a long time. Of course today we have hindsight and can make better alternatives. But replacing React at this point is harder because it’s been around for long enough that it’s become the standard.
scotty79 · 3h ago
Yeah, transcluded scopes and myriad of ad-hoc micro DSLs, one per each HTML attribute that needed any kind of smartness. And dependency injection to micromanage.
Fun times.
0x457 · 3h ago
Well, that's just argument against angular 1.x
jmcgough · 2h ago
Yes, but when React launched, 1.x was its main competition. We started to incorporate React into parts of our app that needed better performance, and found ourselves using it for essentially all our new projects. It was quick to pick up, made apps easier to reason about, and had much more performant DOM updates. Angular's two-way binding made for flashy demos, but quickly became a leaky abstraction for complex pages with lots of updates.
That was in 2013. Angular 2 came out in 2016, and by that point React had won. Have had to dabble in other frameworks since then, and none of them seem to do anything significantly better than React. I spent my early career learning a new FE framework every year, at this point I'm happy to have something boring that does what I need and has a great ecosystem around it.
darepublic · 3h ago
I remember the space being backbone (+ marionette!), and angular 1. webpack was a cool new confusing thing. enter react (with the mysterious redux). Purists said one should only use redux state and never local component state or context. Don't use refs! Don't you try to touch the dom! also jquery. my beautiful jquery. betrayed by the community, and cast out.
oytis · 3h ago
If frontend has finally settled on something, I am really happy for frontend devs. Changing frameworks every year should be really tiresome and hardly deserves to be called innovation
ebr4him · 3h ago
Not a single mention of 'Vue'
synergy20 · 34m ago
to me react is losing as I switched to vuejs and life is way more productive
ZpJuUuNaQ5 · 2h ago
>Killing Front End Innovation
Huh, I wish. This is loosely related, but early in my career I worked in a company where one of the projects I was involved in was a relatively large-scale web platform. The system had quite a lot of interactive UI elements, but for some reason we weren't allowed to use any off-the-shelf UI library/framework like React (it was already around for quite some time), despite presenting arguments countless times on why it would be the better solution and save a huge amount of time.
Instead, we had to use a buggy and incomplete UI library that was built within the company, and the results were as you'd expect. Making changes to the UI was agonizing, the library's behavior and API was inconsistent, components were difficult to reuse, and you had to jump through hoops and monkey-patched nonsense to update the UI. On top of that, nobody worked on fixing the library itself, and eventually the system using it grew so large that making any fixes to the library would break the system and would need a massive amount of time to fix or rewrite all the broken components. The saddest thing was that the UI library itself did not actually do anything "innovative", just some things that are available in countless other UI libraries, but worse.
Sure, maybe it was my technical incompetence and poor decisions, but on the other hand, even then, I knew JS/TS quite well and wasn't one of those people who swear by a particular framework and know nothing else. I worked on other web-based projects before with various technologies and never had that many problems.
throwmeaway222 · 3h ago
its kind of a blessing that SOMETHING won. We finally can just use a component. We don't have to worry about - oh I wish I could use that, but it's written in X framework.
croes · 3h ago
Now you’re forced to use react even for simple pages that just need that one component.
throwmeaway222 · 58m ago
Yeah, well we're often forced to just use something. Computers and cars are a good example of baseline things we're forced to use for some category of tasks.
duxup · 3h ago
Not optimal, but also easy peasy.
One thing I like about React is that if you want it can be very simple.
notapenny · 3h ago
Good. Innovation isn't the latest framework that barely improves the model and as much as front-end developers like to nit about bundle size, 100kb here and there isn't going to matter for most markets.
Honestly between React, Angular and Vue, there's enough jobs if you do want to specialise, but the mental model between the three isn't that different that a good engineer wouldn't be able to adapt.
React is boring old tech to me at this point and I'm happy with that. Like choosing Java, C# or Python for the back-end. I'd rather focus on innovating my clients products until something earth shattering comes along.
baq · 3h ago
If you build an OS in JavaScript please make sure it can unload programs.
…IOW not every app needs to be an SPA, but if it is, it’s still true that nobody needs most of it loaded at any given time. Give me my RAM back.
Filligree · 3h ago
That sounds like it would take extra work. I’ll leave it to the LLM.
AstroBen · 2h ago
The main gist of this seems to be that other frameworks beat React on performance.. but who cares? The speed difference in 99.99% of apps is one that no-one can perceive
React trades this very minor performance hit to give us better developer clarity through a functional paradigm. This makes complex state management much easier to manage
A better article could've been written for this title. I just don't care about improving renders by 3ms when it's already fast enough
I think the reason React won, and is still top dog, is that improvements to performance at this point aren't worth it if you have to give up something beneficial
legitster · 2h ago
I'm an old-school web guy. React is stupid easy, but by nature of things being easy it also encourages really bad habits.
Performance is one thing (the internet is getting slower! Impressively bad!), but also webapps are becoming so incredibly overdesigned, at the expense of the user experience.
Before we had the discrete fields of front-end engineering, design, UX, etc web design was inherently limited and we used standardized shorthands for everything across the industry. With React it's so easy to throw out best practices and try to redesign every single experience from scratch. Combine that with the Figma-fication of web design and teams can get lost making pixel perfect designs that are usability nightmares.
Let's be honest - what percentage of modern React websites actually provide a better user experience than Craigslist? It's fast, I'm not dealing with buttons that move around as a page loads, unusual text sizes at non-standard screen sizes, etc. (The famous McMaster-Carr website is another example).
hn_acc1 · 2m ago
Yeah, the "buttons that move as the page loads" is the single biggest thing I hate about the modern web. I go to click one, and in that instant, it's moved and replaced by a different one that I didn't want to click.
Then again, I'm hardly one to talk. The last time I wrote actual web code was JSPs in 2001. I did hack on some JS code to add dynamic table sorting to some html report pages I created later, but that's about it.. Never liked JS's idea of "we can be every programming language at once with the standards from none of them".. Sure, it's flexible, but so is a noodle..
skydhash · 31m ago
Hill I’m willing to die on (figuratively): Most websites should be readable on w3m (or lynx, or emacs’ ewww).
suchanlee · 47m ago
React is good, and is good enough. That and the ability to easily find React devs makes it a good enough choice for almost all front end applications.
For a new framework to be the default, it has to be a major step function improvement over React, like React was compared to other frameworks at the time like Angular, Ember, etc. I don't think I've seen that in any new frameworks yet.
eric-p7 · 3h ago
This seems like a good place to plug my library, Solarite.
It's a minimal, compilation-free JavaScript library that adds reactivity to native web components, as well as scoped styles and a few other ease-of-life features.
Reading through the example, it seems like it doesn't do reactivity, as the user code must call render() manually on state changes. Did I miss something?
eric-p7 · 3h ago
No, that's correct. I did it that way deliberately as a design choice.
Is that not still considered reactivity? If so then I'll update the docs.
sabellito · 19m ago
I'm definitely not the authority on the definition of that word, but in my view I expect reactivity to mean that the UI reacts to state changes "automatically".
SebastianKra · 2h ago
Why do these articles keep dismissing the innovations by React itself. The Svelte compiler is revolutionary, but the React compiler is not enough somehow. The React-Team has worked on server components, concurrent rendering, suspense & transitions. They all integrate with each other to allow for some really elegant patterns.
While the VDOM overhead does exist, it's not the performance bottleneck. More likely reasons are waterfall fetching (present in all frameworks and solvable by React Server Components) or excessive revalidation (solved by the compiler)
tracker1 · 3h ago
The premise is bullshit... there were LOTS of competing options when React first came out... it wasn't really until Redux hit that a lot of people started seriously using it. A lot of the flux implementations were painful, configuring Webpack was a pain, etc, etc.
It may be the default today, but it largely earned that position by being one of the better options out there. Today there's alternatives and even Angular still has a decent following, not that I'll touch it if I can avoid it.
edit: Just adding to the pain at the time... iirc Webpack + Babel + Sass + CSS + ReactTransforms each with wierd bespoke configuration options... Babel itself was a massive pain for even trying to limit to modern-ish targets or multi-target.
React itself was a bit awkward as well, a lot of the concepts themselves were difficult, and IMO, it didn't get much easier until functional components, even if that really complicated the library itself.
I still have mixed to poor feelings on Server Components as I think it's largely a waste for the types of things people typically build. HTMLX (speaking of innovation) is likely a better option in that space.
That said, I do like MUI (formerly Material-UI, a Material Design Implementation), I think the component architecture is really thoughtful and works well, biggest issue is that devs don't take the couple hours to read the docs and even have awareness of what's in that box.
I also like Redux and even hand-written reducers and extensions quite a bit.
kypro · 3h ago
React's dominance is genuinely baffling to me, and even more so popularity of Next.js.
In my experience React is rarely the best solution and adds a huge amount of complexity which is often completely unnecessary because React is rarely needed.
In the early days my very controversial view was that frontend developers tend to be fairly mediocre developers, and this is why a lot of frontend frameworks suck and frontend developers just mindlessly adopt whatever the hot new technology is with seemingly no concern for performance, maintainability, security, etc.
But honestly I'm not sure this explains it anymore... There are a lot of really talented frontend development teams out there working for companies with plenty of cash to try something different. I don't really understand why there's no serious competitor frameworks in terms of market share out there.
As far as I'm aware there's no analogies to this in other areas of the web tech stack. There's plenty of backend frameworks to pick from depending on the product. There's also plenty of competitive DBMSs, cloud providers, package managers, code editors, etc, etc. I don't understand why frontend development is so static in comparison because it's certainly not that React is the perfect solution for everything.
notapenny · 2h ago
For sure it isn't the perfect solution for everything, and I say that as someone who spends most of their time in either React or Angular now. For application-like development or just sites with tons of interaction it's become as standard as reaching for Spring or PSQL though.
I can't speak to the complexity you've encountered, but for me it's pretty much zero. A button component is just a function. React-Router is good enough and code splitting is pretty much just changing how to import something. Component state is dead-easy to write by just adding a useState hook. Bundlers pretty much handle everything these days so not to much concern about size.
Your view on front-end developers having been mediocre in the past isn't far off though, at least in my experience. I noticed a big difference between the people who wanted to build nice looking pages and the ones that wanted to build applications myself. Even today it amazes me how many people have never unit tested their code, have no idea about layering an application and have poor JS/TS fundamentals. It's gotten a lot better though.
Ultimately it isn't perfect for everything, but for a lot of people it's an easy choice. And for me personally, the tons of other JS frameworks do very little in that area that I'd pick them. I'd rather spend my time working on the product. Lol, maybe its just the default because its the default at this point.
estimator7292 · 39m ago
The first programming language I learned was Java as a teenager. When I started actually programming as an adult, I used C#. As my career has gone on, it's been on a very definite path down the layers of abstraction and now I write C and assembly.
I just got a new job and my first task is fixing up a vibe coded react native app. Holy hell I have never hated programming more than I do now. The absolute mess that is type/JavaScript and the very notion of running your app as an embedded website is quite possibly the worst thing I can imagine. The whole language and ecosystem appears to deliberately make debugging as hard as possible. Things that should be compile-time errors are instead runtime errors that may or may not produce a log in one of three or four locations.
I really want to go back to C. I hate this so much.
Maybe JavaScript works for you, that's great. But my brain runs on C and java just makes me want to find a cave and subsist on berries and twigs for the rest of my life.
skydhash · 33m ago
The ecosystem culture is one that actively look for complexity. Your only hope is to be defensive from dependencies. Isolate them and have a core of serenity to handle business logic changes. Once in a while, go visit your dependencies shell to update them.
EGreg · 57m ago
Well, if you want a more lightweight alternative, that is actually more powerful, spend an hour with this:
I will release a playground soon on qbix.org so you can try it out. You can use it alongside React and Angular
juancn · 2h ago
It could be a good thing.
Front end engineering has been a perpetual chase for The Shiny Thing™, constantly changing, with good excuses, but way too often throwing everything away and starting from scratch, forcing a perpetual catch up and periodic rewrites of everything.
Some maturity and a slower pace of change could be a good thing.
I mean, innovation is still happening, but it's not compelling enough to drop React for most apparently (at least not yet).
leptons · 3h ago
Front-end has seen plenty of innovation, so much that it causes a lot of burnout. So many people seem to want to reinvent the wheel for various reasons - to get recognition, to do things their own way, etc., while the existing trending tech hardly sees the surface scratched and continues to work just fine for most workloads.
>“But proven at scale!” jQuery was proven at scale too. Past success doesn’t guarantee future relevance.
jQuery is still one of the most used front-end libraries, used on 80%+ of all websites. It's easy, it gets the job done, and a lot of sites don't require more than jQuery. jQueryUI can actually do a lot of stuff to build basic web applications. React and every other tech mentioned in the article is just too heavy for most website needs. When you need a build step, that increases the complexity and requirement for developer resources compared to something simple like jQuery, which is probably why jQuery still gets used so much.
vkou · 3h ago
JQuery has plenty of good functionality, but you're going to have a really bad time building non-trivial applications as a team if that's all you are using.
Because it's just a library, not an opinionated framework, keeping everything consistent across a development team of varied tenure and experience levels will be a herculean effort.
mrcwinn · 3h ago
This is mostly nonsense. Moving on.
brianbest101 · 3h ago
IIRC it was quite a fight for react, it wasn’t a slam dunk out of the gate.
azemetre · 21m ago
Was there? By 2016 it felt like nearly 80% of frontend development was happening in react. Even startups in central FL in 2015 were all in on react then. That's barely 4ish years from first introduction. That's quite fast in software adoption.
tracker1 · 3h ago
Not in the least... that first year hardly anyone would even touch it... "eww you have html in your js."
Personally, I loved it... React + Redux + MUI = Winning (IMO)
If React starts taking a backseat, it'll be because its no longer really good. And, to be fair: I've started to see this happen. Next & Vercel have totally taken over the React world, and they've proven to make quite poor architectural decisions. All great empires are destroyed from the inside, not out, and I think its possible Vercel could do this to React. But, also, even as Next seppukus itself, people will likely just fall back to React on Vite (or, there's Remix 3 that's I think still under development, but might end up being big).
But, also yes, it's a pain in the ass and a frustrating kind of necessary evil. So there is room for improvements.
Nextjs is a living hell. The ironic thing is AI makes it dramatically more tolerable to the point it's actually pretty good. But that can't be a good thing in terms of architectural design can it? We're in odd times.
Of course, it's easy to be a hater on the sidelines. I am guilty. Nextjs likely just does too much in it's own made-from-scratch clever way. use-client vs server is just out-of-the gate ridiculous. But then I suppose the real question is "well if you want isomorphic environment, how else are you going to do it?". My answers is "I wouldn't!" but then vercel and the powers that be seem to have won the mindshare of the product crowd. At least for now.
Note that this is neither a major compliment to React's technical merits nor a criticism of React's competitors. In fact, I don't even disagree with the author on some of his claims, such as:
> React is no longer winning by technical merit. Today it is winning by default.
> That reflex creates a self-perpetuating cycle where network effects, rather than technical fit, decide architecture.
I agree! But teams are still largely choosing the better option, because the benefits of React are indeed outweighing the benefits of choosing an alternative. What the author is missing is simply that the technical benefits of an alternative are small except in narrow use cases. And I suspect most competent teams do in fact identify if they're in those narrow use cases and correctly choose an alternative.
Not all problems are complex to begin with, and having a complex tool as default otherwise adds complexity to the project and also inflexibility to iterate quickly.
This is in addition to having to maintain a relatively brittle ecosystem from past feature as well as future features but that can be true for more than one area of JavaScript or other technologies.
Looking for the next curve to emerge out of the current generation of web app building.
But where React fails is actually in more complex scenarios. Prop drilling becomes tedious or intractable, so now we have all these different ways to manage state (Context, Redux, MobX, Recoil, Zustand, Jotai...). Your re-rendering gets slow, so now you need to start sprinkling React.memo() all over the place and adding reselect (or re-reselect!) queries and restructuring or denormalizing your store data, but then it turns out some of your props are objects that are regenerating each render cycle, so you need to memoize those too, and you end up on a wild goose chase there. Or your engineers were sloppy and accidentally put some side-effects into your components, so you've got subtle bugs you're not sure how to fix. And there's a lot of complexity or even unanswered questions around things like robustly fetching data your component needs, and maybe React Router answers them but then you end up down a whole other rabbit hole, especially when a new version of React Router comes out and breaks everything.
Browser people should pick up slack and start developing sane components for the web. How about a backend-supporting combobox, or a standardized date picker across browsers? Then we wouldn't need to constantly innovate how we manage the state of those fundamental operating controls that browser still don't have in 2025.
Google functionally controls just enough of a monopoly via chrome that they can generally do whatever they want (and not do whatever they don't want to do). So that standards still mostly can't do anything google isn't enthusiastic about dumping dev time into.
And they're just barely not enough of a monopoly that they can't just go wild and actually turn the browser into a locked down capital-P Product. Safari and Firefox (in that order... much to my chagrin) are holding them back from that.
So browsers just kind of hang out, not doing too terribly much, when obviously there are strong technical forces that want the browser to finally finish morphing from a document viewer to an application runtime. Finally fulfill the dream of silverlight and java applets/JNLP and so on. But nobody wants to bother doing that if they don't get to control it (and firefox doesn't have the dev power to just trailblaze alone in OSS spirit).
So instead the js people just have to plow along doing their best with the app-runtime version of NAND chips since the incentives don't want to offer them anything better at the browser/platform level.
I really hope that never happens if only because the web dev on ramp will discourage anyone without preexisting technical chops.
Over the years we've had a cascade of APIs to convince us that React was easy: shouldComponentUpdate, hooks / useEffect's manual dependency array. It always felt like React spent most of its time solving problems it didn't need to solve in the first place if he didn't create itself those problems by having a not so great hard to use API. State derivation and computed properties and dependency graphs were already solved problems before React came and tried to explain to everyone that it knew better. The irony is that the ecosystem is now going back on signals / observer approach.
Now that I've finished complaining, I will probably keep using it in the future! (or Preact! which i feel always done a better job of reimplementing React or more, the fresh framework from the same author while I think still WIP is really promising too).
I detoured into heavier focus on backend work for quite a while, concurrent with the rise of React, and watched its rise with suspicion because it seemed like such an inefficient way to do things. That, and JSX's limitations around everything having to be an expression made me want to gauge out my eyes.
Still, React pushed and laid the foundation for some really important paradigm shifts in terms of state management. The path from the old mental models around state to a unidirectional flow of immutable data... re-learning a totally new mental model was painful, but important.
Even though it's been chaotic at times, React has delivered a lot of value in terms of innovation and how we conceptualize web application architecture.
But today, when you compare it to something like SolidJS, it's really clear to see how Solid delivers basically all the same benefits, but in an architecture that's both simpler and more performant. And in a way that's much easier to organize and reason about than React. You still get JSX, server components, reactive state management (actually a MUCH better and cleaner foundation for that) and any React dev could move to Solid with fairly little mental re-wiring of the neural pathways. It doesn't require you to really change anything about how you think about application architecture and structure. It just basically does everything React does but better, faster, and with drastically smaller bundle sizes.
Yet I still have to begrudgingly use React in several contexts because of the industry-wide inertia, and I really wish I didn't have to.
SolidJS still has some major pain points; the one I found was not knowing whether a prop was a signal or needed to become one. The type system doesn't help much. In React, you know for sure that if your reference changes, the component reading that reference as a prop will re-render. In Solid, it's less clear whether the update will be observed.
I think you'll find a lot of people begrudgingly have to work and really wish they didn't have to. That means using what they know, which means React. Which I totally get. People want to spend time with their kids, hobbies etc. Worst case, they might be caring for others, like their elderly parents.
There are a lot of valid criticisms of React, but I don't think this is one of them. These problems are not really new with hooks. They're actually problems which existed in some form in the class component API. Taking them one at a time:
Dependency arrays: I cannot count the number of bugs I encountered which were due to a lifecycle containing some code which was supposed to be called when certain props or bits of state changed, but completely forgot to check one of them.
Stale closures: the second argument to setState allowed this exact bug. Also, people would bind methods in incorrect spots (such as in lifecycle methods) which has the same result.
Misused effects: at varying point, class components had access to the class constructor and the lifecycle methods componentWillMount, componentDidMount, componentWillReceiveProps, shouldComponentUpdate, componentWillUpdate, componentDidUpdate, componentWillUnmount (this is from memory and is definitely only partially complete). Misuse of these was incredibly common. An article like "You Might Not Need an Effect" but titled "You Might Not Need Lifecycle Methods" or "You Might Not Need the Second Parameter to setState" would have been very helpful in the past.
Hooks reduced the number of opportunities for making mistakes, make enumerating those opportunities easier, and, critically, made them easier to detect and warn users about.
when there's friction, it's much more likely to come from poor planning, or constantly adding more functionality without stopping to reconsider architecture, or one of a thousand more organizational issues.
the innovation delivered by basically anyone working in software is extremely rarely a function of the tools they use to build the software, and many extremely successful products effectively started as CRUD apps, just organized in a way that really served a specific use case well.
the stuff i recall that truly transformed the way i've experienced the web - (what was at the time) AJAX, webGL, the canvas tag, websockets - tend to be shipped in the browser, and function equally well in basically any framework. i don't really think that i can point to a single new framework that truly changed the way i experience the web meaningfully.
react is probably the closest i can recall, but primarily because it was the one that caught on and made building really rich SPAs fashionable after the long slushy period of knockout and angular and backbone and handlebars and the thousand other disparate things cobbled together by every company. it catching on and taking over most of the industry meant people could move between jobs easier, contribute more quickly, and take easier advantage of countless libraries because they were either natively made for react or there was plenty of documentation and support for integrating them.
having that broad a universe of support might actually be a main source of innovation, when you think about it. having it be effortless to integrate basically anything in the js universe into your project because it's well-documented and has been done a thousand times means you can focus more easily on the unique parts of your project.
i'm definitely a little jaded, and 20ish years into my career i'm more business-minded than i was when i started, but i struggle to imagine a framework so profoundly and uniquely enabling of new things, that would have such a meaningful impact on my bottom line, that i would choose it and the trouble of hiring experienced engineers comfortable with it (or training new ones) when i could just bring on literally anyone in the entire industry, because basically all front-end devs are comfortable in react.
Mobile development forums were having all-out wars regarding MVP vs MVVM vs VIPER vs ... vs ... yadda yadda.
Now I can just enjoy stable predictable tooling and I can benefit from tons of examples and documentation.
If a framework is easy to use and everyone knows it, it's simply the best choice for 90%+ of teams.
There’s plenty of users who care, but when the competition is also all slow and heavy they don’t get any choice in the matter.
React is a good enough choice for a lot of problems, heck, going without a framework is often a good enough choice, we don't always have to choose the "best" option, because what we value might not actually be that important, over other important metrics. Signals might have performance, elm elegance and purity, etc, etc. But for 95% problems, and teams React is just fine.
A bonus is that I can come back to my project in a year, and not have to rewrite it because everything changed since then.
In Danish we say
> Stop mens legen er god
Stop, while you're still going strong (ish). React is plenty equipped to solve a lot of problems, it doesn't need to solve all of them.
Maybe it can be justified for real apps like desktop apps but the vast majority of web pages that use React could probably provide a better experience to users without it.
Which is to say, that isn't really a goal or objective, imo: it's an unhealthy prediction for misoptimizations, to worship the vanilla.js performance above all past.
More-so, there were so many very very very unperformant web apps before React. So many incredibly bad ways to manipulate DOM. And the spiralling combinatorial possibilities of updating state yourself were gnarly, create enormous cognitive load on every dev in the org.
I know I've just written a pretty big anti- post.
But I feel both sides really strong. I don't want either extreme to be accepted. Inner Platform I see as good and necessary. But also I definitely hope for better someday, see us making lots of Inner Platforms, that might be much smaller / better organically interweaving Inner Platforms. Reacts flaws are significant, a full extra DOM, diffs, coarse grained updates (which I think maybe React Compiler tries to seek out?) all do so much but are a huge abstracting for an Inner Platforms, not necessary imo to what Inner Platforms would have to be. It's amazing how much React gets us, how much consistency & clarity of code & it's purpose (with its immediate mode ish rendering scheme), and the performance is overall stunningly good. But there certainly is significant overhead, lots of code to load & execution time for it. Rather than looking to return back, I want to look onwards.
The "Inner Platform" idea is an amazing & useful framing. I want WebComponents to let us escape this, to be some common system we can agree too, but I suspect even with WebComponents—if they get any broader traction—we will eventually see "inner platforms", paradigms for use and interlinkage that go beyond the very basics of HTML (although Invokers radically and excitingly open up the space of component interacting with components in standard ways!).
Maybe it's not so clear cut a decade+ later, but pieces like The Extensible Web Manifesto speak to a clear loud vocal acceptance of the web as a lower level platform, as a tool that can have higher level expressions built stop it. Theres an expectation of going further, architectures above. https://github.com/extensibleweb/manifesto
Imo it sucks that we near a decade of React Uber Alles, stealing the oxygen that would nourish the web's flourishing. And there's hope for using more of the putter platform: that React as an Inner Platform does a lot of reinvention that maybe ought not be necessary. I guess the question I want to ask is, how little can we make our Inner Platforms, while still retaining the legibility of architecture? Can we decompose that Inner Platform into smaller interoperable pieces, protocols, for how things signal and flow, rather than it being a monolithic platform? What of the Outter Platform could be better used for performance and inter-op, to de-interiorize?
It is dangerous and bad to me to demonize Inner Platforms, to attend only to notions of pure performance as the guiding factor. The karmic wheel imo needs to be going around faster harder, creating and destroying the inner platforms. We have a lot more to explore, have only a couple examples of what web architecture could be and right now the React Inner Platform is a thick boy of an Inner Platform. But it's not just getting rid of Inner Platform that's the goal.
React is mostly HTML driven by data. "HTML killed front end innovation". Well that enabled standards to build real use cases on it with a common ground.
Before React, the Web world was a mess. In 2025, you have lots of frameworks to explore. React did not kill front end innovation at all, it just became a standard that gives more common understanding to building a website.
I wish! Mostly though, React is a terrible mess of hooks with weird rules, suspense, “use client”, pedantic docs, and millions of other idiosyncrasies that have no business being this mainstream.
I think most people agree that the core ideas are great. Eg composable components, props, unidirectional data flow etc. There’s a reason that all other reasonably popular frontend frameworks adopted these ideas. It’s great that React established them. It’s just a bit sad that React established them.
The component render function is pure, meaning you can re-render component without unwanted side-effects. So on encountering an unresolved promise, halt and throw the promise, then have the runtime catch the promise and re-execute the render when it resolves. I thought this was really an elegant way to introduce an asynchronous dependencies.
Are you referring to something in particular here? I've had my issues with the docs in the past, but I don't think I'd describe any of them being related to pedantry.
So eg when you want to focus an input, how do you do that? That's the input itself right, that's my core UI, that's not synchronizing, it's not an external system so I'm not supposed to use useEffect for that, right? That'd be bad, no?
Turns out I do need useEffect, and in fact it's the only way, barring using 3rd party hooks or components that, themselves, use useEffect for this. And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app! That's not an external system at all. It's as non-external as things can get and I'm not synchronizing anything, I'm focusing an input.
This entire "external system" story isn't at all about what useEffect is, it's not what it does, it's merely what the React designers have decided you should use it for.
useEffect lets you run side effects. That's it, that's all there is to it. But they rewrote the docs with total beginners in mind, and put them so full of dos and donts that they forgot to explain what stuff actually does. Gaaah.
And half the documentation is like this. It dances around the actual behavior, never really explicitly saying what things do or how they work, with huge rants about what I ought to do and no info, except maaayybe hidden in some expando, about how things actually work and why.
[0] https://react.dev/reference/react/useEffect
> And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app!
External systems usually means stuff like an event system, network requests, or something else not managed directly by React. Unless you're reaching outside the area of the DOM React is managing, you can usually do this in event handlers or (for spookier cases) ref callbacks. There are certainly exceptions, but it's often an architectural smell.
Further down in the docs you'll see[0]:
> Effects are an “escape hatch”: you use them when you need to “step outside React” and when there is no better built-in solution for your use case.
[0] https://react.dev/reference/react/useEffect#wrapping-effects...
This inverted behavior is the cause of most of the pain and footguns in React and React Hooks because the way state behaves in a React component is not the way state behaves in any other front-end JS one would normally write.
That's why I think for some folks who started with HTML + vanilla JS, React Hooks just feels wrong. It points the reactive callback to the component function whereas every other framework/library uses some sort of signal to point the reactive callback to a handler. Because React points the callback to the component function, then you have to be really cautious about where you put state inside of a component[0][1][2]
Even You wrote this about React's design choice which I think sums it up best:
If you want to "feel" this for yourself, here are a series of JSFiddles:- Vanilla: https://jsfiddle.net/qtmkbdo2/8/
- Vue: https://jsfiddle.net/vys2rmup
- React: https://jsfiddle.net/0gjckrae/1/
It should be obvious that Vanilla and Vue behave like how one would expect callbacks to work. React, because it points the callback to the component function, then requires that you be cognizant of state inside of the component function (placement, memoization, immutability, etc.). All of the pain of React is self-imposed from this design decision.
You can read more about it here: https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo...
--
[0] https://adevnadia.medium.com/i-tried-react-compiler-today-an...
[1] https://tkdodo.eu/blog/the-useless-use-callback
[2] https://adevnadia.medium.com/react-re-renders-guide-why-reac...
So really, the key difference between React and Vue is that your function component is not the setup, it's the template.
What if I want to avoid frameworks and stick to vanilla JS, following instead good strategy and coding conventions for managing state, reacting to events, etc, all in pure JavaScript while avoiding spaghetti code. Does a document like this exist?
This means that in theory the backend/runtime can be replaced (and was replaced ones from React to Preact (0.7.0 -> 0.8.0) then to use hooks and signals instead of class components (0.19.0 -> 0.20.0), and the code will remain the same.
This has one drawback which deters framework creators from choosing the language since there is no reason to innovate on something that is already "done", which leads to fewer people using it in general and hinders adoption, but I'm still optimistic.
All in all, this story has played out many times before, and will again. I think you either have adoption or you have a modern solution without technical debt. React had constraints that don't exist anymore that shaped its architecture, and now it has an enormous community that cannot turn on a dime.
Svelte, Solid, and Qwik have the benefit of hindsight and browser advancements. In 10 to 15 years time we'll be talking about a new batch of frameworks that have the same advantages over Svelte/Solid/Qwik.
Otherwise the front end land is still very dynamic and so on, I think it's great, there are lots of options.
If some boring insurance company doesn't pick the coolest new framework and picks react instead. I don't think that's a problem. Gotta go be with the cool kids to do the cool new things.
A sentence written by someone who clearly hasn't worked on a large Angular 1.x project.
React didn't win by default, it won because developers tried it and found it was better. It absolutely won on technical merit.
There's a bit of a question of whether React would still win on technical merit today, versus all the next-generation frameworks. I personally think it is still better than Svelte, Vue, etc, but I'm a bit of a React apologist.
Meteor was node framework. jQuery is probably still more popular but it is only a lib. Vue had a Chinese language problem.
React won because a framework by Facebook felt safe.
* Two-way data binding spaghetti
* Boilerplate-heavy reactivity
* Opaque, framework-specific magic
* Manual state updates/transitions
React didn't win "by default" (whatever that means), it won because it was better than most of the other options at the time.
I agree that, on purely technical grounds, it isn't as strong of a framework as other competitors anymore, but React is and has always been Good Enough™ for most companies, to the point that it's not worth reaching for anything else most of the time. And I say this as someone who doesn't like most things about modern React.
Have you ever looked at the React source code…
React’s main benefit wasn’t technical, it was organisational. It’s so opinionated that it’s difficult for an incompetent developer to introduce very low quality code into the project. Meanwhile in AngularJS, a developer with a clever implementation idea was a terrifying prospect for future productivity.
I've worked on 2x, if not 3x larger React codebase without these issues. I can't tell a single instance where language tooling was failing me so severely that I've contemplated turning it off because it's creating more uncertainty than its helping.
I'm relatively new to Angular 20 itself—only used Angular 1, and also migrated that project to React. So I'm not yet qualified to make big statements about it (but a preliminary gut feeling is that it often feels complex in the wrong places). C'est la vie though
Fun times.
That was in 2013. Angular 2 came out in 2016, and by that point React had won. Have had to dabble in other frameworks since then, and none of them seem to do anything significantly better than React. I spent my early career learning a new FE framework every year, at this point I'm happy to have something boring that does what I need and has a great ecosystem around it.
Huh, I wish. This is loosely related, but early in my career I worked in a company where one of the projects I was involved in was a relatively large-scale web platform. The system had quite a lot of interactive UI elements, but for some reason we weren't allowed to use any off-the-shelf UI library/framework like React (it was already around for quite some time), despite presenting arguments countless times on why it would be the better solution and save a huge amount of time.
Instead, we had to use a buggy and incomplete UI library that was built within the company, and the results were as you'd expect. Making changes to the UI was agonizing, the library's behavior and API was inconsistent, components were difficult to reuse, and you had to jump through hoops and monkey-patched nonsense to update the UI. On top of that, nobody worked on fixing the library itself, and eventually the system using it grew so large that making any fixes to the library would break the system and would need a massive amount of time to fix or rewrite all the broken components. The saddest thing was that the UI library itself did not actually do anything "innovative", just some things that are available in countless other UI libraries, but worse.
Sure, maybe it was my technical incompetence and poor decisions, but on the other hand, even then, I knew JS/TS quite well and wasn't one of those people who swear by a particular framework and know nothing else. I worked on other web-based projects before with various technologies and never had that many problems.
One thing I like about React is that if you want it can be very simple.
Honestly between React, Angular and Vue, there's enough jobs if you do want to specialise, but the mental model between the three isn't that different that a good engineer wouldn't be able to adapt.
React is boring old tech to me at this point and I'm happy with that. Like choosing Java, C# or Python for the back-end. I'd rather focus on innovating my clients products until something earth shattering comes along.
…IOW not every app needs to be an SPA, but if it is, it’s still true that nobody needs most of it loaded at any given time. Give me my RAM back.
React trades this very minor performance hit to give us better developer clarity through a functional paradigm. This makes complex state management much easier to manage
A better article could've been written for this title. I just don't care about improving renders by 3ms when it's already fast enough
I think the reason React won, and is still top dog, is that improvements to performance at this point aren't worth it if you have to give up something beneficial
Performance is one thing (the internet is getting slower! Impressively bad!), but also webapps are becoming so incredibly overdesigned, at the expense of the user experience.
Before we had the discrete fields of front-end engineering, design, UX, etc web design was inherently limited and we used standardized shorthands for everything across the industry. With React it's so easy to throw out best practices and try to redesign every single experience from scratch. Combine that with the Figma-fication of web design and teams can get lost making pixel perfect designs that are usability nightmares.
Let's be honest - what percentage of modern React websites actually provide a better user experience than Craigslist? It's fast, I'm not dealing with buttons that move around as a page loads, unusual text sizes at non-standard screen sizes, etc. (The famous McMaster-Carr website is another example).
Then again, I'm hardly one to talk. The last time I wrote actual web code was JSPs in 2001. I did hack on some JS code to add dynamic table sorting to some html report pages I created later, but that's about it.. Never liked JS's idea of "we can be every programming language at once with the standards from none of them".. Sure, it's flexible, but so is a noodle..
For a new framework to be the default, it has to be a major step function improvement over React, like React was compared to other frameworks at the time like Angular, Ember, etc. I don't think I've seen that in any new frameworks yet.
It's a minimal, compilation-free JavaScript library that adds reactivity to native web components, as well as scoped styles and a few other ease-of-life features.
https://vorticode.github.io/solarite/
Is that not still considered reactivity? If so then I'll update the docs.
While the VDOM overhead does exist, it's not the performance bottleneck. More likely reasons are waterfall fetching (present in all frameworks and solvable by React Server Components) or excessive revalidation (solved by the compiler)
It may be the default today, but it largely earned that position by being one of the better options out there. Today there's alternatives and even Angular still has a decent following, not that I'll touch it if I can avoid it.
edit: Just adding to the pain at the time... iirc Webpack + Babel + Sass + CSS + ReactTransforms each with wierd bespoke configuration options... Babel itself was a massive pain for even trying to limit to modern-ish targets or multi-target.
React itself was a bit awkward as well, a lot of the concepts themselves were difficult, and IMO, it didn't get much easier until functional components, even if that really complicated the library itself.
I still have mixed to poor feelings on Server Components as I think it's largely a waste for the types of things people typically build. HTMLX (speaking of innovation) is likely a better option in that space.
That said, I do like MUI (formerly Material-UI, a Material Design Implementation), I think the component architecture is really thoughtful and works well, biggest issue is that devs don't take the couple hours to read the docs and even have awareness of what's in that box.
I also like Redux and even hand-written reducers and extensions quite a bit.
In my experience React is rarely the best solution and adds a huge amount of complexity which is often completely unnecessary because React is rarely needed.
In the early days my very controversial view was that frontend developers tend to be fairly mediocre developers, and this is why a lot of frontend frameworks suck and frontend developers just mindlessly adopt whatever the hot new technology is with seemingly no concern for performance, maintainability, security, etc.
But honestly I'm not sure this explains it anymore... There are a lot of really talented frontend development teams out there working for companies with plenty of cash to try something different. I don't really understand why there's no serious competitor frameworks in terms of market share out there.
As far as I'm aware there's no analogies to this in other areas of the web tech stack. There's plenty of backend frameworks to pick from depending on the product. There's also plenty of competitive DBMSs, cloud providers, package managers, code editors, etc, etc. I don't understand why frontend development is so static in comparison because it's certainly not that React is the perfect solution for everything.
I can't speak to the complexity you've encountered, but for me it's pretty much zero. A button component is just a function. React-Router is good enough and code splitting is pretty much just changing how to import something. Component state is dead-easy to write by just adding a useState hook. Bundlers pretty much handle everything these days so not to much concern about size.
Your view on front-end developers having been mediocre in the past isn't far off though, at least in my experience. I noticed a big difference between the people who wanted to build nice looking pages and the ones that wanted to build applications myself. Even today it amazes me how many people have never unit tested their code, have no idea about layering an application and have poor JS/TS fundamentals. It's gotten a lot better though.
Ultimately it isn't perfect for everything, but for a lot of people it's an easy choice. And for me personally, the tons of other JS frameworks do very little in that area that I'd pick them. I'd rather spend my time working on the product. Lol, maybe its just the default because its the default at this point.
I just got a new job and my first task is fixing up a vibe coded react native app. Holy hell I have never hated programming more than I do now. The absolute mess that is type/JavaScript and the very notion of running your app as an embedded website is quite possibly the worst thing I can imagine. The whole language and ecosystem appears to deliberately make debugging as hard as possible. Things that should be compile-time errors are instead runtime errors that may or may not produce a log in one of three or four locations.
I really want to go back to C. I hate this so much.
Maybe JavaScript works for you, that's great. But my brain runs on C and java just makes me want to find a cave and subsist on berries and twigs for the rest of my life.
https://github.com/Qbix/Q.js
I will release a playground soon on qbix.org so you can try it out. You can use it alongside React and Angular
Front end engineering has been a perpetual chase for The Shiny Thing™, constantly changing, with good excuses, but way too often throwing everything away and starting from scratch, forcing a perpetual catch up and periodic rewrites of everything.
Some maturity and a slower pace of change could be a good thing.
I mean, innovation is still happening, but it's not compelling enough to drop React for most apparently (at least not yet).
>“But proven at scale!” jQuery was proven at scale too. Past success doesn’t guarantee future relevance.
jQuery is still one of the most used front-end libraries, used on 80%+ of all websites. It's easy, it gets the job done, and a lot of sites don't require more than jQuery. jQueryUI can actually do a lot of stuff to build basic web applications. React and every other tech mentioned in the article is just too heavy for most website needs. When you need a build step, that increases the complexity and requirement for developer resources compared to something simple like jQuery, which is probably why jQuery still gets used so much.
Because it's just a library, not an opinionated framework, keeping everything consistent across a development team of varied tenure and experience levels will be a herculean effort.
Personally, I loved it... React + Redux + MUI = Winning (IMO)