Does anybody like React?

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.

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.

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.

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.

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.

I've found it to be a great improvement over many cases where I would have used React before.

Svelte feels much easier to learn for someone who already knows the basics of web development, HTML, CSS, and JavaScript. But nowadays I often see people start learning web development by learning React, which feels a bit backwards.

Personally I have been using SvelteKit + Capacitor to build mobile apps, wrote about the setup here: https://bryanhogan.com/blog/web-to-app-sveltekit-capacitor

For simple landing pages I like to use Astro though.

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

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

    You love JSX, you don't love React

My favourite front-end architecture is MPA actually mostly server-rendered, with Vue only on the pages that need high interactivity, and vanilla JS on the others.

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.

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.

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.

Granted none of these critics have a viable tried and true alternative. It’s easy to throw shade at any abstraction. None will ever be perfect!

That said, I welcome any new paradigms and ideas. But discounting how far we’ve come with what’s possible on the frontend with hand waves just doesn’t cut it for me.

1. Over-reliance on complex concepts and terminology. Let's compare with Vue: `useEffect` vs `watch`, `useMemo` vs `computed`.

2. This useless "clever" stuff also slips beyond terminology: many years ago, Redux was considered the go-to state manager, and it required writing a lot of code across multiple files even for incrementing a number, because its author liked a lot of clever CS concepts. VueX at the same time allowed just to increment that number. Thankfully, nowadays, the React ecosystem is full of sane state managers.

3. React ships without any tools to work with CSS. That said there is no chance you would use React without CSS.

4. React doesn't bother optimizing anything for you. You need to know how and when to properly use or not use these clever `useEffect` and `useMemo`. There is a lot of stuff to know, and there are a lot of folk legends about optimizing React. This is while rerendering is its main purpose. In Vue, the framework makes you always use its tools, and does most of the optimizations inside them. I never thought about manually optimizing a Vue app.

5. The folk legends. React API and the "correct way" to write React radically changed so many times, so it is very hard to understand what is still true today and what is not.

All of that can be summarized into one – React is overly focused on ideas, computer science, and being high-level. And not very focused on actually making drawing interactive HTML on screen simple.

I do write a lot of React, Vue, and Svelte. And when I write React I always need to think about stuff, of which I never would think about with Vue and Svelte, because they already took care about it. And performance wise they are on par.

btw, I wrote a related post some time ago https://www.brachkow.com/notes/what-i-like-in-vue/

1. JS supports JSX literals so

   let elDef = <div id="some">Text</div>;

   let elDef = ["div", {id:"some"}, ["Text"]];

   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

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/

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.

My problems with React are more about JS/TS and how other devs (it's never me! I swear!) can write terrible code that passes tests and isn't readable or maintainable. The JS Tradeoff is that we can handle rapidly evolving web landscape, but we have to deal with NPM and supply-chain hacks periodically. shrug

I am fine with the complexities of events, hooks and re-renders in React because we want to build interactive programs and nothing comes for free. Data fetching libraries like Tanstack Query solve one of the hardest problems of cache invalidation/re-rendering.

React was the thing that made me actually enjoy making interfaces for users. I just want to build stuff.

I experiment a bit with HTMX for my super simple single-page tools with some basic javascript, Next.js is nice but kind of thirsty to get you to use Vercel, I like Flask-Admin for really simple tools that must render a page from a server-hosted application.

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 having built websites and apps since before jQuery times, I strongly disagree with manual DOM manipulation as an alternative. Declarative, component-based approach won for a reason. These frameworks allow you to tell how the UI should look based on the state and manages the transition (either via virtual DOM diffing or fine-grained reactivity) for you. DOM manipulation requires you to write some code for every single state transition (instead of every _state_). And, in practice, it becomes unmanageable very fast, and you give up, and start writing code like `element.innerHTML = ...`, causing problems with focus and event management. It's fine for small widgets, even enjoyable, but only until you need to manage a complex UI. Then, you end up with a mess of code that is hard to maintain and debug.

I know some still feel web is not the right platform for building complex UIs but that battle was lost more than two decades ago. Web is good. It comes with accessibility features (like zooming) and works everywhere. As someone with age-related farsightedness, I hate native apps that don't allow me to zoom in with a passion (which is, almost all of them). Of course I hate websites that don't allow me to zoom even more because they had to go out of their way to disable a basic browser feature. But getting decent accessibility is harder with native apps. You basically have to build everything yourself. Web gets you 90% there for free.

React might not be the best out there and might be, one day, replaced by one of the competitors or something new. But declarative, component-based UI development is not going anywhere.

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.

Like many, I came from pre-SPA days -> AngularJs -> Angular 2 -> Modern Angular. I tried react a few times, plus React Native but found it hard. I wasn't good with a slightly different render-syntax (whereas Angular uses HTML) and every project I was on was wildly different from each other.

Modern Angular has been wonderful. A lot of the pain points people have are gone, some good parts of other frameworks (signals, single-components vs modules, etc) have been incorporated and embraced.

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.

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

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.

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.

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.

I have no idea why people go for these super heavy frameworks. Maybe there are some aspects I am not considering that justifies React.

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.

Later I've a managed state, cause let's agree, it's pretty convenient to have UI updated after a change in the state.

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

I think we should return back to that with the era of LLMs. We don't write the code anyway. Let's use reducers and fully event sourced states.

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?

2. if one is too much then use Svelte to make 1. Svelte works perfectly okay with other JS libraries without needing wrappers.

3. use Vue if things get political(i.e we need devs) if you need to play around but u can also use Vue to make 1.

1000xxx. if you tokens to burn & VC money to burn the use React - since your decisions are influenced by politics of the day and not pleasing your users.

(Purely based on vibes, I do not have anything robust to back this up.)

    > A cherry-picked collection of React (and React-tainted) criticism.

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.

But React has the largest ecosystem

It didn't click until I saw a react+graphql project, and it makes sense why meta created react and graphql

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.

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

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.

I've helped juniors learn React as part of their studies and when they then come to intern with me they become happier once they learn other ways of making things happen on the screen.

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)

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.

I also hate React for many reasons, but I mostly like it because I genuinely believe React is the only front-end system I've used that got the fundamentals correct - they've just gotten many other trivial-but-still-annoying things wrong.

The fundamentals:

- no magic: this is a trend that the JS community has picked up I think from Ruby or maybe just Rails, but having a framework pick things up automatically depending on how you've placed them (directory structure, DSL files without explicit exports, etc.) means you need to learn each framework's magic independently & upgrade paths are harder when magic changes. React is just javascript - components are stored in variables, your app container is a native dom primitive & you need to call the render explicitly. This makes your entry points clear & idiomatic, & ensures your framework stands the test of time.

- composable (& somewhat fungible) primitives: React components are JS objects, there's certainly some elements of the underlying lifecycle implementation that's abstracted away once they're passed to the rendered, but at definition time they're just objects - they can be passed around, inspected, manipulated & ultimately they're not abstracted away & hidden from the dev.

- modular DSL: I'm suspicious of DSLs in general but if you're going to create a DSL, JSX is a masterclass in how to do it. 100% independent of React - you can use JSX without React or React without JSX. This modularity has lead to JSX getting broad high-quality third-party tooling support that all other front-end frameworks lack.

- imperative DSL. This is a bonus but the design of JSX is ingenious. Declarative systems are the dominant trend: everyone wants to create a well-defined strictly static language to define their front-end, but that design goal doesn't match reality. JSX isn't declarative: it's an extension of javascript, tags are function calls, attributes are params. This makes it incredibly expressive - I could write my backend in JSX if I wanted to (could be a fun experiment).

The bad:

- class-based components. This is less of a React problem & more of an ECMA problem but shoehorning Java-style classical inheritance models into javascript was always a bad idea & React was the main proponent of this style when it was popular. Thankfully we've moved past this phase & modern React no longer does this.

- lifecycle methods: these were tied to class components so were always going to end up becoming deprecated when classes went away but they also had other annoying fundamental issues - too complex to go into in detail here but their operation was highly abstracted which made debugging really painful

- hooks: the modern replacement for much of the lifecycle method functionally isn't much better. Thankfully hooks are mainly used for state management, which has always been an "added extra" in the React world (see e.g. flux), so you can minimise your hook usage & avoid a lot of friction if you're clever & careful.

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.