React is the worst JS framework except for all the others we've tried.
I'd take React over the Angular 1 days any time. I'd take Angular 1's full-bodied MVC over the "build it yourself from scratch every time" approach of Backbone. I'd take Backbone's minimal MVC structure over the classic JQuery Soup architecture. And I'd take JQuery's dom manipulations and standard-library improvements over the native apis (of that era) in an instant.
React has its tradeoffs, but we got here after a long slog of other things that don't work.
IMHO, React wins because you can just treat templates as variables. You don't need "slots" or other special stuff. It's simply more composable.
The real discussion would be between React's vdom and something like Solid's signals.
Maybe that's just anecdata, but I hated them a lot less. (I am mostly a Backend dev who also does Frontend, so I don't love any of them.)
[0]: and by that I mean my whole team at the appropriate time, it's not simply me misunderstanding things
Before that was XMLHttpRequest (particularly during my .Net WebForm days) and even had to use the ActiveXObject in IE that predated JSON.
Compared to previous paradigms, React lets you compose complexity and rich interactivity really, really well. Even for all its flaws.
These days I use web components for component writing and frameworks to handle routing, state management, bundling, and so on.
Tried React afterwards, this frustration didn't really exist and it was much easier to pick up.
jQuery isn’t a “framework” either, at least not like Angular or Vue, though it can be extended with “plugins.”
Both jQuery and React are foundational technologies, so comparison is valid.
Both jQuery and React are foundational technologies, and comparison is valid.
A lot of people did and do like that idea — I like it too — but it’s woefully inadequate for making rich web apps that a team of average devs can handle.
Plus the ecosystem. It's huge. Nothing comes closer.
It also uses JSX, but since there's no virtual DOM, you can also write 100% JS, but, unlike React, you can do it without any special wrapper. So you don't need to use or write a `react-dnd`, just use any vanilla drag and drop library.
How did the React community convince so many people of this falsehood? Do that many people just not know what javascript is? It baffles me that one could look at JSX and be like, “that right there is vanilla javascript”.
> React has its tradeoffs, but we got here after a long slog of other things that don't work.
I strongly believe it's because of trying to achieve the wrong goal with the wrong tool. So many websites could just be bare html pages and forms with just a sprinkle of JS for some interactivity, but they want to add JS for whatever reason.
If you can have a complete repo browser without JS (cgit), most web applications can survive without it too.
First is the pursuit of polish. Each extra 1% in polish adds tons and tons of lines of code. If you want that level of polish on a non-SPA, you'll still have to add all that code then reload it one page at a time. I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.
Second is bloated do-everything libraries. Ant, MUI, Mantine, or whatever else is aimed to be a superset of all possible website needs which means that the components you adopt have tons of features and bloat you don't need that slow down loading, parsing, and execution. Simply replacing that <Paper> component with a <div> and a few lines of CSS will get you the same thing you want, but will save you layers of unnecessary React components and sometimes a layer or two of unneeded DOM nodes as well that were added because the <Paper> component had weird interactions with some other component.
Third is manpower/experience. Many/most JS devs today (sad to say) don't actually know how to make that simple <Paper> component on their own. Those that do often skip it because they've got too much to do already. I've lost count of the number of teams I've seen where a bog-standard backend has 25 people working on stuff while the frontend team has 3x as many total lines of code (which are often times handling human-computer interaction issues the backend couldn't even imagin), but only 3-4 people to maintain it all.
Fourth is of course management. Designs on the backend change at a trickle while changes to the frontend arrive in a torrent. Understaffed frontend teams can't keep up with all the things shoved on their plate, so they usually can't optimize things even if they know how (eg, only a small percentage of SPA actually know/take the time to lazy load various parts of their apps to improve load time).
Fix these things and the SPA performance will improve drastically and almost certainly exceed BE templates with some jQuery spaghetti.
Exactly.
I did a somewhat longer writeup a while back.
https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
The pull request is still open :-)
It is also somewhat ironic that until late 2010s a common complaint about web development is how fast it changes and how many new things are coming up all the times. It was a very valid complaint, of course. But then when the React monoculture rose to the top, and everyone decides to complain about how that sucks instead. You really can't win.
React wins because it has become a default choice and folks like what’s comfortable to their preferences
I see a lot of personal projects, solo founder applications etc running made in React. I respect your opinion but other people definitely do choose it when they have fully control of what they use.
If I want anything else, I have to implement the integrations myself, search for some open source project that has already done it, or ask AI.
Doable on hobby projects, unthinkable in professional settings.
I wanted to make a back button use browser APIs to go back if the coming from the inbox, just link to the inbox otherwise to preserve scrolling. I had to wire the actions from the html to call the function that goes back, then in my controller determine the previous page and send the JS enabled back button or the hard link. My logic was spread out over 3 files!
With React I can have js in a component determine if the previous page was inbox, and based on that value show the back button JSX or the link. ALL IN ONE FILE. One conceptually entity for me to model vs 3 that do other things and this functionally is hammered in.
Is it slower? Definitely. But it makes me happy. Miserable in a corporate React slopbase? Blame your coworkers, it would definitely be worse without it.
This is why I hate react spas. They're always trying to find some stupid way to break my browsers back button and navigation buttons.
I will always prefer htmx/server rendering with native everything (except the occasional form boosting.)
The problem with just calling history.back() with no fallback is it will bounce users out of your app (back to Google or wherever they came from) and PMs won’t like that…
You hate BAD react SPAs that break the fundamentals of how the web works. Good ones take care to not do that.
React fundamentally doesn't cause this issue either. You can use a different framework than react or even vanilla JS and still produce the same bugs.
I think that lots of more traditional websites have very poor back button designs, especially around editing and form submissions. Remember clicking back and the browser prompting for form resubmission? Very poor design since you have no clue how the server will even handle form submissions. Or getting stuck deep in an application, hard to get back to the root. Or, consider encoding current page data that you’re editing into the URL, and back buttons don’t return to root and just strip query params. Often a very frustrating experience.
Often, “go back to what I was doing before” is what I actually want, not “go strictly to the previous state in the URL bar.”
Sure, plenty of people mess that up too, but the reality is that controlling the navigation stack can help you build more useful designs.
The recommended htmx way would be to hook up an onclick button to inline js or if you dislike that, a function called goBackOrInbox. It can then be something like:
function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }
And if you use that pattern a lot then you can parameterise the function with whatever the route should be.
The problem is that you cannot introspect the browser’s history with the history API. So you have to hack your way around that if you want the “go back in history if possible, otherwise navigate to fallback url” behavior. Which I guess is easier if you’re in a react SPA. Or if you’re fully a MPA and can just check document.referrer
There’s a brand new Navigation API that does let you introspect history entries from the same origin, which perfectly addresses the issue.
I wrote a polyfill in order to take advantage of the navigation API for this exact problem: https://github.com/kcrwfrd/navigation-ponyfill
Even though I'm a fan of React, and use it for practically every web application I build, my biggest and most obvious issue has been that writing UIs through React doesn't feel as natural as, say, writing command line tools in Go, or live/realtime apps in Elixir.
Some languages just feel incredibly natural and frictionless for certain things, and nobody has really nailed UIs yet. Swift, JSX/HTML, Svelte, or whatever framework of the week: they all feel like they're working around the problem to some extent. Like at some point in the process, the designers of the language/framework had to compromise and implement some hacky/weird/painful syntax to satisfy project requirements.
UI's natural interface is visual, so tools like Figma can serve as an essential part of the solution, but nonetheless, I feel there's something missing. There must be a more intuitive way to represent the visual through code. The current solutions, although I find it hard to describe precisely, are always tantalizingly lacking in one way or another.
Emphatically yes. If you look at books written about the problem in the early 90s[1], they are still applicable today.
> The current solutions, although I find it hard to describe precisely, are always tantalizingly lacking in one way or another.
The best analysis of this I have seen so far is in Chatty's Programs = Data + Algorithms + Architecture: consequences for interactive software engineering [2]. It's a bit hard to get through, but absolutely worth it.
As a short summary, the problem is architectural, or more specifically linguistic/architectural mismatch: the architecture our "general purpose" programming languages induces, which is the call/return architectural style, does not match the architecture required for user interfaces, but rather conflicts with that style.
I also wrote about it in Can Programmers Escape the Gentle Tyranny of call/return?.
My current approach is to first build a programming language that can easily express alternative architectural styles: Objective-Smalltalk [4].
With that I am now working an a UI framework I call interscript, including HTMXNative and other goodies.
It seems to be working out...
[1] For example, Languages for developing user interfaces by Myers et al https://api.taylorfrancis.com/content/books/mono/download?id...
[2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
[3] https://2020.programming-conference.org/details/salon-2020-p...
Yet, as the years go by, I find myself accepting a less idealistic answer: Maybe there isn't. Maybe the problem space is just so complex that no one (humanly feasible) general solution exists for all forms of it. If there's one thing that this is true for, UI is probably it.
After I was laid off I realized that what I actually loved about react was JSX components, so I wrote a template engine on top of JSX and started doing server side rendering in my own apps. It's a quiet life
Unfortunately, React's biggest problem is that it forces you into the JS/TS ecosystem, which is, without a doubt in my mind, a compilation target rather than a system I wish to interact with natively.
I'm happy with Elm -- the community is really small, and sometimes you have to roll your own libraries. TEA is sometimes... unnatural (coming from React), but the fact that you do not have to worry about implicit and unexpected state (see useEffect), I always get excited to work with Elm.
Additionally, Claude seems to manage itself better in Elm than in React, at least within large, scary codebases.
>how it scales for apps that may have reusable components or sufficiently complex
It is a lot of boilerplate, but it is mechanical, straightforward changes. I think it is entirely possible to automate it (not even using LLM).
> state..
I have used ELM ports to interact with JS and localstorage/indexeddb.
> How to build a counter component using the HTML Framework in just 1 line of code
> Locate your /node_modules folder and drag it to the trash bin.
> Scott Jehl
> 5th October 2024I like ELM because the core is extremely small. You just have to remember the model, the update function and the message type. That is it.
React on the other hand makes you remember a million conventions and patterns and api like useEffect, useState, hooks.
Ultimately I think React makes it too hard for the performant solution to be used. And then tries to handwave it all away with “the react compiler solves/will solve it”. Don’t even get me started on “useMemo is not semantics” rationalization. First time runs actually matter when working on a performant UI!
DOM ops are expensive but your little bespoke function component code is also expensive when some hook leads to recalcs all over.
I have never found the idea of having a Virtual DOM and diffing in runtime a good solution to the problem, maybe that's why I never liked React. I mean if you are writing a lot of code, have an enormous build step already and use a bloated library, why not have it compiled too anyway. That's why I like the thinking behind Svelte.
It’s hard to explain, but the way everything was encapsulated as a component just clicked for me and suddenly the whole app could be composed.
I think it was when they introduced functional components. And when it comes to hooks, I love them.
Not to say other frameworks didn’t do the same, there was something special about React.
You love JSX, you don't love React
Many of the jobs in my location requires React though, so I have to tolerate it somehow.I have heard a little about ClojureScript here and there. Will take a look at it when I am free!
RSC isn’t React.
> Next.js 15.1+ is unusable outside of Vercel
Next.js isn’t React.
By contrast to nextjs, React + Vite is quite a nice combo. Maybe Bun or Deno are also good? But nextjs and RSC should be kept separate from the discussion.
With React I find there is usually a clear and simple way to achieve what you want, and while it doesn’t perform super well, my customers get more value from a maintainable codebase than a fast one - because I can add features faster.
But it seems becoming. Many React maintainers are on Vercel's payroll and Next.js is also defining where React is going.
But as it turns out it's a great abstraction worth using for the right things (not every part of the web) and one of those are Single Page Applications.
A lot of comments here are about people linking JSX instead of React and that's a good abstraction too. In Mint (https://mint-lang.com/) I'm trying to create a language for SPAs and having HTML syntax helps.
Back then the question we were looking at was whether it would be good idea to move away from SAP UI5. The alternatives back then where React, Angular and Vue.
The conclusion we came to was that it was definitely worth to migrate, but to what was not so easy to agree on.
Right now I am working with a legacy Java codebase that was based on RxJava. And every single day I am cursing the people that made that decision. It seems so obviously a bad idea. And the only thing that lets me keep my sanity is remembering that every decision only becomes obvious with hindsight.
So I guess the only thing I can contribute is that it could always be worse and sometimes making the bold and seemingly innovative decision comes back many years later to bite other people.
I personally like JSX quite a lot. Solid.js is a framework which uses JSX but drops the virtual DOM. Its creator has a course 'Reactivity with SolidJS' on Frontend masters. He's a compiler enthusiast and tells you quite a bit about how much he had to learn from the React project, which, to me, it put into perspective the kind of thinking React brought to frontend. I won't code in React myself, but I surely appreciate its massive influence on everything else.
> A cherry-picked collection of React (and React-tainted) criticism.
I appreciate the honesty up front!1. JS supports JSX literals so
let elDef = <div id="some">Text</div>;
will be compiled into let elDef = ["div", {id:"some"}, ["Text"]];
2. We extend DOM API to accept such constructs: element.append(elDef); // same thing as element.append("<div id=some>Text</div>");
element.prepend(elDef); // ditto
element.patch(elDef); // patch element's DOM by elDef
3. Add appropriate events: componentDidMount, componentWillUnmount, etc. for cases when tag in JSX (uppercased) resolves to a class or function.4. Add render() support. A method that generates tree of elDef's. It gets called by append(),prepend() and patch().
And we will get native React implementation. This will be quite useful and allowed to marry React alike approach with WebComponents into single mechanism.
1...4 is how it is implemented in my Sciter as the Reactor thing, see: https://docs.sciter.com/docs/Reactor/
For me, coding is feeling intuitive as a human being even when I am writing code for the computers (but also for other human beings who'll read and work on my code; not sure how much would that be post-LLM world but still...). React never felt intuitive or, say, natural to me. It "feels" upside down to me, a bit anachronistic (in some way). But as I have seen with many frameworks, or rather "paradigms", which become fashion in the end, "the tools in vogue" because that's what the largest population of coders use, this is what one usually has to use now. I was quite sad when I saw Jetpack Compose as an Android dev. Technically it had improvements over the XMLs no doubt but then seeing it was React was quite not great (at least not for me). But this is what it and one just deals with.
I wish the coding world wasn't obsessed with patterns, architectures, and the need to fit everything into something concretely established (or in vogue). I often see Frankensteins as results.
HTML, CSS and a scripting language inly for progressive enhancement are such beautiful, pure ideas, and learning frontend at the height of the web standards movement made me a partisan of using these technologies as intended. But these days, doing it that way feels like building a house with Japanese joinery techniques.
But now I just use it to get paid cause it's the standard and I know it well. In my experience keeping a large React codebase simple requires some skills that are clearly not universal.
If I have the choice I use Svelte because reactivity is much easier with it and it includes most of what I need to focus on building things.
Currently I'm using hono/jsx, mostly on the server, which seems like an even simpler way to do it than Preact. The JSX looks pretty much the same.
It seems … okay? I feel like I can reason about it. But I worry I’m missing something that’s going to come back and bite us later because we haven’t adopted a framework.
Roast my stack?
If I had to judge it based on this alone post alone:
Great, seems like a straight forward stack. Would happily work on it.
Only criticism, to get all the ergonomics out of alpine, you sometimes have to lax some CSP or use the CSP build. Not necessarily a deal breaker, it is what it is.
Will probably become a hassle when going planet-scale (tm), but I think for most use cases this should be fine.
Later I've a managed state, cause let's agree, it's pretty convenient to have UI updated after a change in the state.
It is gotten weird after Vercel's take over development, with all the "use whatever", which is getting out of hand.
Also the whole functional spaghetti is bonkers.
(Purely based on vibes, I do not have anything robust to back this up.)
It didn't click until I saw a react+graphql project, and it makes sense why meta created react and graphql
It also doesn't help that every single react codebase will always be drastically different from one another. In fact the easiest way to know the date of a react project are the dependencies one chooses in package.json. IDK if that's good or bad, but when you see bootstrap + sass in ${current_year} it's not going to be a good time. Compare this to something like Go where most projects are quite similar. Never had issues jumping in completely new Go repos but react projects are always a massive gamble toward always sucking.
No solutions from me, I charge a premium working on react and there is no shortage of clients with garbage react projects needing help but can't imagine the waste of pure human effort put into maintaining such projects to begin with.
State library is prob all you need now.
Hopefully if the signals standard proposal (TC39) gets up we may not even need state libraries soon.
Now if they could just make Typescript semantics native.
(1) The extreme boom of software engineering as a "get rich quick" career over the past 15 years, and it being the "default" framework for doing stuff on the web. It's so bad, in fact, that most developers these days don't even really understand the difference between a backend and a front-end. I've had to explain, from first principles, how cookies work. All these very important details are simplified or straight up buried by React and its ecosystem.
(2) The overall groupthink of engineers: a lot of us will weirdly become fixated on some framework, operating system, programming language and turn into absolute zealots. This has a long and storied history (Linux vs Windows, C++ vs Java, and so on, so it's nothing new). React just happened to capture a lot of the zeitgeist even though it was objectively the wrong tool to use for like 90% of use cases.
(3) Terrible alternatives. I mostly blame the W3C for this, as JQuery helpers (selectors, AJAX/websockets, etc.) should've been inducted in the DOM standard much earlier and because the W3C (and by extention, the ECMAscript committee) is essentially a beaureaucratic battleground for big tech[1], it's painfully slow to get anything passed, standards are all over the place, and everyone tries to push their own agenda (Google wants to track you, Facebook wants social stuff, Apple wants secure payments via fingerprints, etc.)
(4) The startup boom of the last 15 years or so. This has always been a bit of a problem, but a common trope has been (and still very much is): if it's good enough for "huge tech company," it's good enough for us. So you've had a ton of startups that have been built from the ground up on React and the sunken cost has always been too much to switch.
[1] https://www.theregister.com/software/2018/04/13/go-away-kid-...
But they’ve honestly not worked out.
React works have been a lot better if the React team has figured out what useEffect was supposed to be right at the beginning, or at least when they changed what it was supposed to be used for they documented that clearly instead of gaslighting devs into believing nothing has changed.
Also, hooks aren’t a thing. Each hook is its own API and concept. Grouping them under the umbrella term “hooks” gave the wrong impression that it was a single concept, but there’s No conceptual similarity between ushered, useState or useEffect. The only similarity are the restrictions on their use and nomenclature.
I made sure that all of the interactions in our app that don't require a server round-trip are instant, without any annoying undead skeletons and animations. This works really well because we keep most of the data in RAM on the client, with IndexDB as the backing store and a custom synchronization protocol.
I avoided the "server-side rendering" out of a general distrust of "magic" solutions that do everything for you.
React itself is also really straightforward as a mental model of rendering.
AI writes React well too
Then they took it to the next level with things like styled-component. Virtual DOM is just an implementation detail and overrated to the success of React.
Any future web framework that solves that component thing and allow people to just write code instead of "web code", they'll win.
(I am aware that the web veterans don't like that view)
Here is a fun thing.
Write a bunch of JSON. A lot. Now write a lot of JSX. Then convert the JSON to JSX. Then convert the JSX to JSON. I was surprised by how much easier it was for me to reason in JSX. I use threejs and react three fiber (r3f). Again the JSX type of representation easily wins out for me. I don't really understand why. Maybe JSX ends up being more pictorial - as in a picture is worth a thousand words?
So I'm not sure I even care of about React. I just reason better with JSX than with all the other crufty things (template, html, htmx, etc). And yes, find all of them including React crufty.
One of the things that was clunky in the React version was the use of setInterval. I had to write a hook in React and it just added this unnecessary layer of weirdness in how it all interacts[1]. In the Lit version, I just use setInterval normally and there's nothing extra to understand.
[1] https://overreacted.io/making-setinterval-declarative-with-r...
But the thing is, React and others is useful only for a few specific cases, IMO. I would only feel the need for them if we're building truly interactive applications (Open Street Map, figma, a text editor,...), but only because they've taken care of the state management boilerplate (even if you're now boxed by their applications. But most apps on the web don't needs to be an SPA. They can actually be improved by being a multi page application with small islands of interactivity.
Then Svelte 5 came along and made Svelte more like React. At first, there were just a few simple runes, but then the runes started proliferating like crazy to solve other runes' problems. At that point, Svelte was dead to me and I went back to React/Next.
The right path for Svelte to take would have been to continue to refine Svelte 4.
I don't want to be a "you should've double bagged it" guy, I'm just curious. Svelte is not the be all and all, if you moved on to greener pastures more power to you.
Server components, state management libraries, data fetching libraries, routers, etc, are horrible. Same with most UI libraries. They add so much overhead and complexity.
But React is really, really good at the thing it was designed for: building interactive UIs. You can even build native apps. Can you build a native app in htmx?
Most of the alternatives to React are simplifying alternatives. They aim to take complexity away in order to solve a subset of basic use cases with less ceremony. Sure, if you have uncomplicated needs then use whatever solves your problem, web components, HTMX, Jinja, plain HTML, markdown: go as low as you like down the hierarchy and choose the simplest thing that could possibly work.
But nobody as of yet has built an alternative to React that can solve the difficult use cases better than React. Au contraire, React has moved into domains that it was never even designed for. Native apps. Terminal apps. That's the power of a good abstraction.