Does anybody like React? (opens in new tab)

As someone who lived through all major waves of JS for the last ~16 years, I do love react, in a sense:

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.

After spending so long writing React code, I'm now working on a large Vue project at work. Everyone used to say Vue was the easier of the two, the more approachable option — but I'm starting to see it differently. React, in its elegance, gives you components that are essentially just functions — and beyond that, there's not much more to it (setting aside the whole Next.js ecosystem). It's the most elegant thing I've encountered in frontend development. Vue, on the other hand, feels like a jumble. You can tell it was clearly adopted and glorified by backend developers who didn't want to properly learn JavaScript — and what emerged is this awkward mashup that never quite coheres into something clean.

Of course people do. No one is forced to use React or any other web framework unlike how they are practically forced to use JavaScript, and yet React wins. This should be enough evidence that people like it enough, at least more than most other frameworks out there.

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 like React. And I have seriously tried the HTMX/Hotwire camp.

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.

More than React, I'm interested in the question of how to best write UI through code, in general.

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.

It was an improvement in some regards, but a pita most of the time. Before I had to work on an Angular project React was my least favorite frontend library. Solid.js gave me back my sanity (also Svelte 5). Fast, small, includes what I need and feels like just writing JS/TS. Sadly businesses love to torture their developers, themselves and users too much, so React/Angular it is.

Yes! It is hands-down, the most intuitive interface, that has successfully married declarative and imperative styles together. IMO, nothing comes close to JSX across the length and breadth of UI frameworks across all languages.

I used to absolutely love react. Then I spent two years breaking apart a monolithic SPA into a bunch of federated micro frontends, and I saw the darkside of where React monoculture can go. When your entire website runs in the framework, complexity goes through the roof.

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

I'm biased because I was part of the people that made it happen but yeah, I love React. Before that, I would try everything under the sun to fix the issues I was having doing front-end. But since React came out, I don't have this need anymore. I can just focus on building stuff.

One of the talks I really enjoyed is https://www.youtube.com/watch?v=h9SDuTSy7ps. In my experience, React's architecture is really good and lends itself quite well to making large applications.

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.

A post about React?! Nature is healing

This is my favourite quote (and I write this as someone with no experience with HTML frameworks):

    > 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

ELM forever!

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.

React is great honestly. It's a simple mental model. Hooks are fun and compose well. JSX makes sense: Astro is a great example of how something that is certainly not react still has react-like syntax and is immediately accessible to anyone with react experience.

I use Angular 2+, and I find it quite pleasant to use. I also like how they make the framework evolve. Not scared to have opinions (back when it came out, Typescript was barely a thing). Never got into React (but didn't try that hard to get into it), but it seems like it's a huge bloated mess.

I kinda like react with hooks but I do miss Angular 1 watches. Explicit watch expressions solve a loooot of spurious rerendering nonsense that makes for a lot of churn

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.

There is many "like react" things out there. I avoid full fledged frameworks like the pest, but something like solid.js is probably the one that matches how i think of webdev.

I think so, because it's created in Meta, thus having a huge developer base already and spread its way out of there. If you earn your life writing it, because your employer forces you to do so and you never try other stuff that long, you end up liking it.

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.

React was one of those ways of building software that gave me back the giddy excitement I had learning Visual Basic as a kid.

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.

I read one post before that really resonates with me, couldn't recall from where though:

    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.

> Critical Security Vulnerability in React Server Components

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.

Initially I didn't see the value in React. I thought that the whole virtual DOM compiling on every change was a waste of resources instead of just doing the change itself directly.

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.

"Does Anybody Actually Like ____" is such HN engagement bait

I like react if I'm the one writing all the code. But it's too easy to write something an order of magnitude more complex than it needs to be if you don't know what you're doing. And just easy enough to maintain that complexity that you never realise you're doing something wrong.

I haven't really deeply thought about frontend JS for many years.

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 like the React model of components being (ideally) a function of state, but I don't touch hooks where possible. And I don't use React itself when I can use the lighter Preact library instead, which provides signals as an escape hatch.

What would people answer if they'd be asked if they actually like Unix? Nobody programs in literal Unix, but there's a clear before and after Unix. In the same way, there's a schism between before and after React.

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.

I love it. Easy to write and understand

Hat tip to the article's subtitle:

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

I appreciate the honesty up front!

I like SvelteKit but frameworks are converging to have similar features. React has a compiler. Vue is doing away with VDOM and Svelte has 'Runes' which is a bit like Solid's signals.

What if:

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/

I am assuming the idea is to talk about "react" pattern/idea as well, not just that JS framework, and no, I didn't read the article - after two quotes, I scrolled and realised there was no article to read.

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.

It's called Stockholm syndrome...

React seemed like a bad idea when it came out, and a much worse idea once I started using it day to day. All of my personal projects use Svelte, and I finally, blessedly applied for a job recently where Svelte was their frontend framework of choice. htmx also felt great the one time I used it.

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.

Everyone I know seemed to pretend to like React because it was an avenue for making money. In other words, it was popular, but not on its merits. Next.js was the same.

I did love React for freeing me from AngularJS and I fully bought in its idiosyncrasies.

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.

I like JSX and I prefer Preact to React because it's smaller, but I haven't used React itself enough to know if I'm missing anything.

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.

I’m not an FE engineer but have found myself working very closely with the whole stack recently, which includes an SPA. We use html, JavaScript, Alpine for reactivity and Supabase realtime subscriptions.

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?

I will never change express, ejs and postgresql for my solo projects, even AI likes to deliver in express and ejs with less clutter, easy to read, easy to make cosmetic changes when needed. I've always lived by simplicity and so does AI.

I like it just fine; so long as I am being paid to code with it. Would I use react otherwise? No. But then, I view all js work as strictly mercenary. I would never choose it willingly no matter what library sits on top of it.

Shout-out to the React Compiler for those that have not tried it. It's very easy to configure and can automatically deal with many cases of useMemo / useCallback / memo to reduce boilerplate in code: https://react.dev/learn/react-compiler

I never liked React, but after working with it for several years, I got use to it. Specially JSX. Pretty neat to mix html and js in the same code. That actually inspired me to write tinyJS - https://github.com/victorqribeiro/tinyjs

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

No, it is forced upon me when SaaS vendors only support Next.js/React as official way to extend their product.

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 used React back when it came out once or twice and knew, nah thats not it. It may be good for apps like Facebook. But on the other side, Facebook was slow and buggy af.

It depends on application complexity. I will hit a threshold. Below: HTML + CSS + targeted JS. Above: React + npm + webpack + typescript.

It is the standard, and is extremely flexible. It was probably the wrong framework for most use-cases, which are often just CRUD screens. But, we are in an AI world now, so probably Javascript in general and even Typescript is starting to become the wrong move. Programming languages and frameworks which offer a ton of guarantees is what you need, now. In my humble opinion.

React is probably the most successful framework people constantly complain about.

It's interesting how all of the LLM tools seemed to default to React in 2024-2025, but this year I'm finding them much more likely to default to vanilla JS and HTML instead.

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

I do like React. It's still my choice even after trying other tools (including HTMX).

Yes, and I won't be convinced otherwise until there is an objectively better solution.

React removed the joy of web development from me. Datastar brought it back.

Some people do, some people don't.

React really shines once you embrace graphql and have components pass graphql fragments upward so that components can easily query for the data it needs, and the backend only gets one query per view. React is really annoying if you're doing REST.

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

I see no point in React at all. Modern JS with HTML components is all I need. I use my own state management component (basically implementation of state machine with async reentrant publish subscribe). JS dynamically loads strictly on on-need basis so no need to suck all code on initial load. In the end my front-ends are tiny, no need for build / deploy / source map and all other BS steps) and super easy to debug.

I like React using by using Re-frame. It's a clever loophole to use Lisp while meeting requirements, making everyone happy.

Been using React before class components was a thing, it had its place in the sun but I truly believe react has now done more harm in holding the frontend community back than helping it.

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.

Its bloat. You can do shadow dom and web components in modern native JS.

State library is prob all you need now.

I’ve been lucky enough to avoid it. I’ve banned it at work as it is not the correct as preach for any of our work.

I always get downvoted when I say this, but React is imo the biggest piece of astroturfed garbage corpo-slopware in the history of software engineering. It achieved such ubiquitous status for a few reasons:

(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 loved react in 2013 when it had the life cycle methods. Everything was deterministic, I knew what caused what where and when. Now every framework is a mess and I'm glad I won't have to learn anyone's crap anymore thanks to random code generators.

I like React.

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.

I don't like it. I prefer Svelte and VUE.

I do. Reading React is an uniform experience across all the codebases. You know what state is, what an effect is, what a rendering function is and what it looks like. You also know where code smells are, there's a whole section of eslint rules dedicated to that. Compare to hand-rolled frameworks, where everything is all over the place, and you have to navigate tons of indirection to understand the brilliant intuition du jour by some developer who was bored and wanted to inject a spark of creativity in their code. Give me predictability, and keep creativity for hobby stuff that nobody has to read.

No more or less than I do the rest of the js ecosystem.

Gets the job gone so I can focus on more important things

AI writes React well too

I think mostly people like to have logical component with all the code in one place and not have to think about structuring css/html/js separately. Many people like react for jsx (surprisingly, because initially there was a lot of push back even in early react adoption).

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)

I'm not sure it is React I like. I like JSX.

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.

React is great, and really the only good thing Meta has ever done.

No

No, I prefer much lighter frameworks that are closer to web standards, such as LitElement, which is a relatively light wrapper around Web Component standards. yes, they are slightly clunky, but they work great without a build step. I just edit the code and reload the page, no need to worry about a 5MB bundle. Unless you are writing code that is deployed to a million users running on Nokia brick phone browsers, it works great.

I like it, but only in its truest sense: A view library. Various parts of the ecosystem are horrible even if they don't pertain to react. I like jotai because its elegant as a global state library (React context has too much boilerplate).

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 much prefer svelte but the rest of the world does not

React was incredible right until the end of the class based react components. It all became fucky really quickly past that point. These days I feel React is a tool that is foisted upon me, not one I choose on technical merits.

React is fine. The shit people add to it (including the React team!) sucks tho. Raw react is just declarative UI.

Server components, state management libraries, data fetching libraries, routers, etc, are horrible. Same with most UI libraries. They add so much overhead and complexity.

I'm really sorry to say this, but I actually love React

People hate on React because it's popular. That popularity alienates people whose use cases aren't served well by React and they wonder what the fuss is about.

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.