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.
But why over vue? My biggest frustration has been how vue ends up moving in the direction of react. The original component architecture with the html template, JavaScript state and css styles in vue was so nice. Even the data fetching a url in the component was so intuitive.
Vue doesn't solve problems better than React (and solves them worse if you have to learn all their proprietary files and DSLs instead of JSX), so there's not much of a reason to switch.
The real discussion would be between React's vdom and something like Solid's signals.
That’s right — the outcome is path-dependent. If we knew then what we know now, surely we’d have gotten over the idea that the web is DOM-documents-plus-REST-plus-JS-handlers-everywhere.
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.
"React is actually a library, not a framework" is definitely a thing people have said here and there since its inception. It's a distinction that doesn't seem to buy anything in terms of explanatory power or clarity, so I tend to ignore it.
I think it's a shortcut for saying that react doesn't have an 'official' routing library (like vue-router) and state management library (like vue's pinia). So depending on what you choose to manage routing / state, one react app can be quite different from another.
Maybe nowadays there is a set of popular libraries for react so it becomes framework-y?
Generally the difference between a library and a framework is that you can use bits and pieces of a library to add functionality to your project.
A framework expects most of your project to be shoehorned into it.
Whether something is one or the other depends on which of the two most users are doing. It's not a very interesting argument, though, because debating semantics is the worst use of the limited time you have on this planet.
> React is the worst JS framework except for all the others we've tried.
> 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.
SPAs are a monster that grew and grew; an idea that at first seemed like a clever optimization has generated huge and complex systems that are a nightmare to work with, and are bloated, slow and insecure.
Web components are the next big idea. I hope they have a chance to work.
I hate spas everywhere too but if you needed to build one for valid reasons React is probably a good bet due to large ecosystem and adoption. I personally avoided React as much as I could and luckily I won’t have to have to work with it.
I was a big Sevelte fan. After writing a sizeable application in Sevelte I realized that React is superior in every way overall speaking and at least you're writing 100% pure JavaScript directly. Or Typescript.
Plus the ecosystem. It's huge. Nothing comes closer.
You might be interested in solid.js. To me, it's easier to work with than React. What I like about it is that the reactivity model is small enough that you can understand it, and even implement a basic version yourself.
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.
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.
> 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.
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.)
This has been a non issue when using proper routing libraries that push history entries on the stack properly and render routes from the top of the component tree down.
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.
> You hate BAD react SPAs that break the fundamentals of how the web works.
But that’s all of them? If Github, Reddit, LinkedIn and Facebook and others are unable to build SPAs that don’t constantly break the fundamentals while also choking the browser, maybe it is a tech problem.
It’s not that. The sort of issues all of the above have caused are fundamental, eg not using anchor tags for navigation. It’s not in any way easier to use a button or div with an onclick handler. It’s also not easier to serve megabytes of JS to render 5kb of comments.
Sure, but the internet is majority bad SPAs vs good ones. Rarely am I delighted by a SPA, but suffer through how poorly it works in bad network conditions, usable back buttons, or otherwise respecting the user.
My advice would be to only use HTMX for data state related operations. For something like an intelligent back button, unless it depends on resource state do not use the backend to calculate it.
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.
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.
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.
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.
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
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.
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 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.
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’m the opposite. I loved React (before its hook madness) but I hated JSX. I’ve been using a lispy language to write React since it first came out. Initially went with someone’s pet project and eventually switched to ClojureScript. If you are already tolerating a build tool to transform your code into a form browsers can run, why not switch to a better language that’s designed for nested tree structures?
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.
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.
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 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.
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 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.
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.
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 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.
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.
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 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.
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.
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.
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.
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.
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.
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 have an Astro site that's mostly static with a couple interactive components. I recently converted the components from React to Lit and the result is so much simpler.
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.
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 was all in on Svelte and SvelteKit until I started encountering CSS weirdness caused by a bug that the Svelte developers said is "by design", namely that components' CSS isn't removed from the document after the last instance of that component is no longer rendered. This resulted in a situation in which styles became dependent on the navigation path the user takes, leading to weird an unpredictable layout issues. I couldn't stomach solving this by using Tailwind.
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.
Interesting, so if I'm understanding correctly, component A's style was supposed to change when component B was present, and this was implemented as styling rules in component B? Why was Tailwind necessary rather than moving these rules to component A (which I know would probably require some gnarly selectors)?
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.
I've never been a front-end developer in my entire career until 2026 working on a mature (but new to me) project with react in it: This shit is spaghetti.
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.
But why over vue? My biggest frustration has been how vue ends up moving in the direction of react. The original component architecture with the html template, JavaScript state and css styles in vue was so nice. Even the data fetching a url in the component was so intuitive.
Vue doesn't solve problems better than React (and solves them worse if you have to learn all their proprietary files and DSLs instead of JSX), so there's not much of a reason to switch.
The real discussion would be between React's vdom and something like Solid's signals.
I'm using Vue and do not feel it's becoming react
I like react over angular and vue over react.
same here thus I'm with vue
That’s right — the outcome is path-dependent. If we knew then what we know now, surely we’d have gotten over the idea that the web is DOM-documents-plus-REST-plus-JS-handlers-everywhere.
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.
What about Angular 2+?
Angular 2+ is equally horrible. Having spent 6 years on various versions of Angular, their migration story time and again has been an incredible pain.
These days I use web components for component writing and frameworks to handle routing, state management, bundling, and so on.
Chesterton’s framework.
Wait, react is a framework now? People used to say that react is just a model binding library. FYI I haven't used react.
"React is actually a library, not a framework" is definitely a thing people have said here and there since its inception. It's a distinction that doesn't seem to buy anything in terms of explanatory power or clarity, so I tend to ignore it.
I think it's a shortcut for saying that react doesn't have an 'official' routing library (like vue-router) and state management library (like vue's pinia). So depending on what you choose to manage routing / state, one react app can be quite different from another.
Maybe nowadays there is a set of popular libraries for react so it becomes framework-y?
Generally the difference between a library and a framework is that you can use bits and pieces of a library to add functionality to your project.
A framework expects most of your project to be shoehorned into it.
Whether something is one or the other depends on which of the two most users are doing. It's not a very interesting argument, though, because debating semantics is the worst use of the limited time you have on this planet.
> React is the worst JS framework except for all the others we've tried.
> 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.
Sounds like your argument is with SPAs, not React in particular?
SPAs are a monster that grew and grew; an idea that at first seemed like a clever optimization has generated huge and complex systems that are a nightmare to work with, and are bloated, slow and insecure.
Web components are the next big idea. I hope they have a chance to work.
I hate spas everywhere too but if you needed to build one for valid reasons React is probably a good bet due to large ecosystem and adoption. I personally avoided React as much as I could and luckily I won’t have to have to work with it.
I was a big Sevelte fan. After writing a sizeable application in Sevelte I realized that React is superior in every way overall speaking and at least you're writing 100% pure JavaScript directly. Or Typescript.
Plus the ecosystem. It's huge. Nothing comes closer.
You might be interested in solid.js. To me, it's easier to work with than React. What I like about it is that the reactivity model is small enough that you can understand it, and even implement a basic version yourself.
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.
Could you expand on your experience compared to react?
>Sevelte
FYI: https://www.merriam-webster.com/dictionary/svelte
I never wanna use anything but Svelte ever again, honestly.
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.
> 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.
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.)
This has been a non issue when using proper routing libraries that push history entries on the stack properly and render routes from the top of the component tree down.
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.
> You hate BAD react SPAs that break the fundamentals of how the web works.
But that’s all of them? If Github, Reddit, LinkedIn and Facebook and others are unable to build SPAs that don’t constantly break the fundamentals while also choking the browser, maybe it is a tech problem.
If the APIs are too hard to use properly that no site can use it right, then it's a browser issue.
It’s not that. The sort of issues all of the above have caused are fundamental, eg not using anchor tags for navigation. It’s not in any way easier to use a button or div with an onclick handler. It’s also not easier to serve megabytes of JS to render 5kb of comments.
Sure, but the internet is majority bad SPAs vs good ones. Rarely am I delighted by a SPA, but suffer through how poorly it works in bad network conditions, usable back buttons, or otherwise respecting the user.
My advice would be to only use HTMX for data state related operations. For something like an intelligent back button, unless it depends on resource state do not use the backend to calculate it.
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.
I know there will probably be some complications here and there, but this could be done with Web Components too, right?
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.
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 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.
What if:
1. JS supports JSX literals so
will be compiled into 2. We extend DOM API to accept such constructs: 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/
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
"Does Anybody Actually Like ____" is such HN engagement bait
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.
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 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.
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 read one post before that really resonates with me, couldn't recall from where though:
Many of the jobs in my location requires React though, so I have to tolerate it somehow.I’m the opposite. I loved React (before its hook madness) but I hated JSX. I’ve been using a lispy language to write React since it first came out. Initially went with someone’s pet project and eventually switched to ClojureScript. If you are already tolerating a build tool to transform your code into a form browsers can run, why not switch to a better language that’s designed for nested tree structures?
Interesting to know. Personally I've also been trying out other library/frameworks, like Vue, AlpineJS, or just plain server side rendering.
I have heard a little about ClojureScript here and there. Will take a look at it when I am free!
I love it. Easy to write and understand
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.
Exactly what I want to say. Thank you.
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.
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 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.
It depends on application complexity. I will hit a threshold. Below: HTML + CSS + targeted JS. Above: React + npm + webpack + typescript.
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 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.
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.
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.)
It seems that LLM tools should make these frameworks unnecessary.
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-...
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.
Both Scala, Ocaml and some variant of Ocaml like PureScript target Javascript and even have library that wraps React. Worth to explore with AI.
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.
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.
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.
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.
I like React using by using Re-frame. It's a clever loophole to use Lisp while meeting requirements, making everyone happy.
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.
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 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.
Gets the job gone so I can focus on more important things
AI writes React well too
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.
No more or less than I do the rest of the js ecosystem.
I'm really sorry to say this, but I actually love React
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.
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.
Its bloat. You can do shadow dom and web components in modern native JS.
State library is prob all you need now.
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 have an Astro site that's mostly static with a couple interactive components. I recently converted the components from React to Lit and the result is so much simpler.
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...
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
I was all in on Svelte and SvelteKit until I started encountering CSS weirdness caused by a bug that the Svelte developers said is "by design", namely that components' CSS isn't removed from the document after the last instance of that component is no longer rendered. This resulted in a situation in which styles became dependent on the navigation path the user takes, leading to weird an unpredictable layout issues. I couldn't stomach solving this by using Tailwind.
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.
Interesting, so if I'm understanding correctly, component A's style was supposed to change when component B was present, and this was implemented as styling rules in component B? Why was Tailwind necessary rather than moving these rules to component A (which I know would probably require some gnarly selectors)?
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.
There are dozens of us
Launching a new product in SvelteKit! Coming from Vue and it has been mostly great.
I feel the same way about ember.js :]
I've never been a front-end developer in my entire career until 2026 working on a mature (but new to me) project with react in it: This shit is spaghetti.