React isn't winning by default. It's been so effective, so well designed that it's lived long enough to become the defacto standard... and the villian.

Claiming React is slowing innovation is an absolutely bonkers take when React is essentially the only sane stable choice in a sea of "me too" frameworks and libraries with conflicting and confusing design choices.

Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem.

While a lot of people view web components as competitors to frameworks, they don't really have to be. The just define an interface between component implementations and browsers so enable interop and reliable composition.

On top of the low-level APIs frameworks have a lot of room to innovate and customize:

- There is a huge range of possibilities an opinions on how to author components. Buildless, JSX, template literals, custom syntaxes and compilers, class-based, functional, etc.

- There is a lot room for gluing components together in different ways: custom component loaders, context protocols, SSR, suspense-like utilities, styling and theming frameworks, etc.

- State management cuts across the UI independently from components and has a lot of room for innovation.

Being able to say "Use our new Flugle framework, it works great with all the other frameworks and adds awesome scaffolding" should be a nice selling point and buffer against React monoculture, as opposed to building a different and much smaller silo.

The cycle repeats?

I’ve enjoyed the innovation of the progressive web from jQuery to Angular, but React burnt me out.

I learned the hard way that investing too much time and innovation into a JavaScript framework is a net loss.

And it was always painful when the next person rewrites it into the next “thing”.

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.

There are certainly good reasons to be concerned about a front end monoculture, and what follows is a curious observation rather than an attempt to discount the points being made here. Ten years ago, we had the opposite of a monoculture. We had new frameworks hitting the front pages of HN every week. We had the shitshow that was Angular 1.x -> 2.0. We had people inventing terms like JavaScript fatigue to express the pain of being a frontend dev at the time. The dust has finally settled and React has undeniably won. I am still kind of groggy from the whole thing and am going to avoid learning web components until it hurts my career to avoid it. I am not singing the praises of React (I don’t like hooks and my opinions really don’t matter), but I am at least happy that it is not 2015 any more and I can focus on building. It is interesting to me that enough time has passed and the sentiment is slowly changing.

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.

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.

> 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.

I use a discussion board that has migrated from React to uber-React. Now the system has become completely hostile to saving local pages. Now any local copy when opened locally shows (then blanks completely) all visible content and mutters helplessly "Perhaps you followed an invalid link?"

But even more hostile is a discussion forum has replaced embedded message post times <time></time> with just useless plain "x ago" text and the actual timestamps for each has been hidden as React "props" magically shown by mouseover events by "class". Like "I'll show a picture of a timestamp if you really wanna see one."

An HTML-only copy is more than useless when it used to contain messages and times. A "Web, complete..." copy has message text in there but it blanks everything, sounds like the kind of bug someone would have fixed in a minute if they cared.

And they don't it seems. Like web architecture involves toppling furniture at random and too bad if you trip over something. Love it or leave.

Is this a React thing or an attention-to-detail thing? When I cannot easily save pages locally, I'll go elsewhere.

PS: It "looks" as beautiful as ever. A tad slower maybe.

I would say react being the default expands to apps that normally would work perfectly server-side rendered. The insane amount of added boiler plate associated with writing an API, tests for the API (including contract tests), API documentation, API versioning concerns, deployment timing considerations; front-end API integration, front-end state management, front-end tests, API mocks, I feel like there's about 10 more items I could rattle off.

I feel like people forget that web apps can be rendered server-side, and with HTML-over-the-wire (HMTX, Rails Hotwire, Phoenix LiveView, Larvel LiveWire, etc), server-side rendered apps can have a UX similar to a react app, but with far less total effort.

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).

    Even as Next seppukus itself,
    people will likely just fall back 
    to React on Vite…

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.

Switching to Svelte could be a massive W for a small organization, they'll get inundated with a flood of highly motivated, skilled ex-React developers. Also if react is as probablamitc as people say (I'm veteran of the Angular/Angular.js transition wars so i don't know whats going on as much). If svelt et co. it helps a business not only achieve greater speed but maintenability long-run it's a competative advantage and should be exploited. much like how legacy c code is being handled due to its memory unsafeness. Would that happen?

Last tidbit Web Components are often suggested as a solution, they could lead to another layer of complexity. For instance, how do we manage complex, shared state across different web components that might be built with different tools like Lit or Stencil? How do components built by different systems pass information to each other without essentially creating an ad-hoc framework on top of the web components standard?

I've used React, Vue, Svelte and Solid. React is my far my least favourite of the four. Both before and after they added hooks, all the major API calls seem to have been designed for least intuitiveness.

I really wish something else had won.

React didn't "win" because it’s the best, it won because it became the safe default. Everyone knows it, hiring is easy, and the ecosystem is huge. That’s great for stability but not so great for innovation—lots of teams never even look at lighter options like Svelte or Solid. React still works fine, but we probably lean on it more out of inertia than actual fit.

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.

One consideration that that is missing: how familiar are LLMs with this technology? And from this point of view the app has sailed, I’m afraid we are stuck with the frameworks that are available today for eternity, for better or worse. And maybe that is not such a bad thing. I don’t do full stack programming in my day job, but I have this crazy idea that if I ever have a startup idea, I want to be able to code an MVP. So, every two years I do a deep dive and write a toy web app. I’m always learning something new on the frontend (fun!), while on the backend I just use Django, so it just works as it used to, except it usually gets more convenient in many small ways (boring). Sometimes there’s such a thing as too much fun.

The idea that react is stalling innovation is absolutely absurd. The JS landscape has so much innovation that the peanut gallery actually responds with open hostility any time something new appears. It's hilarious to me how the narrative has shifted from "there's too much church" to "boring tech is stalling innovation".

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).

I love this article and the pluralist worldview harking back to 2015/16. I'd love to tell my team "Hey we're going to build this small separate use case in Svelte". But the evaluation checklist, which is pretty accurate, is in direct opposition to the point being made.

Assess Performance Needs: 99% of apps are not going to notice the difference, so you choose React

Team Skills and Learning Curve: Everyone knows React, nobody knows Qwik, you choose React

Scaling and Cost of Ownership: Immaterial

Ecosystem Fit: React has the more full and stable ecosystem, you choose React

On top of all this, all the AI tools have good capability with React - defaulting to it themselves - and engineers are increasingly expected to make significant use of AI tooling.

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

Seems you don't get the difference between framework and library. In practice, the winner is not the “fastest according to benchmarks” tool, around which it is easier to hire people and build an ecosystem, as was the case with jQuery.

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.

Sticking with React because of "stability" / "ecosystem" seems very strange to me - I've never seen more churn than in codebases making heavy use of the React ecosystem. Constant breakage. Constant rewrites as functions, features, and sometimes entire packages are deprecated.

I also tend to see a lot of the "left-pad" phenomenon in such codebases. Large swathes of the "React ecosystem" are libraries whose relevant functionality you could've implemented yourself in a few minutes (and you'd probably have been better off doing so, to avoid the dependency hell). And there are also large swathes that only exist to work around deficiencies within React itself.

Hireability is a somewhat stronger argument, though this is situational - sometimes you're hiring "tactically" and truly need someone who can hit the ground running in your codebase as soon as they arrive, but oftentimes it's completely fine for new hires to be unfamiliar with your language or framework of choice, and gradually onboard to it on the job.

"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.

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.

>> virtual DOM was a clever solution for 2013’s problems

I'm not a front end expert but, I'm wondering, did anything really change since 2013 that renders the virtual DOM unnecessary? Or was it always unnecessary and people just eventually figured that out?

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.

    > 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 

I don't want more frontend innovation, I would be rather happy with less of it, and more browser plain APIs, which is what I do when coding on my own side projects.

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.

I prefer react to no react but the more I use it and other frameworks like svelte I start to find it more and more offensive to every fibre of my intuition as a programmer.

I thought I'd always like the express oriented style but every single time I go back to a project I didn't entirely write it's like going to a roadside picnic of absolute gibberish that would be better off done more dumbly.

Genuinely wondering, as someone who is not a web developer: is React the reason why most websites are so heavy and slow?

In the AI age we'll probably see even more of a migration toward whatever frameworks have the most training data and are easiest for code-completion agents to work with. Putting much effort into alternative frameworks now seems like even more of a losing battle than previously.

In a way, that might be better though. If you need a framework that's optimized for lightning speed, then maybe you want to be hand-coding it anyway. Also, with fewer people using it, there's perhaps less chance of it becoming bloated over time. The framework no longer has to compete with React; it has its own reason for existence and can focus on the things that make it special, not the things that make it more like React.

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.

One of the issues I find is that JavaScript itself holds back the ability of tool makers to experiment with practical novel alternatives.

TypeScript's tsx macro is designed with React-like libraries in mind and alternative frameworks need to create custom file types and LSPs just to get off the ground.

I'd love to see the JavaScript spec define a generic macro system to enable experimentation (with IDE support) for alternative frameworks.

For example, jsx/tsx could be expressed with an inline macro

    export App() {
      return jsx!(<div>Hello World</div>)
    }

While something like Vue or Svelte could implement their own inline macros rather than investing in tooling for their custom file types

   export class App {
      #[onChange]    // <- makes the prop a getter/setter
      value = Hello World
      
      constructor() {
        setTimeout(() => {this.value = "updated"}, 1000)
      }

      render() {
        return vue!(<div>{{this.value}}</div>)
      }
   }

If it's part of the spec, the browser could interpret it without a preprocessor and compilers like tsc/swc etc could precalculate the transformations and ship the transformed JavaScript (like we do today with tsx)

    let result = add!(1 + 2);

    let result = 3;

    // Removed by the bundler, can also be used in the browser
    import jsx from "react/jsx" 

    const App = () => jsx!(<div>>Foo</div>)

In the age of AI, it's all about popularity contest unfortunately. More people use it, more data points, more training data to feed, better AI response, more people use it.

Svelte shot itself in the foot with runes and other incompatible (but minor) syntax changes. Bad timing. Because now whenever I ask any AI, they will suggest old syntax that doesn't compile.

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)

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).

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.

Svelte is good, but ugh. It’s actually quite buggy.

I’ve never hit a React bug but we’ve hit like 2, maybe 3 little Svelte bugs this year. All to do with hydration though.

For early stage startups using react easily multiplies your required engineering man hours to get to market by a considerable factor. The biggest pro is probably that it pairs nicely with GraphQL, which, in many domains, is nicer to work with on the back-end compared to other options, but is also decidedly unfriendly to most options that minimize front end dev hours.

Point being, not to say no to React, but that if your org's size is small enough that you don't truly have multiple teams, you probably get way more mileage and output per $ using tooling that takes after Phoenix Live View, whatever that is - Hotwire, Livewire, etc.

On the other hand, you may expect that having more distinct BE/FE will pay off because of being able to have separate teams, easier to fit in a mobile app, etc. This has some truth, but it can easily turn into taking away from product focus too early in a company's lifecycle.

I’m starting to lean towards Solid over React these days. If we ever get a chance to redo our entire frontend paradigm, that’s what I will use. I used to feel like it was harder to follow than react, but it has a lot less chances to footgun yourself (unless by being too used to react)

I remember the days of countless insane, boutique javascript libraries. React's ubiquity is a victory - let's not encourage throwing something away in the name of some vague notion of "innovation".

I’m a long time react developer, since nearly the beginning (13 years?), many projects more than 30 large and small, always been a vocal advocate.

I recently ditched React for Lit plus web components and couldn’t be happier.

Not a single mention of 'Vue'

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

> 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.

There are no alternatives that are 3x better than react. That’s the minimum it will take to change the ecosystem default. React is good enough for most applications.

Is that slowing innovation? Vercel’s rsc push is definitely headwinds. But IDK, I see lots of interesting libraries around state mgmt & local-first primitive. I’d like to see more focus on SSG and islands architecture. I think bun 1.3 (bake) will be a healthy alternative to next. Ultimately the basic work of building frontends will become more componentized, so it’d be cool to see more interoperability with web component standards.

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.

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.

Is it winning? Of course, everyone has a different perspective on the software industry. From my (super limited!) view, Angular is winning. And for the first time in almost 10 years, I can now confidently say: Rightly so. “Components become targeted DOM operations”? Yes. “Updates flow through signals”? Yes. (Dunno about Qwik, never heard of it.) It was a long and arduous journey, but they pulled through. Also, it is rather batteries-included.

I encourage everyone to give it a whirl. Zone.js is no longer needed and with Signals and Standalone Components it is now proper good. Developer experience, too, with Vite and esbuild.

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

Or better yet, use vanilla and web components and HTMX.

I simply don't like the "client-side" approach for web development. A website was never supposed to behave as a full fledged app. They've taken us for absolute fools.

It's uncontroversial that with high traffic websites these sort of frameworks are necessary, but the decision to use React is much more commonly being applied at tiny companies as the new "right way" of building things.

What is unclear is what you lose by not using React. This is similar to how trendy MEAN was back around a decade - "it's web scale", etc...

This gets into necessary versus unnecessary complexity, which is nuanced. But the large scale companies get this, and are doing just fine handling it. It's the small ones that can't draw the distinction. Discourse on these sites or articles is much more likely to matter to these smaller companies, and so in general the best "universal advice" is probably to recommend the simplest thing that doesn't close any doors.

"Choose boring technologies"

For many software projects, you don't want to take technical risk on something like a UI framework. React is now boring.

Personally, I want a browser UI framework that's more like desktop/mobile UI programming. Working with the DOM directly kinda-sorta tries to do this, but it's so fundamentally "weird" compared to just getting a pointer / reference to an item onscreen, that it's clear why the React way is much more popular.

Less technical take than the other comments: I don’t care. React is good.

After suffering through JavaScript Framework Fatigue I was glad Create React App “won” for a bit until it was neglected so much a bunch of other bundling tools popped up.

Now the winners seem to be Next.js-but-try-to-ignore-the-Vercel-upsell and Vite.

I’m using Vite + React wherever I can and it just works.

I don’t need something else.

It's ironic that the chorus of "frameworks come and go, everything will be replaced in 3-5 years" has turned into chiding people for choosing the stable option.

The ecosystem lock-in is real. We rebuilt our frontend 3 times and kept coming back to React not because it was the best choice, but because hiring developers who know anything else was so hard. The irony is that React's 'flexibility' means you spend more time choosing between 50 different state management libraries than actually building features haha

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

Too much of the JavaScript ecosystem is "resume-driven innovation" or "innovation so my name is at the top of the dependencies/downloads chart(s)". Unfortunately this drowns out genuinely useful ideas and tools.

It's very sad this is what's happening. React hooks was a major innovation but a very bad one, people in the front-end world seem to value more about radical innovation and marketing buzzwords like "functional UI" (which is not true) than truly evaluating a system. The earliest momentum started from trend chasing, also a lot of people use React because they see the JSX looks pretty nice in the examples.

Darn, more LLM-generated blog posts?

Sigh, the article makes the blanket assumption that web applications cannot be built without some colossal framework. This is the reason I got out of JavaScript work. Most people doing the work have no idea how any of this really works and struggle to do the most trivial of tasks without a nuclear option.

My only real gripe with React is that since it's "just a library", no two React projects are the same, as every concern has a palette of libraries addressing it to choose from. I mean, even the router has alternative implementations.

Every additional dependency is a cost associated with onboarding, maintenance and security issues.

I use html and server side rendering. The whole react thing has passed me by. If I need to use a js framework to add interactivity it’s Alpine. But then I just ask myself the question? Is this bad design? And if the answer is yes, I look for a vanilla html approach. Bye the way... the answer is always yes.

>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.

React is fine, React Hooks isn't. It's cryptic, convoluted, and adds noise.

Yes, both have overhead but they let you mutate refs when you need 120fps feedback.

IMO, the best competitor is its legacy API. Want reactive shared state? 70 LoC:

https://github.com/uxtely/js-utils/tree/main/reactive-state

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.

I really don't like react but I can understand for huge projects and maybe multiple teams it creates an opportunity to have to good standardisation around the framework you create. But ask yourself how many react projects "need" all the tools and utils and nice things react can offer. Sometimes it just feels like the default when something far lighter would be so much simpler and easier to finish.

The author calls for using the right tool for the job, the lists some speedup features of other frameworks, as though "fast at doing X" is all that could possibly matter. I think this obsession with speed above all else (even forgetting that any other concern could exist) is a case of a really common dysfunction in software development, one that leads to ruin and bankruptcy, and one that successful companies built their empires on their ability to avoid.

React sites are perfect for AI summaries delivered to the user.

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.

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.

https://vorticode.github.io/solarite/

> That default is now slowing innovation across the frontend ecosystem.

While sympathizing with author's concerns, if "innovation slowing" means we get to use the same mainstream framework for a few more years there will be pretty positive consequences from that.

If it lasts I'd see many people willing to dip their toe into front end dev again.

As someone still building websites mostly like it's 2010, it's funny to look at these discussions. "How do we abstract away browser APIs" — but what if you just do not? What if you use them directly? What if you don't do client-side rendering unless absolutely necessary?

The two most modern tools I use in my web stack are TypeScript and PostCSS. But these are build tools that make my life easier. At runtime, I still have zero dependencies.

Our front end team doesn’t settle for ONE framework - they have several, all in the same application’s code base. There’s React, AngularJS, Angular, Vue (I think they started on that??) and even a bit of Jquery.

Is it an SPA? Well it’s an SPA per framework per page!

No one has the patience to port all the old code, and no one has any leadership to guide them. They’re just adding in flavor of the month and making it work somehow (kinda, well depends on who you talk to)

What about Vue? How popular/good is it, in comparison to React?

Frontier AI models and Coding agents are contributing to this calcification.

My preferred stack is SvelteKit, and I just maintain a markdown file of all the context needed to steer the AI towards the happy path with Svelte 5 runes, the Svelte flavor, etc.

maybe it's just time to say it's just a UI library space, and what kind of innovation could you imagine.

The last thing we need is “innovation” in the form of MORE JavaScript frameworks.

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.

For what it's worth, very happy with React and excited to keep the inertia going. "Good enough" in this case is quite good.

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?

How smooth an experience you have with react really depends upon which framework you use, how old the code is. I have seen many react apps using outdated versions of react that break in interesting ways.

People using react do not care of availability, of accessibility, of links, of the web foundations. They probably do not know why they are important. Beata ignoranza.

React is this generation Apache Struts. And it will pass too.

Yes but it's also a good declarative abstraction and should make the code more portable to other future declarative frameworks.

The best tech doesn't always win because network effects from wide adoption can be profound.

Is react winning because LLMs make people less interested in writing and maintaining open source libraries?

If something innovates enough to be a lot better than react then it will start winning. I haven’t seen anything yet

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.

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.

"Innovation" has been React reinventing itself, what, three or four times now?

I am so sick of "innovation". How about we innovate a solid baseline, establish an orthodoxy, and build on top of that. Oh wait, we already did, its called Web Components.

NOT React, which seems to change face every time someone needs a new resume badge.

Imho react is to FE development what C++ is to games programming.

And I'm not saying this in a good sense.

In particular their developers demonstrate the same tendencies:

- unwillingness to leave behind all the years of experiences they've built on it. I'm not saying one should just for the sake of changing, but if you encounter certain problems, you should at least consider it

- unwillingness to really try more modern alternatives

- willingness to criticize any alternative, even stating plain wrong things about those. This also includes judging alternatives for the state they were 5/6 years ago, often on very brief experiences

- ability to deflect criticism to their favorite toy with a "skill issues" argument. Oh, it's very easy to squeeze performance, you only need to know how to get good at using useMemo, useCallback, useEffect, etc. Of course, it ain't React being the wrong tool for the problem, or having made design choices that don't fit the problem at hand. Nope, has to be skill issues.

Honestly, every time I read "React is better because X", I know there's just too much engineering nuance missing to have constructive discussions.

LLMs have more knowledge in React, more than other tools.

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.

I'd say it's more "JS is winning by default and slowing innovation".

React (and TypeScript) is a mere band aid trying to make something out of it.

I say this from an Elm perspective: so much you do not need (code and libs) because the language is "sound".

Also true: some things are quite a bit harder in Elm than in JS, but usually that because it wants you to handle all corner cases that'd be runtime errors in JS/TS.

React gives me headaches.

> That reflex creates a self-perpetuating cycle where network effects, rather than technical fit, decide architecture.

This is 90% of enterprise software “engineering” as well.

Not just the front end. Not just React. Mostly everything.

The reality is that for most situations choosing a technology you know well, is mature, and is proven, will almost always be the better choice. There's always going to be some small issue with a framework, and then suddenly you're pulling your hair out at 2am trying to hack together a solution to make it fit your specific needs. Web devs aren't complete idiots, most will be able to pick up a framework in a couple hours. They won't be able to pick up all the edge cases and foot guns for months or years. Better the devil you know.

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).

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.

I started a new job last year (on a greenfield project) and our director of product told us we had to use React because "we won't be able to find developers if we don't use react". I love constantly shooting myself in the foot with react because vercel has good marketing.

i for one can't wait for React to die. I've never liked it and have felt other frameworks far exceeded it, but fell into the same camp as others when determining what framework to start the website with.

HTTP and JS have to go

How my understanding of the world or me living in a bubble was shaken because i understood that every sane programmer around me hates react

Well, if you want a more lightweight alternative, that is actually more powerful, spend an hour with this:

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

Ryan Carniato Is GOD

nobody wants innovation

Over 10 years writting front ends. I hate react, but this article is junk, it advocates for new "reacts". This exact mentality is what got us the bad parts of React, and it's going to give us the bad parts of whatever next library.

All the problems that react faces had already been solved by another framework, YEARS in advance. That framework is ember.js. And you know why? Because react started out as an view layer library, it was not meant to be a full blown front end framework from the beginning and it paid the price. But hipsters kept looking at how fast it rendered 10 million rows instead of focusing on what actually matters FOR EVERY TOOL YOU USE:

SCALABILITY!!!

Does your tool scale? ALL freaking frameworks feel great while writting Todo MVC. But how does feel writting a huge app? That's where decisions matter. And ember.js got these decisions right, everyone is reinventing those decisions (in worse ways) and calling it innovation. You're not innovating, you are reinventing a wheel, having not even learned your lesson from previous experience.

Having done that rant, and having said i hate react, react has become mature enough (with a big ecosystem) to let you do your job decently enough. Give me a freaking break. Let me use a tool for 3 years without having to re-learn a new API.

The argument about looking at technical fit doesn't come through. Very few people, "professionals", view it like that. Instead almost everyone defaults to their stack and views it as mandatory. I've been working for a long time, and I'd like to think I can manage to learn a new framework (and like most people, I implement something as a small project to learn something new occasionally), but in reality if I don't work with React every day professionally for n years, most people will not look at my work. In certain cases "the right tool for the right job" might make sense, but I'd argue that it really doesn't matter here, as all of these tools do the same job. If some do it better than the others they should win out, but the term better is very broad and complex, to the point it was successfully argued that worse is better.

I don't like to criticize too much any more, but I think in general this is a poor article. It doesn't really tell us anything other than latching onto someone else's opinion -- Rich Harris told us virtual dom is pure overhead, ok, but what's your opinion -- or referring to technical debt with React, as if it doesn't exist in every other project, or vaguely complaining about suffocating something.

I mean the job of these frameworks is to update a page when you change state. That's it. If the world has decided React is good enough in all or many aspects of using it, so be it. If The Guardian rewrote something in Svelte and nobody noticed the improvement that apparently objectively exist, what's the point?

As far as the "killing innovation" thing. Thats incorrect. Browser manufacturers and HTML/CSS/JS have killed innovation.

Screen layout was a solved problem 40 years ago.

Also search has killed innovation by turning sites into content factories instead of building things that matter.

Google was and is a very bad steward of the web and is rightly dethroned by even fake AI.

IIRC it was quite a fight for react, it wasn’t a slam dunk out of the gate.

[dead]

[dead]

[flagged]

[flagged]

[flagged]