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.
I worked on a business app made with lit web components and all properties being stringly typed was a real drag. It didn't compare to a realtime-first component library.
At my large corporation, we are required to use a centralized React library for internal apps. So it is not “react by default”, but instead “React is the only choice”. 100% agree that our path out is for the central library to be reimplemented as web components to open us up to using whatever framework we choose.
Strong disagree. Web Components are react in different clothing. You don’t need this component-based framework style architecture to write applications for the browser.
I promise writing applications for the browsers is not challenging. You don’t need big frameworks or component madness that’s more of the same.
You don’t need big frameworks or component madness that’s more of the same.
You don't, but in any sufficiently complex app you'll end up writing a sort of 'mini framework' of your own as you abstract all the things that crop up more than a few times. That framework might be really nice at the start but it'll get more and more hacky as the project continues, especially if you're constrained by resources. Eventually you'll regret not using something standard.
If there are more than a couple of developers on the project it'll be something no one really likes after a year or two.
If there are more junior developers it'll be a reason for them to want to get off the team because they won't want to be a part of the 'old legacy code'. Then it'll be hard to find people who want to join.
Eventually, as it gets harder to recruit people to the team because it's on a weird, legacy framework that no one knows, there'll be a big project to refactor it on to something more standard. That'll probably be React. At the same time most of the senior developers will be calling to scrap the codebase entirely and rebuild it (wrongly in almost every case, but they don't care and want a greenfield project to play with new things on.)
This is a story that has played out at every large org that builds apps internally, and probably a lot of startups as they mature and need to hire more devs. You might as well skip all of it and use a standard framework from the start.
We should probably be making widget toolkits for the Canvas and using WebSockets for communication. DOM manipulation is a total hack-job. It's somewhat flexible, but the performance and dark-pattern cost is just too great. If you're making an interactive application, then treat it like an application and draw widgets to a canvas.
This is an insane take, show me a responsive button with hover state and a tooltip implemented in the canvas that outperforms a button rendered with React.
It just takes the minimal amount of discipline, and some conventions. I know it can be done because I did it, lots of people did it just a few years ago (some of those apps are STILL running today.)
Curious if has anyone had much success using web components within a react UI library? When building a component library on a bespoke design system, I'm quite pleased that I can rely on a headless library like RAC to ensure that the base component implementation is accessible and works well on touch devices. I can see theoretically that web components could be a complimentary tool, but in practice I'm not certain where they're best used.
>"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."
I avoid frameworks like a plague. Plain JS, web components and some good domain specific libs are more than enough to cover all my needs
I moved my entire business off React and now I don’t have to worry about tinkerers at Meta deciding to reinvent React every 2 years and tricking everyone by keeping the name again and again.
Web components are fantastic. They are the real future.
I like lit. I'm not primarily a web developer and I've found it intuitive and easy to read and write. What I find more confusing than frameworks is building, bundling, ES modules, the whole NPM ecosystem.
Agreed, Web Components don't require any framework and you can achieve everything you can achieve with React (including reactivity via attributeChangedCallback), the learning curve for Web Components is actually much less steep than React when you consider from the perspective of someone starting from scratch.
Furthermore, Web Components enforce good patterns; like the fact that you can only pass strings as attributes (by-value) is actually genius as it encourages simple, minimalist component interfaces and avoids pass-by-reference issues for which React community had to invent an entirely new paradigm to protect against (I.e. Redux state management with functional programming approach).
And the great irony is that a lot of the top people who are still pushing React are basically rich from Facebook shares and don't have to work anymore. In effect many of them are forcing this technology onto young people who have no choice in the matter whilst they themselves don't need to use it or do any coding anymore. Meanwhile I know a lot of developers who want to leave (or have left) the industry because of how bad it is and how few decisions they're allowed to make.
It's demoralizing to work with inferior tools when you know better tools exist because you use them in side projects... When you see this, you think to yourself "If the company forces me to be inefficient with my choice of tooling, this gives me a license to be inefficient in other ways."
Personally, I don't even code anymore (only on my side projects). It's a shame because one of my main talents is writing clean, minimalist code. In my day job, I'm using drag-and-drop UI platforms like n8n and Flowise (for AI). It's refreshing to be able to use vanilla JS inside the nodes, without a compile step and on a real-world project that actually pays. These UI platforms are actually much more predictable to work with than React. When I was using React (for almost a decade), I was constantly debugging weird glitches and state management issues; I never encountered those with Web Components or with platforms like n8n.
> the fact that you can only pass strings as attributes
This isn't true at all though. It's a lie started in the early days by React engineers that just won't die, unfortunately.
Web components are objects and they can have properties and accessors like any object. The vast majority of declarative template systems like React, Lit, Vue, Angular, Svelte, Solid, etc., will declaratively set properties - which can carry any type of JavaScript value, including complex objects and function - on web components which can then be used to update the component's DOM.
That approach passes values in JS rather than the DOM, right? I read the go comment as talking specifically about DOM attributes which can only be strings (well, you can have boolean attributes as well).
Web components can be passed objects in JS, but its news to me if that is available in HTML.
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.
I have been a part of quite a few tech stack decisions at various companies and startups. I have literally never heard an argument made for react that included merits of the framework itself. The decision was always based on a combination for familiarity, ability to hire for eng roles, and the ecosystem.
Im not sure how this is a negative merit for React.
Besides if you are a small company, or a start up, your job is to get things done. Not to embark on a global technology crusade to push your favourite tech.
By and large the best thing about react is the overall ecosystem, libraries, talent and ubiquitousness. And thats a good thing.
It isn't necessarily a bad thing, but it doesn't align with the idea of how good react is or the technical merits of it.
I also am not saying teams I have been on that picked react made the wrong choice. That's all in context and as you said startups are often in the "get things done" mentality where tech debt won't matter if you can't survive long enough for it to matter.
It’s good enough that the ecosystem outweighs the superiority of something like SolidJS.
React has React Native as part of its ecosystem. That’s a massive advantage. react-strict-dom is going to be a game changer for the development of universal apps.
We're talking about two different topics here. I agree, the ecosystem around react is huge and there are reasons a team would pick react. Ecosystem isn't an indicator of the technical merits of react itself though, and that's what I was originally responding to here.
You’re assuming webdevs are rational creatures which in my experience is far from truth, since they easily fall for human biases traps such as “social proof” and “authority”.
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.
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.
The amazing thing about React to me is that millions of dollars keep flowing into improving its DX further. They have spent a lot of time building React Compiler (https://react.dev/learn/react-compiler/introduction) which does all the memoization for you! This severely lightens the performance concerns.
Sure, but Svelte and Vue have had these compilation features built-in for ages without all that money flowing in.
The react team resisted these features because they went against their “it’s just a library” philosophy. They’re only copying them now because of how obviously useful they are in the other frameworks.
useEffect, useMemo, useCallback etc. add a ton of complexity and make it easy to write buggy code. I used to work at an agency so I’ve done projects with React/Svelte/Vue/Lit/Stencil/Angular/etc. I found the React projects had lots more performance issues, confusing bugs, etc. than Vue or Svelte.
I agree with the article. React is popular because it was groundbreaking and now is the default, but it’s far from the best
I'm a counter example of your claim. Migrating away from React did made the complexity of my app a lot more manageable and unlocked new business opportunities that would have been impossible with React without following the JIRA route of making the software worse for 99% of users because 1% of those needed something. The project in question is Filestash (https://github.com/mickael-kerjean/filestash), what made me switch are those 2 reasons:
- Performance ceiling. Past the point where you have used all the react specific optimisation tricks (useMemo, etc...), React just gets in the way, once you start to optimise things to reduce the memory footprint, optimise for 60FPS, dig into heap snapshots and allocation traces, your life starts to become miserable where you need a complete understanding of not only your app but also the inner working of React, and the intersection of both React with your app. At that point, you either accept the ceiling or rewrite everything to vanilla JS and have complete control over every piece of the code you are shipping to the client
- Extensibility. I am now shipping plugins which patch frontend on the fly without any build step. In practice, after a plugin author packaged their plugin (as a zip file containing a manifest), the patches are applied in real time by the server without a prior frontend build system (open up the demo instance with the network tab open to see this working from: https://demo.filestash.app/). This powers themes with icons swaps, new behaviors (e.g. a "recall" button for files in Glacier), and other things plugin authors come up with that that makes the app far more customizable and opened for new niches without falling onto the JIRA trap
React is totally fine for solving simple problems.
I'd classify pretty much all frontend web development I do as simple. It's pretty much just boring internal websites, I definitely don't need react for them. Could have made the same thing with any other frontend framework, could have made it server-side rendered. React is totally fine for that. The backend is generally more exciting than the frontend. React is totally fine.
The main problem I see is that most other developers are really ass at their jobs and just overcomplicate everything. I've seen very simple apps have a super complex React codebase, and due to the complexity they're always full of bugs. It's much more rare that I see an elegantly simple React app, or any other app for that matter. Everyone just always overcomplicates everything.
Using React doesn't in any way require you to make it complex. You can make React apps dead simple. And if you are comfortable working with react you'll already know all the solutions to all the problems which makes your job extremely easy. You can breeze through and make the entire simple app in a few days if you know what you're doing. Or you can pick up some new fancy tool, hey let's try Svelte. And now instead of a few days we're gonna spend a few weeks and end up with a codebase that reflects our Svelte experience. And hey look it's time to onboard a new team member - hey guy, we have these three apps - this one's made with Angular because one dimwit wanted to learn that, here's a Svelte app we made last year and lastly here's a HTMX app we made when that was hot. Good luck learning 3 new technologies you'll probably never use again!
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.
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.
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.
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.
> 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.
> 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.
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
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.
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.
I'd go further and suggest that we need maybe five or six browsers. One for shopping, one for banking, one for socializing...
Let the platforms for these things compete on the back end only and provide a uniform experience on the front end across competitors. This way the people writing the code that runs on our devices don't have conflicts of interest that lead them to betray their users.
It would also be easier to use because once you know the structure/flow/hotkeys for one bank you're now wizardly at navigating the interface for every other bank.
It's just such a waste to have each business writing a separate front end even though what they end up with is always more or less identical to their competitor.
Sandwich shops should compete by making a better sandwich, not by outmaneuvering each other re: how they leverage the app they managed to get 8% of their customers to install.
Frankly it's incredible what any of these frameworks have been able to accomplish given the bonkers platform they have to work on.
HTML, CSS, and JS made sense back when the web was primarily text with some simple forms. It's a dog shit foundation to build highly interactive apps on. The whole thing needs to be thrown out and rebuilt.
The frustrating part is that the idea is incredible. Everyone has this piece of software on their computer that lets them run anything as long as there is a server to talk to. I love it. I don't want to have to download a thousand apps, especially not for shopping or banking. Just using a web interface is awesome.
Unfortunately we decided the correct way to provide the functionality was by layering bonkers ass abstractions on top of a system meant to largely display static text and images. In the year 2025 there is absolutely no reason we shouldn't have a unified coding language that allows you to render things in a web browser in a sane way.
At the very least we should have seen a substantial expansion of what HTML is capable of, closer to what HTMX is doing now, with a better way to style everything then fucking CSS. People complain about JavaScript but for my money CSS is the greatest sin.
A great native app on an iPhone feels far superior to a mobile website. The gestures, the stack navigator, haptics, scrolling, native ui primitives, etc…
Also iOS accessibility screen reader APIs are way better than the web. Accessibility actions for instance are great.
> 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.
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).
+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.
React DX is probably the worst DX of all frontend frameworks I've ever seen. All kinds of confusing concepts (hooks, memo, props passing, class style vs function style, an entire new "language" like JSX which you then first need to install an IDE extension for) and you cant even begin a react project most of the time without using some kind of react starter template because building this thing is so hugely complex that people just give up. Then you constantly run into issues of double rendering with reactjs which is quite hard to debug. I was hoping for something tiny like https://www.arrow-js.com/ taking off but the creator doesn't really work on it.
Honestly I think React DX kinda sucks, at least in some areas. Performance is one of the worst (`useMemo` and `componentShouldUpdate` are way to easy to ignore, constant re-renders are the norm and writing performant React code requires conscious effort to avoid footguns) but it's also just less self-explanatory than the alternatives I've tried.
I started doing web dev before reactivity frameworks were a thing, and I found Vue to be the most intuitive of the frameworks available when I first needed reactivity. To me, Vue feels like HTML with superpowers while React feels like a whole new way of thinking about webapps. I'm honestly a bit surprised that the article doesn't mention Vue, since Vue is (and has been for a while) the most popular "not React or Angular" framework option. Newer versions of Vue even support the "disappearing framework" feature Svelte was built for, which I'm excited to take advantage of when my biggest work project finally moves to Vue 3.
I think you've nailed it. It does come down to user preference.
React _is_ a whole new way of thinking. Back in the days of jQuery it was very painful to stitch together web experience across HTML+CSS+JS. jquery provided much needed DX around utilities to navigate across these pieces. But it was still way too easy to treat HTML like your database and model user-state across a Frankenstein of server, json, html, and javascript.
React was a paradigm shift. "Screw it, everything is javascript." The web depends on js runtime, we know we're going to need it. It starts to makes the best future-forward sense to use the only full programming runtime available. From DX pov this was spectacular to speed up prototyping. And you can finally truly model state purely from data.
What followed was a huge a mess (redux), but I always say, what do we expect? The web is a mess, and it's great because it's useful. Humans are a mess!
---
VUE: similar to angular I just don't align with "super-powered html attributes". It just doesn't make sense as a mental model. Because it's _not_ HTML spec and HTML is not a programming language. The more powerful the framework gets the more we reinvent a pseudo-programming language _through_ HTML. Angular was full-stop a no-go when I first saw it's for-loops in HTML.
Neither react's JSX nor vue's template language are HTML. But rejecting vue's template on grounds that it's not HTML seems odd. React's JSX deviates from HTML in many ways. Like class vs className. XML self-closing vs HTML self-closing. onchange vs oninput. On purely aesthetic grounds, I can't understand how the react idiom of array.map() would ever be preferable to an affordance in the (non-HTML) template language for handling this normal standard thing that always happens.
it's not about feigning html purity it's the opposite. Why pretend we're using HTML when it's not? so with react it becomes a js flavor, jsx, which some people hate but it's very clear that it's a made up language IN real javascript.
edit: the mental model is instant: it's just javascript for reals. do anything you want in javascript using real js primitives. it's not about looking pretty, jsx doesn't. it's about not relearning basic programming primitives in a made up _markup_ language.
my issue with angular is it's neither real html nor any programming language. its made up pseudo-programming language for no other reason than it fools people into thinking "it's just HTML". that's my gripe.
Completely agree with you. Every time I see yet another template language adding some clumsy for-each loop syntax I sigh. Just let us use a normal programming language. As an example I give you every template system ever invented. Devops tooling is full of them.
I don't really recommend isomorphic environments, but if it's your cup of tea, Tanstack Start is making a lot of progress. It removes all of the magic and misdirection of Nextjs and just provides a good light alternative.
Issue with all things tanstack is they change everything constantly. The Tanner guy really does make decent libs but he drops em pretty quickly for others to take up maintenance on which makes it risky to pull into any production app.
Next initially jumped the shark when they went all-in on server-side rendering. The reason why Vercel did this is clear: client-side rendered apps can be hosted basically for free on Firebase, Cloudflare, or S3, so the only way they can raise their Vercel cloud revenue is by forcing their users into a dynamic-first world, pushing so much complexity and dynamism into the framework that only Vercel could disentangle how to host it effectively. The less-dystopic reasons they communicated as to why customers might want SSR; improved time-to-first-byte and a more PHP/Rails-like programming model; while well-intentioned, ultimately became of questionable value to customers given their choices during implementation.
I do actually believe a more PHP/Rails-like programming model would be beneficial for React; Vercel just missed the extremely important detail in how Rails is so dang productive. Its not their decisions when it comes to HTML templating; its Active Record.
React DX is hot garbage. Words cannot express how much I LOATHE hook rules. Coming from a Solid JS background, where reactive primitives are just Javascript functions... I groan every single time I run into (yet another) hook rule.
I have to conditionally render empty fragments because React can't handle conditional hooks. It's the stupidest thing ever. "Oh hey let me allocate memory for this hook that will almost certainly never be used except under edge conditions! Sure, React can do conditional components, but conditional hooks are just too much for us!"
Not sure I understand the conditional beef, perhaps you can give example? I would assume if you want `if condition, useEffect(...)` you could simply replace with `useEffect(() => if condition...)`, no?
Fair. My bitching would've been better expressed as "I groan every single time I attempt to violate a hook rule." Which is a lot, because I'm new to React. It's almost certainly a "skill issue", but hooks are NOT just "JavaScript functions", contrary to React marketing PR.
My conditional beef: in my app, users can choose between using the built-in mic for speech recognition or a 3rd party service (LiveKit). If the user chooses the built-in mic, I still must allocate memory for LiveKit's services because it's exposed as a hook, even if the user will never use it. This problem compounds - every option that I expose that uses a hook requires that I allocate memory for an option that may never be used. Also TTS - users can choose to use the phone's TTS, or a remote service, etc. Every option I offer, if the library exposes it as a hook (and they virtually always do), if I naively implement the feature, allocates memory for a hook that might never be used.
Fuck. React. Hooks.
My workaround is to conditionally render empty fragments. These fragments wrap hooks, which I then inject into the context. This makes it so I can conditionally run hooks. This is why I complained that React can handle conditional components, but not hooks. Concretely: https://pastebin.com/sjc3vXTd I'm using Zustand because god I need a lifecycle outside of React.
Y'know how people complain about how Async "colors" functions? Hooks are also a type of function coloring. And they don't compose with Async.
Yeah, this is a really annoying thing about how hooks work. For whatever reason (I'm sure they have a great reason) React can't do hook state book-keeping correctly without tying it to a function component lifecycle.
I think you actually can conditionally render a hook but that choice has to last for the entire rendered lifetime of the component. But that doesn't really help you when your user can switch between them.
Based on how they are run they are completely not just ordinary JavaScript functions, hook era components are also not just JavaScript functions, it's a very complicated system. React calling them "just functions" is untrue, just marketing buzz words, and it leads developers into traps.
Many functions can only be called in a certain context. Calling them "not functions" is misleading imo because it implies those functions are compiled out or something, like `$state()` in Svelte.
Yeah they themselves are functions but how they're called are managed by a complicated system, I think treating them as a separate new concept is less misleading than calling them plain functions
They kind of are not though, you can't call them out of order and other things which is checked at runtime by the React "engine" and will stop script execution. If they were regular functions you could call them anytime.
They are context dependent, must execute in the same order every time, and must be called every time the component re-renders (i.e., they do not support conditional calls). They have enough gremlin rules that calling them "just functions" is unhelpful for reasoning about using them.
> if the cost is an extra few milliseconds of render time and few extra hours of dev time
That is very optimistic. Most React projects never get to the optimization stage, and end up with seconds of rendering and transition delays that significantly harm UX. And the amount of time spent battling hooks, re-renders, compatibility issues, etc amounts to hundreds of hours over the course of a medium-sized project, thousands for larger companies.
“Most” react apps needing “seconds” definitely needs some citation or evidence. Even in fairly heavy and laggy react apps, it’s still usually network latency, waterfall requests, ad/tracking bloatware, large asset sizes, and the usual old classics that cause perceptible slowness in my experience.
In my humble (backender) opinion, if it's hard to use a tool right, that counts as a cons, and that must be accounted for when choosing which tool to use.
It's hard to build non-trivial web UI with any technology—React is just what's familiar. If Angular had won (god forbid) we'd be seeing all the same articles written about how bad Angular is.
I won't say most react apps performs like this. But it's what you will get if you ship a big react app without optimization at all.
Other framework mostly have a much saner default (for example, component without argument change does not re-render). So it will work well (not best though) even in large scale. But in react they are all opt-in.
Mcdonalds is really good. Even if the cost is an extra few pounds and increased chance of getting cancer.
If Mcdonalds starts taking a backseat, it’ll because its no longer really good. And, to be fair: I’ve started to see this happen. Mcdonalds & Coca-Cola have totally taken over the food industry world, and they’ve proven to make quite poor nutritional decisions. All great empires are destroyed from the inside, not out, and I think its possible Coca cola could do this to Mcdonalds. But also even as Coca-Cola seppukus itself, people will likely just fallback to Mcdonalds on Pepsi (or, there’s Pepsi Zero Sugar that’s I think still under development, but might end up being big).
Why don’t we just switch over to Vue? If DX is such a driver for deciding to use a web framework, Vue kicks React’s ass, and that’s just objectively speaking.
Well not technically switch, I never learned React properly because I didn't like it when it first came out and by the time I gave it a second look there were already a gazillion React devs so I just stuck with Vue.
Vue just seems much more intuitive and sane to me. Sane is relative for front end frameworks of course. Don't get me started on Angular I got PTSD and couldn't code for a couple of months from a large Angular project with an offshore team.
I do get the benefit of using these framework for teams, and they are nifty once you get what is happening, but I still scratch my head when I see all the steps and files to do simple things I used to bang out in a few dozen lines of jQuery.
My main complaint about React is the sort of lackluster quality of loads of React-adjacent libraries, by people who seem obsessed with "we're doing Yet Another Rewrite and a major version bump".
It's not that hard to maintain API stability folks! Try a bit harder!
React is popular in the modern days only because, well, it's popular. Developers use it because companies use it, and companies use it because developers use it. It's not popular because it's better than all the alternatives, it's just that it has reached critical mass, and it's now "too big to fail". It takes constant effort to avoid React's many footguns. Supporters often call this a “skill issue,” but even if that’s true, why wouldn’t you prefer a framework that does the same things with less code, faster, and with far less mental overhead?
Super insightful. I hadn’t been able to articulate the same feelings.
Even as Next seppukus itself,
people will likely just fall back
to React on Vite…
This is my exact read on the situation, as well. I’m not sure if anything can meaningful affect React’s domination in the short-term or medium-term, even with the accumulation of poor choices.
I haven’t tried tanstack-start, but I wouldn’t be surprised it becomes the defacto react framework instead of next. Everything by Tanner Linsley is just so well thought out and the DX is amazing. If his framework is the same level of quality, without any major gaps compared to next, it will probably blow next out of the water.
And Tanner is already a huge name in the typescript/react world, so I think there is actually a chance.
Time spent implementing features / components that don’t exist for the alternative framework of choice, or trying to figure out a framework bug in your own because there aren’t enough other developers using the framework to have surfaced and resolved all the bugs.
funny you should mention react on vite - i migrated a web-app to that setup ~3 years ago and never even considered looking back. react is still a trusty workhorse that assists me in getting things done, the ecosystem is rich (i'll take the varying quality as a given for one this size).
I've been toying around with next a couple years ago, followed their development for some time, then decided they are not doing what I need.
Isometric rendering turns out to sound way better than it actually is. The pain doesn't come from different programming languages on front- and backend, it comes from the difficulty of reconciling client state, server state, security etc. I actually find it helpful to have specialized languages for each side, rather than having to figure out for each piece of code wether its supposed to run on my server or in the browser.
Remix 3 appears to not be based on React. The React Router/Remix people write great libraries. The problem is that they're constantly chasing the next great library. By the time you use their latest creation, they've already started making a new library that they'll tweet about
Maybe us backenders help. If I need to do front end I learn as little as possible. React does the job. It could have been Angular that ended up being in the boring throne, and I would have said just use Angular. Just use what the world uses!
I'm a backender that writes UI PoCs to test the backend where the PoC gets pushed to prod. I just write custom JS updating HTML/CSS elements directly. No frameworks. I've been told it's a nightmare to deal with later, but it makes perfect sense to me. Not once have I ever claimed to be a UI person. That's just way too close to the user for my liking.
Angular is so much nicer and more batteries-included than React. React somehow manages to be massively yet incomplete: add a router, add state management, add react-hook-form...
In practice, at scale, in an ecosystem instead of a toy project, excessive choice is counterintuitively a bad thing.
It's hugely beneficial to have common ground and shared interfaces when integrating code from third parties, or collaborating across multiple teams.
> You can pick
A golden rule of large enterprise is that there is no "you".
As soon as there are two people working independently, not to mention different business units or teams, different choices will be made. Incompatible choices.
Angular is used a lot in enterprise apps/services when they need a low risk one-way to do things (e.g. Apple's App Store developer portal).
React is used in enterprise when teams need to move fast and break things (e.g. Microsoft Edge's UI after switching from Trident/Spartan/EdgeHTML to Chromium) and tend to be replaced with something else when dev teams / managers realise that they need to rebuild it anyway just to keep it maintained and/or gain more performance. (e.g. Edge "WebUI 2.0" moving their browser UI from react to web components)
At least in my own experience, I tried building a relatively simple static SPA NextJS React app with their router, and wanted to host it on CloudFlare Pages.
It ran locally in dev mode just fine. Once I deployed it on CFP, the router broke. No errors in the console, it just didn't work.
If I'm forced to use Vercel to make a simple SPA work, which then forced me into paying for their service, that's the problem.
A front end web framework with global state management should be a last resort for a website. Coming out of the gate with it is just ridiculous IMO. Most peoples websites are just not that complex.
There's like an escalation ladder in my mind:
- just write HTML
- statically generate the HTML
- dynamically generate the HTML
- dynamically generate the HTML at a smaller granularity (HTMX et all)
- augment your HTML with custom web components that have client side behaviour.
Only if you've exhausted that should you bother with something like React. And even then SolidJS does a much better job of it than react itself does.
So yeah, I am just not seeing it. Former (and perhaps future!) React.JS dev btw.
To be nitpicky, React itself does not specify that state management must be global. It was a popular pattern, starting with Facebook's blog post on Flux and made popular by Redux. And certain newer features like hydration/SSR and suspense more or less require a global store because their data can't be kept in the tree. But in many cases you can keep state local with useState and Recoil/Jotai and frameworks that keep global state/caches abstracted away like TanStack Query.
For progressive enhancement, I like the island approach used by Astro. I do think that most developers are not just building static sites though. And if you're generating HTML on the server side and then updating it dynamically on the client, having two different languages (Java/Go/Python on the backend, JS on the frontend) becomes messy pretty quick.
There are times where you should build the simplest solution that meets your needs, and times when you should think ahead to future use cases so you don't box yourself into a corner. And picking a framework is a big part of that process.
fwiw i've never experienced the drawback of separate languages for server and client. nor did i ever experience the benefit of single language across server and client.
being forced to use javascript on the server sounds like a cruel joke vs a benefit. I mean just simply from "i can literally pick anything for my controlled server env" vs "no we're a js shop cuz web"
edit to add: is it one repo? or maybe shared types. typescript is probably the strongest argument. can enforce integrity truly across the stack. but i don't think that's worth being forced into js environment and packages. community is forced to reimplement everything in js. no good.
Maybe I'm stupid, but as I recall, React hooks were quite complicated. It's been a few years since I wrote production front-end code, but it felt like some kind of high IQ/elitist barrier.
I'm not sure I'd say that React's DX is actually that great. I've watched C++ developers come over from using QT and the learning curve is massive. Plus almost all the bugs come from dealing with React's renders.
I think React by default is weird because most things don't actually need that degree of reactivity. Like, if most of the time only one thing is displaying or updating a value React just adds a lot of headache. And the amount of useEffect I see? (By necessity mind you) with the need for linters in order to figure out if you missed something in a dependency list.. I just think it's the wrong model for most projects
Maybe it would be, but I would also make a significant bet that the web would be noticeably less sophisticated without React. React is complicated, and builds complicated apps, and has its performance pitfalls, but it is also a driving force for how the web has been able to achieve native-class user experiences. Its the right programming model for building complicated things.
Websites were much more varied and creative in the jQuery era, and even more so in the Flash era that came before. Different interaction paradigms, wild animations, full-screen effects, etc etc. Not necessarily "better", but React didn't really enable anything we couldn't have before - even today when real performance is required you will resort to canvas/webgl, alternative rendering approaches and skipping react's render cycle.
React was never [1] fast [2] - that is one of the biggest misconceptions in frontend development in the last decade.
I wrote websites in the jquery era. I wrote web apps back then. Gaming tools, databases, tons of dynamic stuff.
When I used react for the first time I cried with “where has this been all my life? It would have saved me years of work”.
Whenever I see claims like yours I always have hardcore doubts. React may not have “enabled” new things just like ai coding doesn’t “enable” new things … as long as you consider time to be in infinite supply. If you care about getting shit done, there is no comparison.
How is it good? I've only had the misfortune of working on two React apps, but they were both a nightmare. It seems like React is great if you have multiple teams that hate each other all working on the same giant frontend app.
It's good because it's popular, which doesn't really mean it's good. See Java. It works and rakes in billions, but it still may be utter shit from an engineering viewpoint.
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.
I agree 100% on the added cost and complexity. I think a lot of that gets masked by the boilerplate that makes it so easy to get started. Then they have their hooks in you and 6 months or a year later you are scratching your head and hiring “react developers” to help solve the problems you were trying to avoid.
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.
No OP, but I've also used Angular, React, Vue, Solid and Svelte in real world projects and my default choice is Vue, because it's on par with Solid and Svelte (and with Vue Vapor those three are basically the same) but with the larger ecosystem (vuerouter, vueuse, nuxt, nuxt-ui, primevue, nuxt-content, ...). I must also say that React was by far the most unpleasant and unproductive to use.
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.
> 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.
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.
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.
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.
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.
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).
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.
Css in js was like a fever dream that lasted 2-3 years and seems to mostly go away. It's a good example as to how the frontend world just seems to make bad decisions.
Like if you take React's server components, it has a ton of problems and gets excessive focus from react devs, but fundamentally I can agree on what's its trying to solve. I understand the need, even if i disagree in almost anything else regarding it. I still don't know what the css in js phase was about.
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
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.
I remember seeing Mint quite a few years ago. I love the idea, I really like the language design, but I agree 100% with your take on the drawback. It's hard to sell that to teams.
What's surprising to me is how many alternatives exist in this space. Between elm, imba, svelte, and mint, and probably more that I don't know about, I wonder how many devs in the world are shipping to prod using them.
edit: have you thought about including Form Validation to the core lib?
"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.
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.
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.
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.
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.
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.
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.
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.
This is the most pedantic section for me, it’s just a bunch of 5 year old illustrations with 0 explaining on how React actually works behind the scenes:
https://react.dev/learn/render-and-commit
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.
Usually I write a few helper functions to streamline working with elements, attributes, and registration of element + CSS. But even without those, I think this approach provides a good level of simplicity without introducing libraries or frameworks.
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.
I don't know if I'd consider that the reactive callback because there's no change in state if I only put the `console.log` in `onChange`. The point of the reactive callback is to be invoked on a change in state and in this case, that is the component function would you agree?
In Vue, for example, when I set up a `watch`, the change in state only invokes the callback that is wired to the state. In React, the entire component function is invoked again on a change of state.
Yeah that's a pretty good way of putting it. In Vue et al, the script tag is a constructor and the template is a render function. In react, you just write a render function and use hooks to define stuff that otherwise would have been in the constructor.
"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.
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
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)
I explored JS decorators in the past but decorators are different in that they are a runtime operation that can't be statically compiled and can't be used on non-class properties.
You probably know this already but macros on the other hand are just dumb expansions/computations of syntax transformed at compile time, like
let result = add!(1 + 2);
Would compile into
let result = 3;
Including macros into the JavaScript spec is a bit weird because it's an interpreted language so compile-time concepts don't really make sense (which is probably why decorators were proposed).
But JavaScript is compiled more frequently than it isn't and we apply a crazy amount of transformations to it (typescript, tsx, path manipulation, styled-components, etc). IMO standardized compile-time manipulation with LSP integration would go a long way for language ergonomics.
That would also mean transformations for things like jsx could be run _in the browser_ allowing people who don't want to use a bundler to run their code without one.
// Removed by the bundler, can also be used in the browser
import jsx from "react/jsx"
const App = () => jsx!(<div>>Foo</div>)
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.
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 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.
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.
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).
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..
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.
I wouldn't say I've worked at companies where the framework is exactly what holds back deliverability, but I have worked in plenty of environments where a complex front end is multiplying the work required to get a basic CRUD product out without a ton of benefit.
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)
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)
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.
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.
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.
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.
Yes, quite an oversight ... as Vue has it all: Adoption, maturity, ecosystem, features, DX and speed (with upcoming Vapor mode even on par with Svelte and Solid).
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
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.
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.
Google's incapable of sticking to anything good. Nobody gets promoted at Google maintaining a system. So somebody inevitably gets the idea to make a 2.0 which isn't backwards compatible, enabling them to do all sorts of bold promotion-worthy innovation. And inevitably 2.0 isn't very good. Even worse, it makes the entire ecosystem confusing and unhealthy.
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.
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 :-)
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
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
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.
I am so glad to be old and have lived through the transition from Angular to React. To understand why we have React. In fact I am so old I have lived through the transition from Adobe Flex to Javascript Frameworks first.
And the thing that is clear to me is that wave of Javascript Frameworks, of which Angular was one, looked at Flex and leanred all the wrong lessons (I'm looking at you two-way data binding) whilst React got second mover advantage and learnt all the right lessons.
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.
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.
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.
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.
React's benefit was absolutely technical. Its component model and one-way data binding was so much simpler to reason about and elegant than Angular. So much so that they ended up copying it in Aungular 1.6 and Angular 2.x.
One of the biggest criticisms at the time (And perhaps still now) was that it wasn't opinionated at all. It didn't make assumptions as to how to do routing, or to fetch data, or to handle state. The community eventually converged towards a handful of solutions, like redux, but it was easy for each project to have its own combination of flavours and patterns.
Angular was an all-batteries-included MVC framework, with DI, testing framework, and one true way to do things. The reason why it's harder to introduce very low quality code in React is because React is just functions, returning JSX, executing when the function parameters change.
On the other hand, angular had comically large footguns due to its very high complexity. Have a look at the legacy documentation, the page about "scopes" by itself is longer and introduces more concepts than the entire "Thinking in react" page.
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.
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
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.
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.
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.
This seems unlikely. People are creating libraries and they're getting a lot of downloads because they're genuinely useful. It's a lot of work to write and maintain a library just for resume street cred.
I think the ecosystem has more of the opposite problem: engineers create libraries to scratch a particular itch, because they needed to solve a problem for their own project, or maybe it seemed like an interesting solution that they wanted to share with the world. If the person was working for a company, they may even be paid to maintain it for a while.
A bunch of other projects start depending on it, but the original creator/maintainer has moved on. They might not even be using the library for their own projects any more, nor paid to work on it. Now they're stuck maintaining it out of a feeling of obligation, or maybe it's a passion, but at a certain point it becomes unsustainable and the project becomes unmaintained or under-maintained (huge backlog of tickets). Maybe they find new blood to help out, maybe they don't.
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.
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
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.
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.
Yeah, I have to admit I don't really understand the need for front end frameworks in 2025 with how fully featured vanilla JS and CSS are.
With web components and a little bit of good architecture you can sidestep most front-end complexity. And server-side rendering dramatically simplifies state, because your state is now the database.
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.
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.
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.
> 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.
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.
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.
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.
No, but think about the trajectory. Most people new to building a frontend bare-prompt. There's value for them in using the most supported language, including support from AI systems.
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.
My dude, you're already operating on like five levels of abstractions, and you haven't the slightest clue how any of them work. The answer isn't another abstraction, it's learning how computers actually operate.
I once worked on a VK mini app with one guy. He was building the app itself, I did the backend. He just recently started learning web development, having never done any programming before.
So I'm ready for him to test my backend, I tell him to make a request to https://... and pass this and that parameter. And he just has no clue what I'm talking about. He somehow managed to learn React, a bit of HTML and a bit of CSS without any of the underlying basics. I had to explain him some of HTTP, the URL structure, and what an XMLHttpRequest is.
You don't need to understand how the engine works in detail, but in general, it's useful to know which operations are expensive, performance-wise, which are cheap, and what triggers them. For example, you want layout recalculations to only run when they're actually necessary. Or, if you want to move an element around, you should use transform instead of position as transform is "free" because it's a simple matrix multiplication that the GPU does anyway, but position might trigger a re-layout every time you update it.
> I care about building a great CX
I've yet to see a React website that doesn't feel sluggish and overall terrible.
I generally agree with you, but if you only care about technical perfection, it can happen that something is "technically perfect", but insufferable to use.
For example, I'm sure many of the common command-line utilities are considered technically perfect by their developers, but outside of some common use cases you've memorized, they are all a pain to use because of how undiscoverable CLI is by its nature. The "wrong input, go read some manuals" style of error messages doesn't help either.
I myself always start from user requirements and work my way down from there.
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?
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".
It's quite an oversight of the author did not to include Vue. Vue has it all and is as of now in terms of DX, features, ecosystem and performance (with upcoming Vue Vapor mode basically the same as Solid and Vue) the best choice.
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.
> The premise is bullshit... there were LOTS of competing options when React first came out...
Good thing that wasn't the premise, then.
The article is specifically looking at reasons for React's success other than its technical merits. It does not deny that it has merits, nor does it deny that its success is partly due to them. It only says that its current success is no longer wholly due to them, and backs the point up with examples of alternatives that are claimed to be technically superior and that are not achieving success commensurate with that superiority.
You can disagree on the superiority claims, you can disagree that innovation in this area is a good thing (many don't!), but I think the main claim is very believable: that in the present day, React's success is heavily helped by its default status.
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?
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.
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.
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.
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'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.
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.
> 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.
For me, everything depends on the site and the host.
For 80% of websites, a button is <button>, a router is just URLs that point to files, a state is just a json object in localStorage.
For 15% of websites, a button is <button>, a router is a single file that imports an auth provider and a storage provider which are chosen based on the host.
For the remaining 5% of websites which are actually true applications, I'd reach for a RoR inspired framework (so Laravel for PHP host, Adonis for js host, etc...).
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.
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.
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.
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.
I remember vividly the chaos before React and what it was like to not know whether it was worth investing in a framework because it might not be around for long. Vue was the first one that I stuck with for a while, but Nuxt was being updated slowly at the time and none of the packages ever seemed quite as seamless as the guys in React land had it. I don't even use more than a handful of unique packages per site generally, I just really need those to work out of the box (tm). It's amazing how many very popular slideshow libraries just.. Break.
I love the idea of a modern & efficient framework that replaces it all, but in terms of hiring, training, maintaining and all of those boring yet vital things it's going to have to be something quite special to make a case for itself. Being able to render 100k table line updates simultaneously instead of 10k or whatever isn't fundamentally going to make the difference for all of those other requirements.
When did I become this person. How depressing. At least there always fun new tech on the backend to play with on weekends.
> Being able to render 100k table line updates simultaneously instead of 10k or whatever isn't fundamentally going to make the difference for all of those other requirements.
React's performance are way more severe and ubiquitous and user impacting.
I'd really love to see the websites you're writing in React and lunch a lighthouse or to simulate how do they perform for somebody on a slightly slower connection or not being on the latest iPhone.
Because I know my users include bank clerks or post office cashiers on 10+ year old computers being used at work as much as people on vacation with very poor signal on the beach.
Of course, if you only experience your website from your MBP on cable you thing the issues are only at "10k rows" level.
We target <3s to usable on lighthouse mobile, ideally less but I don’t design the sites so only so much I can do about large above fold images etc. the truth is react isn’t that bad compared to latency or other issues on the kind of use case you’re describing
I should clarify - this is headless international ecommerce, so that 3s includes localisation, currency, inventory, cart, video, tracking scripts etc. If you'd like 200ms to live on a static site I can do that too, it's just a bit different.
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.
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.
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.
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.
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?
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.
Definitely feels more geographically based then. I worked at Humana and Comcast, they were both on the react train by late 2015/2016. This was northeast area.
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.
It's the inversion of the title. Innovation is unable to keep up with the winning React formula.
How much innovation is needed. often iteration is better and cheaper.
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.
I worked on a business app made with lit web components and all properties being stringly typed was a real drag. It didn't compare to a realtime-first component library.
At my large corporation, we are required to use a centralized React library for internal apps. So it is not “react by default”, but instead “React is the only choice”. 100% agree that our path out is for the central library to be reimplemented as web components to open us up to using whatever framework we choose.
That's a very normal thing for a big shop --- if it wasn't React it would be something else --- so kind of tough to pin that constraint on React.
Strong disagree. Web Components are react in different clothing. You don’t need this component-based framework style architecture to write applications for the browser.
I promise writing applications for the browsers is not challenging. You don’t need big frameworks or component madness that’s more of the same.
You don’t need big frameworks or component madness that’s more of the same.
You don't, but in any sufficiently complex app you'll end up writing a sort of 'mini framework' of your own as you abstract all the things that crop up more than a few times. That framework might be really nice at the start but it'll get more and more hacky as the project continues, especially if you're constrained by resources. Eventually you'll regret not using something standard.
If there are more than a couple of developers on the project it'll be something no one really likes after a year or two.
If there are more junior developers it'll be a reason for them to want to get off the team because they won't want to be a part of the 'old legacy code'. Then it'll be hard to find people who want to join.
Eventually, as it gets harder to recruit people to the team because it's on a weird, legacy framework that no one knows, there'll be a big project to refactor it on to something more standard. That'll probably be React. At the same time most of the senior developers will be calling to scrap the codebase entirely and rebuild it (wrongly in almost every case, but they don't care and want a greenfield project to play with new things on.)
This is a story that has played out at every large org that builds apps internally, and probably a lot of startups as they mature and need to hire more devs. You might as well skip all of it and use a standard framework from the start.
Sure you can make a blog without a framework. But for complex applications it’s far better/easier than raw DOM manipulation or rolling your own thing.
I disagree. It’s actually the same effort either way, but one of those costs substantially more to maintain and performs far slower.
It is not obvious to me which one you are talking about.
We should probably be making widget toolkits for the Canvas and using WebSockets for communication. DOM manipulation is a total hack-job. It's somewhat flexible, but the performance and dark-pattern cost is just too great. If you're making an interactive application, then treat it like an application and draw widgets to a canvas.
This is an insane take, show me a responsive button with hover state and a tooltip implemented in the canvas that outperforms a button rendered with React.
Accessibility suffers with that approach.
It doesn't just suffer it's impossible unless you recreate the whole thing with actual HTML behind the <canvas> rendered version.
HARD AGREE!
It just takes the minimal amount of discipline, and some conventions. I know it can be done because I did it, lots of people did it just a few years ago (some of those apps are STILL running today.)
Curious if has anyone had much success using web components within a react UI library? When building a component library on a bespoke design system, I'm quite pleased that I can rely on a headless library like RAC to ensure that the base component implementation is accessible and works well on touch devices. I can see theoretically that web components could be a complimentary tool, but in practice I'm not certain where they're best used.
Did duetds.com
>"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."
I avoid frameworks like a plague. Plain JS, web components and some good domain specific libs are more than enough to cover all my needs
I moved my entire business off React and now I don’t have to worry about tinkerers at Meta deciding to reinvent React every 2 years and tricking everyone by keeping the name again and again.
Web components are fantastic. They are the real future.
https://i.imgur.com/7ITZb7d.jpeg
Aren't web components a pain in the ass to use?
Nope
Lit.dev
I like lit. I'm not primarily a web developer and I've found it intuitive and easy to read and write. What I find more confusing than frameworks is building, bundling, ES modules, the whole NPM ecosystem.
React gets reinvented every year?
Are you talking about functional components instead of class components? What big changes am I missing here? It seems pretty static to me.
Agreed, Web Components don't require any framework and you can achieve everything you can achieve with React (including reactivity via attributeChangedCallback), the learning curve for Web Components is actually much less steep than React when you consider from the perspective of someone starting from scratch.
Furthermore, Web Components enforce good patterns; like the fact that you can only pass strings as attributes (by-value) is actually genius as it encourages simple, minimalist component interfaces and avoids pass-by-reference issues for which React community had to invent an entirely new paradigm to protect against (I.e. Redux state management with functional programming approach).
And the great irony is that a lot of the top people who are still pushing React are basically rich from Facebook shares and don't have to work anymore. In effect many of them are forcing this technology onto young people who have no choice in the matter whilst they themselves don't need to use it or do any coding anymore. Meanwhile I know a lot of developers who want to leave (or have left) the industry because of how bad it is and how few decisions they're allowed to make.
It's demoralizing to work with inferior tools when you know better tools exist because you use them in side projects... When you see this, you think to yourself "If the company forces me to be inefficient with my choice of tooling, this gives me a license to be inefficient in other ways."
Personally, I don't even code anymore (only on my side projects). It's a shame because one of my main talents is writing clean, minimalist code. In my day job, I'm using drag-and-drop UI platforms like n8n and Flowise (for AI). It's refreshing to be able to use vanilla JS inside the nodes, without a compile step and on a real-world project that actually pays. These UI platforms are actually much more predictable to work with than React. When I was using React (for almost a decade), I was constantly debugging weird glitches and state management issues; I never encountered those with Web Components or with platforms like n8n.
> the fact that you can only pass strings as attributes
This isn't true at all though. It's a lie started in the early days by React engineers that just won't die, unfortunately.
Web components are objects and they can have properties and accessors like any object. The vast majority of declarative template systems like React, Lit, Vue, Angular, Svelte, Solid, etc., will declaratively set properties - which can carry any type of JavaScript value, including complex objects and function - on web components which can then be used to update the component's DOM.
That approach passes values in JS rather than the DOM, right? I read the go comment as talking specifically about DOM attributes which can only be strings (well, you can have boolean attributes as well).
Web components can be passed objects in JS, but its news to me if that is available in HTML.
Neither can react
I didn't say it can, I never actually mentioned react at all here.
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.
I have been a part of quite a few tech stack decisions at various companies and startups. I have literally never heard an argument made for react that included merits of the framework itself. The decision was always based on a combination for familiarity, ability to hire for eng roles, and the ecosystem.
Im not sure how this is a negative merit for React.
Besides if you are a small company, or a start up, your job is to get things done. Not to embark on a global technology crusade to push your favourite tech.
By and large the best thing about react is the overall ecosystem, libraries, talent and ubiquitousness. And thats a good thing.
It isn't necessarily a bad thing, but it doesn't align with the idea of how good react is or the technical merits of it.
I also am not saying teams I have been on that picked react made the wrong choice. That's all in context and as you said startups are often in the "get things done" mentality where tech debt won't matter if you can't survive long enough for it to matter.
It’s good enough that the ecosystem outweighs the superiority of something like SolidJS.
React has React Native as part of its ecosystem. That’s a massive advantage. react-strict-dom is going to be a game changer for the development of universal apps.
We're talking about two different topics here. I agree, the ecosystem around react is huge and there are reasons a team would pick react. Ecosystem isn't an indicator of the technical merits of react itself though, and that's what I was originally responding to here.
You’re assuming webdevs are rational creatures which in my experience is far from truth, since they easily fall for human biases traps such as “social proof” and “authority”.
Never heard, "man react is great!" It's always, "we can hire more easily".
Unfortunately
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.
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.
The amazing thing about React to me is that millions of dollars keep flowing into improving its DX further. They have spent a lot of time building React Compiler (https://react.dev/learn/react-compiler/introduction) which does all the memoization for you! This severely lightens the performance concerns.
Sure, but Svelte and Vue have had these compilation features built-in for ages without all that money flowing in.
The react team resisted these features because they went against their “it’s just a library” philosophy. They’re only copying them now because of how obviously useful they are in the other frameworks.
useEffect, useMemo, useCallback etc. add a ton of complexity and make it easy to write buggy code. I used to work at an agency so I’ve done projects with React/Svelte/Vue/Lit/Stencil/Angular/etc. I found the React projects had lots more performance issues, confusing bugs, etc. than Vue or Svelte.
I agree with the article. React is popular because it was groundbreaking and now is the default, but it’s far from the best
And the moment you need to increase complexity in your app, you need to add back react.
I'm a counter example of your claim. Migrating away from React did made the complexity of my app a lot more manageable and unlocked new business opportunities that would have been impossible with React without following the JIRA route of making the software worse for 99% of users because 1% of those needed something. The project in question is Filestash (https://github.com/mickael-kerjean/filestash), what made me switch are those 2 reasons:
- Performance ceiling. Past the point where you have used all the react specific optimisation tricks (useMemo, etc...), React just gets in the way, once you start to optimise things to reduce the memory footprint, optimise for 60FPS, dig into heap snapshots and allocation traces, your life starts to become miserable where you need a complete understanding of not only your app but also the inner working of React, and the intersection of both React with your app. At that point, you either accept the ceiling or rewrite everything to vanilla JS and have complete control over every piece of the code you are shipping to the client
- Extensibility. I am now shipping plugins which patch frontend on the fly without any build step. In practice, after a plugin author packaged their plugin (as a zip file containing a manifest), the patches are applied in real time by the server without a prior frontend build system (open up the demo instance with the network tab open to see this working from: https://demo.filestash.app/). This powers themes with icons swaps, new behaviors (e.g. a "recall" button for files in Glacier), and other things plugin authors come up with that that makes the app far more customizable and opened for new niches without falling onto the JIRA trap
Maybe, maybe not. It's not the only sponge, unless it's the only sponge I know.
>"React is great at solving complex problems."
The only thing it is great for is creating complex problems out of simple things.
React is totally fine for solving simple problems.
I'd classify pretty much all frontend web development I do as simple. It's pretty much just boring internal websites, I definitely don't need react for them. Could have made the same thing with any other frontend framework, could have made it server-side rendered. React is totally fine for that. The backend is generally more exciting than the frontend. React is totally fine.
The main problem I see is that most other developers are really ass at their jobs and just overcomplicate everything. I've seen very simple apps have a super complex React codebase, and due to the complexity they're always full of bugs. It's much more rare that I see an elegantly simple React app, or any other app for that matter. Everyone just always overcomplicates everything.
Using React doesn't in any way require you to make it complex. You can make React apps dead simple. And if you are comfortable working with react you'll already know all the solutions to all the problems which makes your job extremely easy. You can breeze through and make the entire simple app in a few days if you know what you're doing. Or you can pick up some new fancy tool, hey let's try Svelte. And now instead of a few days we're gonna spend a few weeks and end up with a codebase that reflects our Svelte experience. And hey look it's time to onboard a new team member - hey guy, we have these three apps - this one's made with Angular because one dimwit wanted to learn that, here's a Svelte app we made last year and lastly here's a HTMX app we made when that was hot. Good luck learning 3 new technologies you'll probably never use again!
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.
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.
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.
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.
> 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.
> 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.
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
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.
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.
> Google functionally controls just enough of a monopoly via chrome that they can generally do whatever they want
Crazy statement. Any API not supported by Safari might as well not exist.
How many APIs in Chrome today will never appear in Safari?
WebSQL? WebUSB?
It seems like Safari bends towards whatever is in common use, at least within a few years.
> 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.
We are mostly there and I am all for it.
No other GUI runtime or framework delivers true cross platform implementation. HTML, CSS and js are as open and as standard as it gets.
GTK sucks in its own ways and is not international standard.
To be fair browsers/CSS have been solving a lot of use cases you'd normally turn to js for, lately. We should continue escalating this effort.
I'd go further and suggest that we need maybe five or six browsers. One for shopping, one for banking, one for socializing...
Let the platforms for these things compete on the back end only and provide a uniform experience on the front end across competitors. This way the people writing the code that runs on our devices don't have conflicts of interest that lead them to betray their users.
It would also be easier to use because once you know the structure/flow/hotkeys for one bank you're now wizardly at navigating the interface for every other bank.
It's just such a waste to have each business writing a separate front end even though what they end up with is always more or less identical to their competitor.
Sandwich shops should compete by making a better sandwich, not by outmaneuvering each other re: how they leverage the app they managed to get 8% of their customers to install.
Frankly it's incredible what any of these frameworks have been able to accomplish given the bonkers platform they have to work on.
HTML, CSS, and JS made sense back when the web was primarily text with some simple forms. It's a dog shit foundation to build highly interactive apps on. The whole thing needs to be thrown out and rebuilt.
Webapps were a mistake :(
The frustrating part is that the idea is incredible. Everyone has this piece of software on their computer that lets them run anything as long as there is a server to talk to. I love it. I don't want to have to download a thousand apps, especially not for shopping or banking. Just using a web interface is awesome.
Unfortunately we decided the correct way to provide the functionality was by layering bonkers ass abstractions on top of a system meant to largely display static text and images. In the year 2025 there is absolutely no reason we shouldn't have a unified coding language that allows you to render things in a web browser in a sane way.
At the very least we should have seen a substantial expansion of what HTML is capable of, closer to what HTMX is doing now, with a better way to style everything then fucking CSS. People complain about JavaScript but for my money CSS is the greatest sin.
Almost all phone apps could be a web app
A great native app on an iPhone feels far superior to a mobile website. The gestures, the stack navigator, haptics, scrolling, native ui primitives, etc…
Also iOS accessibility screen reader APIs are way better than the web. Accessibility actions for instance are great.
> 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.
The dependency array thing is really easy if you use eslint with the react rules of hooks.
Prop testing with fast-check helps alot I've found for when little things change
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).
+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.
React DX is probably the worst DX of all frontend frameworks I've ever seen. All kinds of confusing concepts (hooks, memo, props passing, class style vs function style, an entire new "language" like JSX which you then first need to install an IDE extension for) and you cant even begin a react project most of the time without using some kind of react starter template because building this thing is so hugely complex that people just give up. Then you constantly run into issues of double rendering with reactjs which is quite hard to debug. I was hoping for something tiny like https://www.arrow-js.com/ taking off but the creator doesn't really work on it.
Honestly I think React DX kinda sucks, at least in some areas. Performance is one of the worst (`useMemo` and `componentShouldUpdate` are way to easy to ignore, constant re-renders are the norm and writing performant React code requires conscious effort to avoid footguns) but it's also just less self-explanatory than the alternatives I've tried.
I started doing web dev before reactivity frameworks were a thing, and I found Vue to be the most intuitive of the frameworks available when I first needed reactivity. To me, Vue feels like HTML with superpowers while React feels like a whole new way of thinking about webapps. I'm honestly a bit surprised that the article doesn't mention Vue, since Vue is (and has been for a while) the most popular "not React or Angular" framework option. Newer versions of Vue even support the "disappearing framework" feature Svelte was built for, which I'm excited to take advantage of when my biggest work project finally moves to Vue 3.
I think you've nailed it. It does come down to user preference.
React _is_ a whole new way of thinking. Back in the days of jQuery it was very painful to stitch together web experience across HTML+CSS+JS. jquery provided much needed DX around utilities to navigate across these pieces. But it was still way too easy to treat HTML like your database and model user-state across a Frankenstein of server, json, html, and javascript.
React was a paradigm shift. "Screw it, everything is javascript." The web depends on js runtime, we know we're going to need it. It starts to makes the best future-forward sense to use the only full programming runtime available. From DX pov this was spectacular to speed up prototyping. And you can finally truly model state purely from data.
What followed was a huge a mess (redux), but I always say, what do we expect? The web is a mess, and it's great because it's useful. Humans are a mess!
--- VUE: similar to angular I just don't align with "super-powered html attributes". It just doesn't make sense as a mental model. Because it's _not_ HTML spec and HTML is not a programming language. The more powerful the framework gets the more we reinvent a pseudo-programming language _through_ HTML. Angular was full-stop a no-go when I first saw it's for-loops in HTML.
You are correct. JSX is not “just HTML”. It’s “just interleaved HTML and JavaScript”.
`v-bind:id` and `@click.prevent` are something else. There is nothing like this in JSX. It’s not HTML. It’s not JavaScript. It’s some other language.
Neither react's JSX nor vue's template language are HTML. But rejecting vue's template on grounds that it's not HTML seems odd. React's JSX deviates from HTML in many ways. Like class vs className. XML self-closing vs HTML self-closing. onchange vs oninput. On purely aesthetic grounds, I can't understand how the react idiom of array.map() would ever be preferable to an affordance in the (non-HTML) template language for handling this normal standard thing that always happens.
it's not about feigning html purity it's the opposite. Why pretend we're using HTML when it's not? so with react it becomes a js flavor, jsx, which some people hate but it's very clear that it's a made up language IN real javascript.
edit: the mental model is instant: it's just javascript for reals. do anything you want in javascript using real js primitives. it's not about looking pretty, jsx doesn't. it's about not relearning basic programming primitives in a made up _markup_ language.
my issue with angular is it's neither real html nor any programming language. its made up pseudo-programming language for no other reason than it fools people into thinking "it's just HTML". that's my gripe.
Completely agree with you. Every time I see yet another template language adding some clumsy for-each loop syntax I sigh. Just let us use a normal programming language. As an example I give you every template system ever invented. Devops tooling is full of them.
Both the Vue template language and JSX are supersets of HTML. However, when it comes to integrating with CSS, JSX significantly worsens DX.
I don't really recommend isomorphic environments, but if it's your cup of tea, Tanstack Start is making a lot of progress. It removes all of the magic and misdirection of Nextjs and just provides a good light alternative.
Issue with all things tanstack is they change everything constantly. The Tanner guy really does make decent libs but he drops em pretty quickly for others to take up maintenance on which makes it risky to pull into any production app.
The best library are the complete ones.
AFAIK "TanStack" doesn't support RSCs? That's a deal breaker for me. Also the guy named his framework after himself, it can't be good.
Linus named Linux after himself, it can't be good!
For the record, the TanStack name comes from the community. Eventually Tanner stopped fighting back and made it official
They built a half baked version of it and then haven’t finished it for a while but maybe they’ll get back to it sometime.
Linux also sucks for this reason /s
Could you please elaborate on why you don't recommend isomorphic environments?
Next initially jumped the shark when they went all-in on server-side rendering. The reason why Vercel did this is clear: client-side rendered apps can be hosted basically for free on Firebase, Cloudflare, or S3, so the only way they can raise their Vercel cloud revenue is by forcing their users into a dynamic-first world, pushing so much complexity and dynamism into the framework that only Vercel could disentangle how to host it effectively. The less-dystopic reasons they communicated as to why customers might want SSR; improved time-to-first-byte and a more PHP/Rails-like programming model; while well-intentioned, ultimately became of questionable value to customers given their choices during implementation.
I do actually believe a more PHP/Rails-like programming model would be beneficial for React; Vercel just missed the extremely important detail in how Rails is so dang productive. Its not their decisions when it comes to HTML templating; its Active Record.
React DX is hot garbage. Words cannot express how much I LOATHE hook rules. Coming from a Solid JS background, where reactive primitives are just Javascript functions... I groan every single time I run into (yet another) hook rule.
I have to conditionally render empty fragments because React can't handle conditional hooks. It's the stupidest thing ever. "Oh hey let me allocate memory for this hook that will almost certainly never be used except under edge conditions! Sure, React can do conditional components, but conditional hooks are just too much for us!"
> I groan every single time I run into (yet another) hook rule.
There are only two rules:
1. Only call Hooks at the top level
2. Only call Hooks from React functions
Per https://react.dev/reference/rules/rules-of-hooks
Not sure I understand the conditional beef, perhaps you can give example? I would assume if you want `if condition, useEffect(...)` you could simply replace with `useEffect(() => if condition...)`, no?
Fair. My bitching would've been better expressed as "I groan every single time I attempt to violate a hook rule." Which is a lot, because I'm new to React. It's almost certainly a "skill issue", but hooks are NOT just "JavaScript functions", contrary to React marketing PR.
My conditional beef: in my app, users can choose between using the built-in mic for speech recognition or a 3rd party service (LiveKit). If the user chooses the built-in mic, I still must allocate memory for LiveKit's services because it's exposed as a hook, even if the user will never use it. This problem compounds - every option that I expose that uses a hook requires that I allocate memory for an option that may never be used. Also TTS - users can choose to use the phone's TTS, or a remote service, etc. Every option I offer, if the library exposes it as a hook (and they virtually always do), if I naively implement the feature, allocates memory for a hook that might never be used.
Fuck. React. Hooks.
My workaround is to conditionally render empty fragments. These fragments wrap hooks, which I then inject into the context. This makes it so I can conditionally run hooks. This is why I complained that React can handle conditional components, but not hooks. Concretely: https://pastebin.com/sjc3vXTd I'm using Zustand because god I need a lifecycle outside of React.
Y'know how people complain about how Async "colors" functions? Hooks are also a type of function coloring. And they don't compose with Async.
Yeah, this is a really annoying thing about how hooks work. For whatever reason (I'm sure they have a great reason) React can't do hook state book-keeping correctly without tying it to a function component lifecycle.
I think you actually can conditionally render a hook but that choice has to last for the entire rendered lifetime of the component. But that doesn't really help you when your user can switch between them.
Hooks are also just JavaScript functions...?
Based on how they are run they are completely not just ordinary JavaScript functions, hook era components are also not just JavaScript functions, it's a very complicated system. React calling them "just functions" is untrue, just marketing buzz words, and it leads developers into traps.
Many functions can only be called in a certain context. Calling them "not functions" is misleading imo because it implies those functions are compiled out or something, like `$state()` in Svelte.
Yeah they themselves are functions but how they're called are managed by a complicated system, I think treating them as a separate new concept is less misleading than calling them plain functions
They kind of are not though, you can't call them out of order and other things which is checked at runtime by the React "engine" and will stop script execution. If they were regular functions you could call them anytime.
Many "regular" functions are context dependent.
They are context dependent, must execute in the same order every time, and must be called every time the component re-renders (i.e., they do not support conditional calls). They have enough gremlin rules that calling them "just functions" is unhelpful for reasoning about using them.
I read things like this and think “I am so glad I don’t write JavaScript/ web-anything for a living”
cries in ts backend, react frontend, react-mobile client
> if the cost is an extra few milliseconds of render time and few extra hours of dev time
That is very optimistic. Most React projects never get to the optimization stage, and end up with seconds of rendering and transition delays that significantly harm UX. And the amount of time spent battling hooks, re-renders, compatibility issues, etc amounts to hundreds of hours over the course of a medium-sized project, thousands for larger companies.
“Most” react apps needing “seconds” definitely needs some citation or evidence. Even in fairly heavy and laggy react apps, it’s still usually network latency, waterfall requests, ad/tracking bloatware, large asset sizes, and the usual old classics that cause perceptible slowness in my experience.
In my humble (backender) opinion, if it's hard to use a tool right, that counts as a cons, and that must be accounted for when choosing which tool to use.
It's hard to build non-trivial web UI with any technology—React is just what's familiar. If Angular had won (god forbid) we'd be seeing all the same articles written about how bad Angular is.
You probably never see what reddit like after it just get rewrite. https://www.reddit.com/r/bugs/comments/rj0u77/reddit_redesig...
I won't say most react apps performs like this. But it's what you will get if you ship a big react app without optimization at all.
Other framework mostly have a much saner default (for example, component without argument change does not re-render). So it will work well (not best though) even in large scale. But in react they are all opt-in.
Mcdonalds is really good. Even if the cost is an extra few pounds and increased chance of getting cancer.
If Mcdonalds starts taking a backseat, it’ll because its no longer really good. And, to be fair: I’ve started to see this happen. Mcdonalds & Coca-Cola have totally taken over the food industry world, and they’ve proven to make quite poor nutritional decisions. All great empires are destroyed from the inside, not out, and I think its possible Coca cola could do this to Mcdonalds. But also even as Coca-Cola seppukus itself, people will likely just fallback to Mcdonalds on Pepsi (or, there’s Pepsi Zero Sugar that’s I think still under development, but might end up being big).
If React implodes because of bad architectural decisions, Vite should fork it.
It's crazy that the best React DX is provided through Vue's community projects.
Why don’t we just switch over to Vue? If DX is such a driver for deciding to use a web framework, Vue kicks React’s ass, and that’s just objectively speaking.
I did switch over to Vue.
Well not technically switch, I never learned React properly because I didn't like it when it first came out and by the time I gave it a second look there were already a gazillion React devs so I just stuck with Vue.
Vue just seems much more intuitive and sane to me. Sane is relative for front end frameworks of course. Don't get me started on Angular I got PTSD and couldn't code for a couple of months from a large Angular project with an offshore team.
I do get the benefit of using these framework for teams, and they are nifty once you get what is happening, but I still scratch my head when I see all the steps and files to do simple things I used to bang out in a few dozen lines of jQuery.
My main complaint about React is the sort of lackluster quality of loads of React-adjacent libraries, by people who seem obsessed with "we're doing Yet Another Rewrite and a major version bump".
It's not that hard to maintain API stability folks! Try a bit harder!
React is popular in the modern days only because, well, it's popular. Developers use it because companies use it, and companies use it because developers use it. It's not popular because it's better than all the alternatives, it's just that it has reached critical mass, and it's now "too big to fail". It takes constant effort to avoid React's many footguns. Supporters often call this a “skill issue,” but even if that’s true, why wouldn’t you prefer a framework that does the same things with less code, faster, and with far less mental overhead?
Super insightful. I hadn’t been able to articulate the same feelings.
This is my exact read on the situation, as well. I’m not sure if anything can meaningful affect React’s domination in the short-term or medium-term, even with the accumulation of poor choices.I haven’t tried tanstack-start, but I wouldn’t be surprised it becomes the defacto react framework instead of next. Everything by Tanner Linsley is just so well thought out and the DX is amazing. If his framework is the same level of quality, without any major gaps compared to next, it will probably blow next out of the water.
And Tanner is already a huge name in the typescript/react world, so I think there is actually a chance.
Thank you for your kind words and support!
If react adds extra render time and extra dev time, what is it saving?
Time spent implementing features / components that don’t exist for the alternative framework of choice, or trying to figure out a framework bug in your own because there aren’t enough other developers using the framework to have surfaced and resolved all the bugs.
funny you should mention react on vite - i migrated a web-app to that setup ~3 years ago and never even considered looking back. react is still a trusty workhorse that assists me in getting things done, the ecosystem is rich (i'll take the varying quality as a given for one this size). I've been toying around with next a couple years ago, followed their development for some time, then decided they are not doing what I need. Isometric rendering turns out to sound way better than it actually is. The pain doesn't come from different programming languages on front- and backend, it comes from the difficulty of reconciling client state, server state, security etc. I actually find it helpful to have specialized languages for each side, rather than having to figure out for each piece of code wether its supposed to run on my server or in the browser.
Remix 3 appears to not be based on React. The React Router/Remix people write great libraries. The problem is that they're constantly chasing the next great library. By the time you use their latest creation, they've already started making a new library that they'll tweet about
Maybe us backenders help. If I need to do front end I learn as little as possible. React does the job. It could have been Angular that ended up being in the boring throne, and I would have said just use Angular. Just use what the world uses!
I'm a backender that writes UI PoCs to test the backend where the PoC gets pushed to prod. I just write custom JS updating HTML/CSS elements directly. No frameworks. I've been told it's a nightmare to deal with later, but it makes perfect sense to me. Not once have I ever claimed to be a UI person. That's just way too close to the user for my liking.
Angular is so much nicer and more batteries-included than React. React somehow manages to be massively yet incomplete: add a router, add state management, add react-hook-form...
That's why it's so good. You can pick what you want instead of being told what to do.
https://en.wikipedia.org/wiki/The_Paradox_of_Choice
In practice, at scale, in an ecosystem instead of a toy project, excessive choice is counterintuitively a bad thing.
It's hugely beneficial to have common ground and shared interfaces when integrating code from third parties, or collaborating across multiple teams.
> You can pick
A golden rule of large enterprise is that there is no "you".
As soon as there are two people working independently, not to mention different business units or teams, different choices will be made. Incompatible choices.
This is very true and almost nobody sees it...
Angular is used a lot in enterprise apps/services when they need a low risk one-way to do things (e.g. Apple's App Store developer portal).
React is used in enterprise when teams need to move fast and break things (e.g. Microsoft Edge's UI after switching from Trident/Spartan/EdgeHTML to Chromium) and tend to be replaced with something else when dev teams / managers realise that they need to rebuild it anyway just to keep it maintained and/or gain more performance. (e.g. Edge "WebUI 2.0" moving their browser UI from react to web components)
Vue is used a lot in Asian enterprise markets.
What is Vercel doing to React? I just know them as a simple hosting solution.
For one they're shifting React to require a hosting solution.
/snark
At least in my own experience, I tried building a relatively simple static SPA NextJS React app with their router, and wanted to host it on CloudFlare Pages.
It ran locally in dev mode just fine. Once I deployed it on CFP, the router broke. No errors in the console, it just didn't work.
If I'm forced to use Vercel to make a simple SPA work, which then forced me into paying for their service, that's the problem.
OpenNext on Cloudflare is the only way I've successfully gotten NextJS to work in a Cloudflare Worker.
https://opennext.js.org/cloudflare
Interesting. Yea, I didn't want a worker, just a static html page with my javascript.
You need to configure it for static export if that’s what you want: https://nextjs.org/docs/app/guides/static-exports
But this won’t support all framework features. The default expectation for Next.js is with a server runtime for SSR.
Vercel is anything but simple. Easy? Sure.
They developed next.js
A front end web framework with global state management should be a last resort for a website. Coming out of the gate with it is just ridiculous IMO. Most peoples websites are just not that complex.
There's like an escalation ladder in my mind:
- just write HTML
- statically generate the HTML
- dynamically generate the HTML
- dynamically generate the HTML at a smaller granularity (HTMX et all)
- augment your HTML with custom web components that have client side behaviour.
Only if you've exhausted that should you bother with something like React. And even then SolidJS does a much better job of it than react itself does.
So yeah, I am just not seeing it. Former (and perhaps future!) React.JS dev btw.
To be nitpicky, React itself does not specify that state management must be global. It was a popular pattern, starting with Facebook's blog post on Flux and made popular by Redux. And certain newer features like hydration/SSR and suspense more or less require a global store because their data can't be kept in the tree. But in many cases you can keep state local with useState and Recoil/Jotai and frameworks that keep global state/caches abstracted away like TanStack Query.
For progressive enhancement, I like the island approach used by Astro. I do think that most developers are not just building static sites though. And if you're generating HTML on the server side and then updating it dynamically on the client, having two different languages (Java/Go/Python on the backend, JS on the frontend) becomes messy pretty quick.
There are times where you should build the simplest solution that meets your needs, and times when you should think ahead to future use cases so you don't box yourself into a corner. And picking a framework is a big part of that process.
fwiw i've never experienced the drawback of separate languages for server and client. nor did i ever experience the benefit of single language across server and client.
being forced to use javascript on the server sounds like a cruel joke vs a benefit. I mean just simply from "i can literally pick anything for my controlled server env" vs "no we're a js shop cuz web"
edit to add: is it one repo? or maybe shared types. typescript is probably the strongest argument. can enforce integrity truly across the stack. but i don't think that's worth being forced into js environment and packages. community is forced to reimplement everything in js. no good.
HTML templates and the shadow DOM solved the only problem of separated languages that I have ever actually seen.
So yeah, once there was a benefit for using the same language. IMO, it never was worth the cost. But it doesn't exist anymore anyway.
i'm bookmarking this comment. great cascading list!
agree as a 10+ year customer facing product person doing tons of react.
I just use svelte. It works with raw html.
Maybe I'm stupid, but as I recall, React hooks were quite complicated. It's been a few years since I wrote production front-end code, but it felt like some kind of high IQ/elitist barrier.
I'm not sure I'd say that React's DX is actually that great. I've watched C++ developers come over from using QT and the learning curve is massive. Plus almost all the bugs come from dealing with React's renders.
I think React by default is weird because most things don't actually need that degree of reactivity. Like, if most of the time only one thing is displaying or updating a value React just adds a lot of headache. And the amount of useEffect I see? (By necessity mind you) with the need for linters in order to figure out if you missed something in a dependency list.. I just think it's the wrong model for most projects
Remix v3 isn't react though, the alternative is react router 7
React router have completely bungled their marketing and PR, but they still make the best web framework out there
> Even if the cost is an extra few milliseconds of render time
These things are adding up. Web would be much more pleasant without React. There are many better options out there.
Maybe it would be, but I would also make a significant bet that the web would be noticeably less sophisticated without React. React is complicated, and builds complicated apps, and has its performance pitfalls, but it is also a driving force for how the web has been able to achieve native-class user experiences. Its the right programming model for building complicated things.
Websites were much more varied and creative in the jQuery era, and even more so in the Flash era that came before. Different interaction paradigms, wild animations, full-screen effects, etc etc. Not necessarily "better", but React didn't really enable anything we couldn't have before - even today when real performance is required you will resort to canvas/webgl, alternative rendering approaches and skipping react's render cycle.
React was never [1] fast [2] - that is one of the biggest misconceptions in frontend development in the last decade.
[2] https://css-tricks.com/radeventlistener-a-tale-of-client-sid...
[1] https://www.zachleat.com/web/react-criticism/
I wrote websites in the jquery era. I wrote web apps back then. Gaming tools, databases, tons of dynamic stuff.
When I used react for the first time I cried with “where has this been all my life? It would have saved me years of work”.
Whenever I see claims like yours I always have hardcore doubts. React may not have “enabled” new things just like ai coding doesn’t “enable” new things … as long as you consider time to be in infinite supply. If you care about getting shit done, there is no comparison.
How is it good? I've only had the misfortune of working on two React apps, but they were both a nightmare. It seems like React is great if you have multiple teams that hate each other all working on the same giant frontend app.
https://medium.com/@fulalas/web-crap-has-taken-control-71c45...
It's good because it's popular, which doesn't really mean it's good. See Java. It works and rakes in billions, but it still may be utter shit from an engineering viewpoint.
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.
I agree 100% on the added cost and complexity. I think a lot of that gets masked by the boilerplate that makes it so easy to get started. Then they have their hooks in you and 6 months or a year later you are scratching your head and hiring “react developers” to help solve the problems you were trying to avoid.
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.
Which is your favorite, and why? :-)
No OP, but I've also used Angular, React, Vue, Solid and Svelte in real world projects and my default choice is Vue, because it's on par with Solid and Svelte (and with Vue Vapor those three are basically the same) but with the larger ecosystem (vuerouter, vueuse, nuxt, nuxt-ui, primevue, nuxt-content, ...). I must also say that React was by far the most unpleasant and unproductive to use.
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.
> 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.
It's usually not the framework that causes apps/sites to be slow.
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.
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.
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.
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.
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.
Umm…hate to break it to you, but https://youtu.be/NeJ6wq2szVs?si=RFwtccO9_QH1CJzY
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.
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).
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.
Css in js was like a fever dream that lasted 2-3 years and seems to mostly go away. It's a good example as to how the frontend world just seems to make bad decisions.
Like if you take React's server components, it has a ton of problems and gets excessive focus from react devs, but fundamentally I can agree on what's its trying to solve. I understand the need, even if i disagree in almost anything else regarding it. I still don't know what the css in js phase was about.
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
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.
I remember seeing Mint quite a few years ago. I love the idea, I really like the language design, but I agree 100% with your take on the drawback. It's hard to sell that to teams.
What's surprising to me is how many alternatives exist in this space. Between elm, imba, svelte, and mint, and probably more that I don't know about, I wonder how many devs in the world are shipping to prod using them.
edit: have you thought about including Form Validation to the core lib?
The Mint website is quite lovely! Props for making something so nice and pleasant and clean and easily navigable and informative.
Thank you! And it's written in Mint :D
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.
"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.
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.
You are right. But the difference is a C compiler in theory can add optimisations, but React is a runtime and cant optimise your code (just itself).
That said if React were to be adopted as a web standard it might be possible.
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.
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.
> 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.
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.
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.
> 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.
This is the most pedantic section for me, it’s just a bunch of 5 year old illustrations with 0 explaining on how React actually works behind the scenes: https://react.dev/learn/render-and-commit
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.
[0] https://react.dev/reference/react/useEffect
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.
[0] https://react.dev/reference/react/useEffect#wrapping-effects...
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:
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...
Here is an alternative vanilla approach that uses a single-file/single-class-declaration custom element without Shadow DOM: https://jsfiddle.net/auxiliarymoose/tcgk1Ljv/98/
Usually I write a few helper functions to streamline working with elements, attributes, and registration of element + CSS. But even without those, I think this approach provides a good level of simplicity without introducing libraries or frameworks.
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.
I don't know if I'd consider that the reactive callback because there's no change in state if I only put the `console.log` in `onChange`. The point of the reactive callback is to be invoked on a change in state and in this case, that is the component function would you agree?
In Vue, for example, when I set up a `watch`, the change in state only invokes the callback that is wired to the state. In React, the entire component function is invoked again on a change of state.
Yeah that's a pretty good way of putting it. In Vue et al, the script tag is a constructor and the template is a render function. In react, you just write a render function and use hooks to define stuff that otherwise would have been in the constructor.
"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.
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
While something like Vue or Svelte could implement their own inline macros rather than investing in tooling for their custom file types 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)Js has decorators for class fields so you wouldn't even need a macro for that. `@state accessor value = "hello world"` works.
I do like the idea of macros in general though.
I explored JS decorators in the past but decorators are different in that they are a runtime operation that can't be statically compiled and can't be used on non-class properties.
You probably know this already but macros on the other hand are just dumb expansions/computations of syntax transformed at compile time, like
Would compile into Including macros into the JavaScript spec is a bit weird because it's an interpreted language so compile-time concepts don't really make sense (which is probably why decorators were proposed).But JavaScript is compiled more frequently than it isn't and we apply a crazy amount of transformations to it (typescript, tsx, path manipulation, styled-components, etc). IMO standardized compile-time manipulation with LSP integration would go a long way for language ergonomics.
That would also mean transformations for things like jsx could be run _in the browser_ allowing people who don't want to use a bundler to run their code without one.
Projects like this : https://github.com/developit/htm are an expression/symptom of that needOh yeah I agree it would be useful.
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.
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.
Plus, I have no interest in front end innovation. I think HN and Craigslist are as good aw it gets.
The day we stop "innovating" in front end by inventing new UI's every month, global productivity is going to skyrocket.
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.
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.
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)
You don't even need RSC to fix waterfall fetching, relay solves this problem beautifully.
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).
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..
Hill I’m willing to die on (figuratively): Most websites should be readable on w3m (or lynx, or emacs’ ewww).
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.
I wouldn't say I've worked at companies where the framework is exactly what holds back deliverability, but I have worked in plenty of environments where a complex front end is multiplying the work required to get a basic CRUD product out without a ton of benefit.
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)
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)
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.
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.
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.
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.
Not a single mention of 'Vue'
Yes, quite an oversight ... as Vue has it all: Adoption, maturity, ecosystem, features, DX and speed (with upcoming Vapor mode even on par with Svelte and Solid).
to me react is losing as I switched to vuejs and life is way more productive
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.
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.
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.
If every other framework failed because of <insert reason here>, that does indeed sound like React won due to its own merits.
Google's incapable of sticking to anything good. Nobody gets promoted at Google maintaining a system. So somebody inevitably gets the idea to make a 2.0 which isn't backwards compatible, enabling them to do all sorts of bold promotion-worthy innovation. And inevitably 2.0 isn't very good. Even worse, it makes the entire ecosystem confusing and unhealthy.
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.
You are 100% right. Maintaining angular.js for large scale app is pain.
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 :-)
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
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
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.
I cannot upvote this comment enough.
I am so glad to be old and have lived through the transition from Angular to React. To understand why we have React. In fact I am so old I have lived through the transition from Adobe Flex to Javascript Frameworks first.
And the thing that is clear to me is that wave of Javascript Frameworks, of which Angular was one, looked at Flex and leanred all the wrong lessons (I'm looking at you two-way data binding) whilst React got second mover advantage and learnt all the right lessons.
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.
Well, that's just argument against angular 1.x
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.
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.
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.
React's benefit was absolutely technical. Its component model and one-way data binding was so much simpler to reason about and elegant than Angular. So much so that they ended up copying it in Aungular 1.6 and Angular 2.x.
One of the biggest criticisms at the time (And perhaps still now) was that it wasn't opinionated at all. It didn't make assumptions as to how to do routing, or to fetch data, or to handle state. The community eventually converged towards a handful of solutions, like redux, but it was easy for each project to have its own combination of flavours and patterns.
Angular was an all-batteries-included MVC framework, with DI, testing framework, and one true way to do things. The reason why it's harder to introduce very low quality code in React is because React is just functions, returning JSX, executing when the function parameters change.
On the other hand, angular had comically large footguns due to its very high complexity. Have a look at the legacy documentation, the page about "scopes" by itself is longer and introduces more concepts than the entire "Thinking in react" page.
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.
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
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.
Now you’re forced to use react even for simple pages that just need that one component.
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.
Not optimal, but also easy peasy.
One thing I like about React is that if you want it can be very simple.
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.
This seems unlikely. People are creating libraries and they're getting a lot of downloads because they're genuinely useful. It's a lot of work to write and maintain a library just for resume street cred.
I think the ecosystem has more of the opposite problem: engineers create libraries to scratch a particular itch, because they needed to solve a problem for their own project, or maybe it seemed like an interesting solution that they wanted to share with the world. If the person was working for a company, they may even be paid to maintain it for a while.
A bunch of other projects start depending on it, but the original creator/maintainer has moved on. They might not even be using the library for their own projects any more, nor paid to work on it. Now they're stuck maintaining it out of a feeling of obligation, or maybe it's a passion, but at a certain point it becomes unsustainable and the project becomes unmaintained or under-maintained (huge backlog of tickets). Maybe they find new blood to help out, maybe they don't.
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
"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.
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
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.
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.
Yeah, I have to admit I don't really understand the need for front end frameworks in 2025 with how fully featured vanilla JS and CSS are.
With web components and a little bit of good architecture you can sidestep most front-end complexity. And server-side rendering dramatically simplifies state, because your state is now the database.
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.
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.
>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.
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.
That sounds like it would take extra work. I’ll leave it to the LLM.
> 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.
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.
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.
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.
Even if you tell it not to use React?
No, but think about the trajectory. Most people new to building a frontend bare-prompt. There's value for them in using the most supported language, including support from AI systems.
Makes sense to me. I've read that LLMs are more competent in React than other frameworks.
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.
The same is true everywhere in tech, I swear.
"What if we abstracted away X?"
My dude, you're already operating on like five levels of abstractions, and you haven't the slightest clue how any of them work. The answer isn't another abstraction, it's learning how computers actually operate.
I once worked on a VK mini app with one guy. He was building the app itself, I did the backend. He just recently started learning web development, having never done any programming before.
So I'm ready for him to test my backend, I tell him to make a request to https://... and pass this and that parameter. And he just has no clue what I'm talking about. He somehow managed to learn React, a bit of HTML and a bit of CSS without any of the underlying basics. I had to explain him some of HTTP, the URL structure, and what an XMLHttpRequest is.
This was a revelatory experience for me.
Why? I don't care how the chrome engine works. I care about building a great CX and making money
You don't need to understand how the engine works in detail, but in general, it's useful to know which operations are expensive, performance-wise, which are cheap, and what triggers them. For example, you want layout recalculations to only run when they're actually necessary. Or, if you want to move an element around, you should use transform instead of position as transform is "free" because it's a simple matrix multiplication that the GPU does anyway, but position might trigger a re-layout every time you update it.
> I care about building a great CX
I've yet to see a React website that doesn't feel sluggish and overall terrible.
> and making money
Ah that's more like it.
> I've yet to see a React website that doesn't feel sluggish and overall terrible
I doubt it, sounds like confirmation bias.
This is the difference, and why we can never understand each other.
I couldn’t care less how much customers like something; what matters to me is if it’s technically perfect.
This is also why I will never be happy at any job, because it turns out technical perfection doesn’t pay the bills.
I generally agree with you, but if you only care about technical perfection, it can happen that something is "technically perfect", but insufferable to use.
For example, I'm sure many of the common command-line utilities are considered technically perfect by their developers, but outside of some common use cases you've memorized, they are all a pain to use because of how undiscoverable CLI is by its nature. The "wrong input, go read some manuals" style of error messages doesn't help either.
I myself always start from user requirements and work my way down from there.
The last thing we need is “innovation” in the form of MORE JavaScript frameworks.
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/
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?
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.
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".
What about Vue? How popular/good is it, in comparison to React?
It's quite an oversight of the author did not to include Vue. Vue has it all and is as of now in terms of DX, features, ecosystem and performance (with upcoming Vue Vapor mode basically the same as Solid and Vue) the best choice.
For what it's worth, very happy with React and excited to keep the inertia going. "Good enough" in this case is quite good.
Darn, more LLM-generated blog posts?
> The problem isn’t React itself, it’s the React-by-default mindset.
> The loss isn’t just performance, it’s opportunity cost when better-fit alternatives are never evaluated.
> That’s not healthy competition; it’s ecosystem capture by default.
The "It's not <plain old thing>, it's <more complex/controversial characterization of thing for emphasis>" really gives it away.
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.
> The premise is bullshit... there were LOTS of competing options when React first came out...
Good thing that wasn't the premise, then.
The article is specifically looking at reasons for React's success other than its technical merits. It does not deny that it has merits, nor does it deny that its success is partly due to them. It only says that its current success is no longer wholly due to them, and backs the point up with examples of alternatives that are claimed to be technically superior and that are not achieving success commensurate with that superiority.
You can disagree on the superiority claims, you can disagree that innovation in this area is a good thing (many don't!), but I think the main claim is very believable: that in the present day, React's success is heavily helped by its default status.
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?
It exists. It's called a framework.
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?
I think the point is to not have to untangle another developer's middleware in a router from a bunch of state when all you needed was an anchor tag.
The best tech doesn't always win because network effects from wide adoption can be profound.
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.
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.
Yes but it's also a good declarative abstraction and should make the code more portable to other future declarative frameworks.
React is this generation Apache Struts. And it will pass too.
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.
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'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.
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.
> 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.
For me, everything depends on the site and the host.
For 80% of websites, a button is <button>, a router is just URLs that point to files, a state is just a json object in localStorage.
For 15% of websites, a button is <button>, a router is a single file that imports an auth provider and a storage provider which are chosen based on the host.
For the remaining 5% of websites which are actually true applications, I'd reach for a RoR inspired framework (so Laravel for PHP host, Adonis for js host, etc...).
No react needed.
LLMs have more knowledge in React, more than other tools.
> 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.
React gives me headaches.
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.
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.
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.
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.
I remember vividly the chaos before React and what it was like to not know whether it was worth investing in a framework because it might not be around for long. Vue was the first one that I stuck with for a while, but Nuxt was being updated slowly at the time and none of the packages ever seemed quite as seamless as the guys in React land had it. I don't even use more than a handful of unique packages per site generally, I just really need those to work out of the box (tm). It's amazing how many very popular slideshow libraries just.. Break.
I love the idea of a modern & efficient framework that replaces it all, but in terms of hiring, training, maintaining and all of those boring yet vital things it's going to have to be something quite special to make a case for itself. Being able to render 100k table line updates simultaneously instead of 10k or whatever isn't fundamentally going to make the difference for all of those other requirements.
When did I become this person. How depressing. At least there always fun new tech on the backend to play with on weekends.
> Being able to render 100k table line updates simultaneously instead of 10k or whatever isn't fundamentally going to make the difference for all of those other requirements.
React's performance are way more severe and ubiquitous and user impacting.
I'd really love to see the websites you're writing in React and lunch a lighthouse or to simulate how do they perform for somebody on a slightly slower connection or not being on the latest iPhone.
Because I know my users include bank clerks or post office cashiers on 10+ year old computers being used at work as much as people on vacation with very poor signal on the beach.
Of course, if you only experience your website from your MBP on cable you thing the issues are only at "10k rows" level.
We target <3s to usable on lighthouse mobile, ideally less but I don’t design the sites so only so much I can do about large above fold images etc. the truth is react isn’t that bad compared to latency or other issues on the kind of use case you’re describing
I should clarify - this is headless international ecommerce, so that 3s includes localisation, currency, inventory, cart, video, tracking scripts etc. If you'd like 200ms to live on a static site I can do that too, it's just a bit different.
HTTP and JS have to go
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.
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.
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.
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.
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.
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.
Angular was bigger than react until 2018/19-ish in the enterprisey places I worked at.
Definitely feels more geographically based then. I worked at Humana and Comcast, they were both on the react train by late 2015/2016. This was northeast area.
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)