React, Electron, and LLMs have a common purpose: the labour arbitrage theory of dev tool popularity
React is, for the vast, vast majority of organisations making web-facing software, objectively worse than many of the alternatives.
A cherry-picked collection of React criticism.
React is, for the vast, vast majority of organisations making web-facing software, objectively worse than many of the alternatives.
I’ve seen all those headlines about Svelte being the “most loved” framework, and… well I admit, I just ignored it as noise. But the next time that survey comes around, I’ll be right up there with them, waving from the Svelte bandwagon.
I talk about an apparent attitude shift in attitude towards React in the community and also make some recommendations about decision-making for your projects.
Personally, I would love it if more people were complaining about the dreadful user experience inflicted by client-side React. Instead the complaints are universally about the developer experience.
By ejecting from the thrash of React and other heavy-handed frameworks and doubling down on web fundamentals, you’ll be future-proofing both your career and your codebases.
Why the heck is everyone reaching for React as soon as something on the screen needs to update? And why do we insist on squishing our frontend concerns together with our backend concerns?
However, today I see two problems that make me enjoy React a little less and make me worry that new developers might be intimidated by it: ownership and complexity.
After a false start with React in 2023, we’re now on a tech stack that we’re not fighting against and that maps better to our customers’ domain.
[...] I still reach for React when I want to build something somewhat complex, I just… wish I were happier about it when I do.
It has been one and a half years since the last React release, far longer than any previous release took.
At the same time, React has done nothing (besides an abandoned experiment in 2019) to improve their pitiful client-side story. It is a legacy framework created to solve Facebook-scale problems with Facebook-scale resources, and as such is a bad fit for most use cases.
Performance challenges with a React SPA created an opportunity to explore Liveview. After two days of exploration, we were convinced Liveview provided a path forward, and within a few weeks, we replaced our React SPA with Liveview.
You should stop using React. In fact, you probably should have never used React in any of the projects you used it on. But before you pull out your sawed-off shotgun and shoot me, hear me out.
Hooks in React are tricky to use correctly and even harder to use in a performant way. This has left many applications with poor code quality and bad performance, but that doesn’t have to be the case anymore.
Making the case that you should not use React Server Components if you want to ship applications quickly. If you want to learn, experiment, or make content, by all means!
Feels like React is playing his own game by his own rules.
How do we improve JavaScript usage, teach progressive enhancement and reconcile the community?
There have been a number of criticisms levied at the React project over the years, some of them handled and some of them still wavering in the wind.