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.
Other frameworks, like Vue and Alpine, let you use them "progressively" and you can even do so with a CDN to avoid having to set up npm/vite from the get go. Their intro docs have instructions for how to do so, along with the relevant caveats
React claims to be progressive, but since it's JSX it requires a compile step. Its intro docs do not have instructions for using it via CDN. You can make it work if you really want to, but it basically requires shipping the compiler to the client along with the JSX and doing the compilation client-side, which obviously scales so poorly that their docs don't cover it.
To recap, my whole point is that React scales very poorly down to simple sites. And since most site are not Facebook or the Spotify web player or Netflix (and even Netflix is moving away from React: https://x.com/NetflixUIE/status/923374215041912833), I think it's very hard to argue that React is effective or well designed.
With the process improvements of 2025, if it doesn't take you an innovation pool of at least 16 petaquacks to display a webpage, are you even trying?
Anyone else up downscaling their innovation?
PHP or blazing fast PHP-fpm, MySQL/MariaDB or Postgres, json for config, jQuery… it is good enough for most cases.
For Netflix, Spotify, Facebook, Waze, and other heavily used sites with millions users… it is a different game.
But instead I am asked to work with tools from the wet nightmares of React developers.
Stuff that runs in Node - yet is designed as if Node, the DOM, or the OS, didn't exist.
Now that's never boring. They can't even consider that everything might work better without their favorite tool, than with it. It's surreal. And awful.
Everytime I see some new editor, I know that people are really innovative because THIS will be THE ONE. /s
I sure love the smell of Wirth’s law in the morning - smells like my PC melting.
Select all angular, leptos, vue, solid and react variants -> react literally is consistently the slowest
Another example is the internet itself. You can have a local LAN of a few computers or a global network of billions. So I'd say that to some degree innovation is measured by how well something can scale both up and down, but of course that's not always the case.
Really really straightforward.
This is such a vanilla setup and was kind of the big selling point to start with from the get-go?
Why do you claim otherwise?
React has always initially rendering components on the server, then hydrated on the client. You don't have to take my word for it, download the initial release and try it out yourself: https://github.com/facebook/react/releases/tag/v0.4.0
Go ahead, run that and write a simple app. Even better, want to do full SSR with no client lifecycle? Write an app that uses "React.renderComponentToString" and then describe what's happening for me.
Even .NET had solutions around using React just for SSR: https://reactjs.net/features/server-side-rendering.html
Claiming that react itself could not just render out a component server-side and spit out the HTML to the client requires several critical misconceptions about how software in general works lol.
Grow up.
React's history starts around 2010 or so, it was integrated into Facebook in 2011 and Instagram 2012 before being open sourced in 2013. And it was that first open source release that added renderComponentToString: long after React had been deployed on some of the world's largest websites.
Also, renderComponentToString isn't SSR. That term usually implies client side hydration so event handlers work, as React is all about state management. But in that release there is no mention of hydration. You could of course do it by hand by rendering to HTML server side, then replacing the entire DOM with a new client side rendered version yourself if you don't mind wiping user's state in some cases, which of course people do! For SSR to work properly took longer.
And that makes sense. Facebook don't use JS on the server side, at least not in that era, their web servers were all PHP/hack. So what would have done the SSR?
It still doesn't solve the problem of scaling down to simple things. I think this is better illustrated with this codepen I made a while ago to implement a reactive button in React, Vue, Alpine, and vanilla JS: https://codepen.io/nbelakovski/pen/jEOVbyP
I tried to implement the React part without JSX, but I couldn't figure out how to render the function component, and while I was able to render a class component based on the old docs, I couldn't figure out how to use useState with it.
But going back to the codepen, the React and the vanillaJS both look messy, but I would take the vanillaJS over React if it means that I can sprinkle a little JS in my code without having to buy the whole farm that is create-react-app + npm + eslint + vite + all the React stuff I've mentioned.
I sense a theme here.
You can view the source on that page to see how simple it can be, but here is the essence:
1. Import React. This is the step you can do from a CDN instead of you want a faster initial page load. (Okay apparently I'm using Preact here, but it's effectively the same thing.)
import { h, render, createContext } from 'https://unpkg.com/preact@latest?module';
import { useState, useMemo } from 'https://unpkg.com/preact@latest/hooks/dist/hooks.module.js?module';
const appDiv = document.getElementById('app');
render(h(App, null), appDiv);
function App() {
let [state, setState] = useState(initial_state);
// --------------->8------
return h('main', null, [
h(Description, {
turn: state.turn,
strait: state.straits[state.shipment.strait]
}),
h(Bankroll, { wealth: state.wealth.first() }),
h(Investment, { invest, state }),
h(WealthHistory, { wealth: state.wealth }),
]);
}
[1]: https://xkqr.org/ship-investor/ship-investor.html
(There is at least one bug in the game logic that prevents this game from being any fun at the moment. I have not taken the time to investigate why that happens, because I have not offered the training that used this tool to anyone in a few years.)
((If you enjoyed the game anyway and want more of a challenge, you might want to try the continuous version: https://xkqr.org/ship-investor/ship-investor-2.html. There is also a secret third version simulating futures which I have never shared with anyone before. It is playable, but not finished: https://xkqr.org/ship-investor/ship-investor-3.html))
Using a CDN is very unlikely to get you a faster initial page load. Initialising an HTTPS connection to a new host is almost always going to take longer than serving that file first-party; there’s even a decent chance of this if your server is on the other side of the world.
React itself buries this information in a reference (https://react.dev/reference/react/createElement#creating-an-...), and the reference doesn't even give a complete example because the example still uses JSX to render the root component.
And I'm not sure if Preact is really a viable alternative to React. If a library I want to use can't work via preact/compat, what then? Do stackoverflow solutions for React problems apply to Preact? I imagine at least some might not. Given these limitations, is there a reason someone would choose Preact over a framework that has its own ecosystem, like Vue for example?
Preact's compatibility layer is good but not perfect - some UI libraries rely on React's internal implementation which breaks with Preact. I think people can and should chose Preact for when they know what third party dependencies they will rely on, and for situations like this where it's a fairly trivial single page app.
I agree completely, my whole career I've been building webapps, as in like software that really couldn't be server side rendered, such as very interactive charting and table applications or games (that didn't require Canvas and could work in DOM but needed lots of reactivity, such as a SQL query builder game or a terminal emulator game), where react works decently. Vue worked fine and so did backbone/marionette, whatever, a framework is a framework is a framework, React has a lot of libraries I can just chuck in to get a date picker or whatever so I use it.
Anyway, I would never build anything that can be server-rendered in react. Simple forms, e-commerce, blogs, portfolios, anything like that I'm just writing in HTML or Django or Hugo or hell, Wordpress. I tried out Astro for a blog just to pick up the framework and didn't understand why on earth I needed all this insane boilerplate to render Markdown files. Hugo solved that problem. If I need more complex than that, Vite + react, done.
I feel like there's a lot of devs out there that are using react cause they like the devx "nice to haves" that they're used to e.g. hooks or whatever, when they really don't need them for their page.
This is a foolish take. React is the reason the modern web is as usable as it is. Anyone who contests otherwise is simply ignorant of web development history.
>(and even Netflix is moving away from React
They're not moving away from React, they're doing pure SSR with it. https://react.dev/reference/react-dom/server/renderToPipeabl...
You don't need the compiler client side. What level of confusion leads you to believe that? That's not even a detail about React, that's simply a mistake in how software works.
React has ALWAYS, by default, done SSR first and then hydrates state on the client. It's trivial, and always has been, to simply do SSR only if you so wish.
>But to implement it in React you have to go on a steep learning curve to learn about JSX, hooks, the component lifecycle, building the app for dev, packaging it for prod, and more.
I find it hard to take this characterization in good faith. If you have trouble learning about the component life cycle in React, I don't see how you have any hope of successfully building a production level application without any guard rails.
You will, without a singular doubt, simply get "it" wrong. Even with modern JS.
Theres at least one foolish take here Come on think of the 100s of comparable FE frameworks…
What are we comparing? What is there to compare?
Or is perfectly aware of web development history and doesn't share your opinion.
It's not a perspective.
function MyForm() {
const [isHidden, setIsHidden] = useState(false)
return (
<>
<button onClick={()=>setIsHidden(!isHidden)}>{isHidden ? ‘Show’ : ‘Hide’}</button>
{!isHidden &&<form>your same stuff</form>}
</>
)
}
At it’s core, React isn’t very complex and you can build a lot of stuff without much complexity.
The problem I often see is developers overengineering stuff. It’s not react specific and you’ll find this issue everywhere, but the form it takes in react land is adding massive solutions to little problems. I’ve worked on apps with giant routing solutions for a handful of routes or complicated stores with almost nothing in them.
I suspect tech influencers and those of us writing actually large apps have an outsized voice if only because those devs keeping simple react projects simple just don’t have that much to write about.
It started simple and sound idea but had its quirkiness with shouldUpdate, didReceive, willUnmount. But that wasn't enough, to write decent applications, you need to do unidirectional flow. You can do that, all you need is actions, action creators and dispatchers! Now you have all this bloat that eventually leads to reflux. While you're tearing your head screaming "What the flux", redux comes along and says hey you know what, if you just write a giant switch statement, you don't need dispatchers. And everybody liked not having to read about dispatchers, so redux was here to say. If it gave more problems you can just create a toolkit around it. Besides, it claimed to be functional. Surely that means it works, right? Now you could rub shoulders with those cool clojure kids who seem to be getting all those high paying jobs. But the cool clojure kids are not impressed. They say, class is something you are, not something you write. So you hang your head in shame and promise to never write classes again. While you're untangling yourself from this mixin mess you got mixed up with, an epiphany hits you. If you can emulate a class using functions, then you don't have to write classes again! And so you finally get around to ridding yourself of classes. Sure it means you have to write more functions, and nested functions and wrap all your functions and shove the state away somewhere you can't see, but it makes everything functional, which means it works. Except for handling exceptions globally, you'll need to use classes for that. And by the way, don't worry about unidirectionality. Everything is asynchronous now.
Look over quick starts of React and Angular, for example. One is a well structured application, the other is a spaghetti script, all held by magic and conventions.
If you recall the (in)famous "PHP: a fractal of bad design", React basically ticks every box in this rant and then some. It's not surprise knowing it's origins, but still.
The reasons React has got traction are the same reasons PHP got traction or web frontend dev in general and have nothing to do with being well designed: it tries to "render" something visible, which makes early adoption much more interactive (hey, I've changed one line and now instead of 15 errors I have 25 different ones and the text moved!), however at the cost of any shot at long term maintainability. Before someone comes and tells me React is just a tool and you can make good products with any tools I encourage you to look at all the headliner star projects by Meta: if they cannot make websites in React at least somewhat functional and stable, no one can. Google headliners built with Angular, for all their warts, are at least for the most part functional.
That's simply because you learn Angular once, and then you learn the half dozen things that can differ between projects, and then you know how it works. For React, every project has its own stack and conventions.
I probably won't disagree that the ceiling for a good React project is higher than that for a good Angular project, simply because you have more freedom to make good decisions. But in the same vein, you also have more freedom to make bad decisions, and most people tend not to be very good at making these kinds of decisions.
React: Where is the code for the <Foo/> component that is used here? Either defined in the same file or imported, like any other javascript thing.
But React is the crazy one.
I've been coding in Angular since 2 and I have never had a duplicate component with the same name. Almost every Angular app uses nearly the same folder structure.
I dare you to walk us through that blog post and explain to us in detail how React "basically ticks every box".
Not only does React not compare to PHP in the slightest, I also find this comparison rather wild because other web frameworks rank so much higher than React on the "quirks & arcane code you need to understand" scale. (I have PTSD from Angular and Vue in particular.)
React has rather matured in dealing with it's own outdated Virtual DOM design, making it much more boiler platy than modern alternatives.
I'm familiar enough with Angular, React, Flutter, Vue, and Svelte as big names in the ecosystem, but have really only done scrappy development with React and not much with the others.
Google trends seems to show React is still a leader [1], and React has more than double the amount of Github stars than any of the others I've mentioned except Flutter, by which it still leads a healthy margin.
- [1] https://trends.google.com/trends/explore?cat=32&date=today%2...
https://2024.stateofjs.com/en-US/libraries/front-end-framewo...
React isn't innovating, it's just improving what it already does, but it doesn't do it in a new way.
That makes it stable, and a safe choice for devs. But yeah indeed like the article says, it kind of stagnates innovation in the ecosystem. But yeah I guess that is because React is usually "good enough" in most cases. Not enough reason to use something else.
LLM coding will lead to stagnation in languages and frameworks as developers start considering how competent their favorite agent is in each domain.
I wonder if you’re better off with something critical mass enough that an LLM can correctly write it at all but not trained on mountains and mountains of slop.
Enough to make it worth it to switch, but not so much that it's hard to switch
> often iteration is better and cheaper
Fortunately React has had major changes over its lifetime that iterating with React was/is the better and cheaper solution.
I do think that React in its history has been able to evolve quite meaningfully, and in a good way (lifecycle methods -> hooks), but in the more recent years, less so.
I think React and JSX and custom components as they are in React with JSX have people "programming" things, that don't need that kind of programming, as they are static things, that do not need the power of a full blown programming language behind them. In a way JSX is even more cumbersome than some PHP, because it makes you learn a new wannabe HTML syntax, which is not HTML (for example classList instead of class) for little benefit on most websites.
The performance is atrocious unless you want to spend most of your time ejecting from the framework to do any realtime work, and building meta-tooling that uses direct DOM manipulation and only occasional state syncing with React, like video keyframes.
This is the approach taken by many projects, including tldraw, framer, everything from poimandres, and many things from tanstack.
The issue is that it's a "demented" framework where everything re-executes all the time and it's up to you to manage repainting and memoization manually. Because a "render" is executing the entire component tree.
The compiler is just a massive band-aid on a fundamentally broken architecture, that every other framework has moved away from.
This feels like a misattribution, due to halo effect.
lmao as if they didn't have to completely re-invent itself from scratch using hooks because it's design and performance were utter garbage. It wasn't until Svelte and SolidJS showed how bad Vue and Svelte were performance-wise for both of them to fix some of their glaring flaws.
> sea of "me too" frameworks
This couldn't be farther from the truth - those frameworks are completely different. Svelte and SolidJS looked at React and Vue and said "this can be done without a virtual DOM", and they did so...and absolutely obliterated them in terms of performance.