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.
I skimmed through it, and I think the only thing that is out of date is the section on `zone` in Angular. In october 2025, they changed to `zoneless` by default, which uses signals just like Vue. This was a long time coming imo, as the major criticism of Angular was how poorly update management was handled. Also Svelte runes aren't mentioned, as that came out three months after this post. Runes are essentially also signals.
Basically every framework now has a concept of
* State - change this and the framework automatically updates UI and triggers effects
* Effects - functions that run when parts of state change (or triggered by signals)
And almost everyone solves this with signals except for React.
Any conversation which isn't dead will age fast in tech. What is the state of discussion on generating a random integer? Even that conversation advances.
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.
It does, if you care about ergonomics. The reactivity model is simpler and arguably less error prone.
It does have its own templating syntax, which is trivial to learn. No more cumbersome to learn than JSX, which is a templating language designed by the React team. Not sure why you chose to make the distinction between JSX and Vue’s DSL as if JSX wasn’t developed for the sole purpose of facilitating React’s virtual DOM.
JSX is <div>abc</div> turns into createElement('div', null, 'abc') and you can use that instead of JSX if you like or you can use something like hyperscript. Everything else like mapping or if statements is pure JS and works just like JS anywhere else in your app.
Vue templates mean learning Vue's custom syntax for if statements, loops, dynamic attribute syntax (with its own gotcha), binding dot modifiers, data binding, and whatever else. It requires learning its entire custom directive system. It uses custom syntax for stuff like events too.
I don't see this as remotely comparable with Vue being much closer to something like my time working with Angular 1 (a time I'd rather not repeat).
It is a massive difference. I do not like magic compilers. The JSX transform is trivial and not even necessary, just create a factory function and React.createElement becomes arguably more readable, just not HTML like.
Is it a massive difference, or is it a small difference? At the end of the day 99% of React projects have a transpilation step and utilize some form of “magic compiler” somewhere along the line.
The simplicity of JSX is overvalued. It just means more code, and typically uglier code, to achieve the same behaviour as Vue. Which is basically the theme of React when you compare the two libraries.
JSX is a very thin layer of templating logic inside JS. Meaning you have all the language features available while templating. Some arbitrary JS can result in templating.
Vue's DSL is whatever language the developer implemented. Which is probably not enough, depends how much effort they put into it and how good they are in language design. Given that they cargo cult HTML tags to organize components in a pseudo-familiar but not-valid-HTML way, I don't have much confidence in their language design skills.
While I understand the advantage of using the built-in language features (and I know why it is required to be done that way), I still think using
{enable && <Form />}
for conditional rendering, or
{collection.map(x => <Item x={x} /> }
for looping are not the most obvious choices. If you ask people how conditionals and loops are written in JS, you will get 'if' and 'for' or variants of 'while'. So I get where the v-if and v-for are coming from.
Vue solve single source of truth much better than react though. The shape of derived data and source data (or even external data) are the same and interchangeable. So you can write an api that works with both without handling implementation quirks at all.
The company I work for uses Vue. I think the non-backwards-compatible move from Vue 2 to Vue 3 burned a lot of the current devs, so now they're stuck working on Vue 2 apps that are in maintenance mode with no viable case to clean up the mess by moving everything to Vue 3. The experiments to do it with Copilot mostly failed, although that was in the early days so another try today might work better. If we're doing something drastic to improve though, we might as well solve our "Vue devs are hard to find" problem by rebuilding it all in React at the same time.
I am in a process of upgrading fairly big Vue 2 app (technically 2 apps, where one is not traditional and the other uses Inertia) to Vue 3.
It is a fairly painful process - I am using Codex and Claude as a first pass for converting things, but everything has to be checked manually and often fixed or rolled back to try again. Too often instead of "removing" piece of code that is not necessary anymore, AI would try to add a 100 line workaround for it because it would really rather add things than remove them.
It is, however still a faster process than doing manual rewrite. Smaller components are a breeze to convert from older Vue 2 to Vue 3 composition API.
Rewriting entry point app.ts with bunch of custom plugins was a horrendous experience that eventually was done manually. Move from Vuex to Pinia was also 50/50. Some things were easy, some things were not and had to be done manually.
Then there's a process of switching from unsupported packages which is a whole other can of worms.
Overall - if not for AI I'm not sure I'd have gone with an upgrade at this point. Yes it requires careful review and testing, but a ton of trivial stuff was done very quickly.
I led a project to (successfully) migrate a Vue 2 to 3 app and while that was painful and expensive, I still find Vue more pleasant to work with than React once it was done. But TBH depending one team code discipline either could be fine or a nightmare. :)
I definitely sympathize with the feelings about the Composition API. Though I’ve moved past it because looking at React’s visible complexity (useMemo, useEffect - which apparently have changed names again since I last looked) - Vue has clearly chosen a superior API design.
Yeah you’re actually right I was looking at the API section instead of the Hooks section. Perhaps another demonstration of React’s verbose API surface.
This sentiment only really applies if you’re coming from
Vue 1/2 to Vue 3. The Composition API is definitely more like React but makes some better design decisions that make it easier to work with than React. Such as implicit reactivity.
If anything, composition API has taken the good parts from React. Once you get the hang of it, it’s amazing. Everything clicks together, is easily composable, and fully typed-safe.
Yup I'd sign this. We use Vue2 in a old codebase with options API and composition API in new projects. Both feel way better than anything I ever had to do with React (how many Hooks do you have to learn by now? 13?)
Vue just has a very simple lifecycle and combined with a simple store like Pinia it's just really fun to work with.
Agreed. Like you, I went from hand-written cgi-bin html to jquery to angular v1 to React. I will willingly reach for React as a tool - it does what I want to do.
We're still using it for our stuff (via our @beanbag/spina TypeScript wrapper for Backbone that has a few additional niceties), and I feel the same way. We can be as close to the DOM as we need (or let something manage it for our view for us), we can be smart about where data lives and how things interact with it/listen for changes, and we get a decent little object model that doesn't dictate how we think about everything.
Very happy still with the Backbone way of building webapps.
"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?
Vue-Router and Pinia have always been optional add-ons for Vue too, however, yet the Vue ecosystem seemed to to fine without those "aaakshually“ kinds of people that feel the need to micro-manage other people’s speech.
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.
Yep, react is indeed a library. Part of the confusion comes from a fact that
react community was keen to hijack "react" name and slap it onto their own
projects, for example there were react router, react query, react table, etc.,
so one could have get a feeling that react was like full-fledged framework, while most
of these "react" projects were not affiliated with react the library in any way.
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.
I migrated from Angular 4 to 18 (including ngrx and material) and didn't find it especially problematic.
Migrating mostly was little effort and consisted of automatic migration and walking through the provided checklist (mostly to ensure I didn't miss anything important), but I don't have any comparison in the JS SPA ecosystem.
I tried Angular 2+ back in the day. I found it frustrating to learn as the API had changed between versions, and when searching for help you would come across a blog post/stackoverflow answer, start implementing it and realise it didn't work in the version of Angular your project was in. Frustrating.
Tried React afterwards, this frustration didn't really exist and it was much easier to pick up.
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've tried solid and it's much nicer on small projects. How well does it scale though? Modern React is also 'more functional' (for some definition) but it comes at a cost of cumbersome and leaky abstractions. Classic React walked a fine line of being 'just reactive enough'. You could make code declarative and composable while still micromanaging certain lifecycle and data dependency decisions that can be critical for performance.
I've built quite complex applications (e.g. a spreadsheet app) using SolidJS as a base layer, and in that sense it scales really well. It's very easy to separate data management from the UI, so architecturally it scales well, and performance-wise we rarely had issues with it at all.
The biggest issue is in finding people to work with it. If you're hiring React developers over web developers, they will probably struggle more with SolidJS's differences from React, in part because they just look so similar that there's more to "unlearn". But most web developer (i.e. anyone who can understand beyond just the confines of their favourite framework) should find it relatively easy to understand what's going on.
Haha, that was part of the reason we originally went down this route. In practice, as soon as you want to implement spills, you lose a lot of the benefits because the contents of a spill can depend on any other cell and affect almost any other cell, and you need to evaluate the spill to figure out which cells are relevant. In the end, we rewrote the spreadsheet engine to use a different mechanism that was simpler and that we could optimise better, and then hooked that into SolidJS for everything else.
I guess technically that part of the application didn't scale so well in SolidJS, but it scaled a lot better than it would have in any other framework, and we got to delay writing the engine "properly" until we'd already built everything else and got it running with real users in production.
How did the React community convince so many people of this falsehood? Do that many people just not know what javascript is? It baffles me that one could look at JSX and be like, “that right there is vanilla javascript”.
What people mean is obviously that you use JS primitives for looping, branching, conditionals, etc. over some DSL. Everybody knows that the tags are added syntax, there is no conspiracy here.
"These burgers are pure beef! Obviously what people mean is that beef is one of the ingredients. Everyone knows that the plastic is added in, there's no conspiracy here"
It's like arguing the moon and sun are the same size because they look the same size when looking at the sky. A hamburger with added plastic is essentially a hamburger. A hamburger made out of plastic that resembles beef is not.
vanila javascript would not be far off, just replace the tags with function calls. In early versions of react, there were people who wrote code like that. For some reason web devs since collectively agreed that the xml syntax is essential to web technologies
> 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.
There are four culprits here and neither is due to JS.
First is the pursuit of polish. Each extra 1% in polish adds tons and tons of lines of code. If you want that level of polish on a non-SPA, you'll still have to add all that code then reload it one page at a time. I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.
Second is bloated do-everything libraries. Ant, MUI, Mantine, or whatever else is aimed to be a superset of all possible website needs which means that the components you adopt have tons of features and bloat you don't need that slow down loading, parsing, and execution. Simply replacing that <Paper> component with a <div> and a few lines of CSS will get you the same thing you want, but will save you layers of unnecessary React components and sometimes a layer or two of unneeded DOM nodes as well that were added because the <Paper> component had weird interactions with some other component.
Third is manpower/experience. Many/most JS devs today (sad to say) don't actually know how to make that simple <Paper> component on their own. Those that do often skip it because they've got too much to do already. I've lost count of the number of teams I've seen where a bog-standard backend has 25 people working on stuff while the frontend team has 3x as many total lines of code (which are often times handling human-computer interaction issues the backend couldn't even imagin), but only 3-4 people to maintain it all.
Fourth is of course management. Designs on the backend change at a trickle while changes to the frontend arrive in a torrent. Understaffed frontend teams can't keep up with all the things shoved on their plate, so they usually can't optimize things even if they know how (eg, only a small percentage of SPA actually know/take the time to lazy load various parts of their apps to improve load time).
Fix these things and the SPA performance will improve drastically and almost certainly exceed BE templates with some jQuery spaghetti.
>I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.
having lots of JavaScript tends to make more WCAG problems, because you do interactive stuff that needs to be described. Having bare HTML and the accessibility that is required for that is not tending to bloat in my experience.
Users need interactive stuff. If your site isn't interactive and your competitor's site IS interactive, customers almost certainly will prefer your competitor.
When you try to chain that stuff across multiple backend-rendered pages, you get a whole other list of problems. If you need to track all the otherwise transient UI stuff on the BE, you have now created a whole mess of stateful APIs and turned horizontal scaling into a much bigger issue than it needed to be.
so you argued that the need for internationalization and Accessibility was such that if you tried to add that in to bare html - css solution that you would end up getting bloated, I argued (based on my experience) that accessibility bloat actually comes from the need to support various JavaScript bits of accessibility.
To which you then argue that the JavaScript parts are needed.
If so it is the JavaSript that adds the bloat, because the accessibility bloats to support the JavaSript.
I mean I'm not against JavaSript but I have seen many sites that didn't need it; and I've been forced by work requirements to add in too much of it on sites that needed very little or even none at all.
Users wants something that will help with whatever they want done. And the quicker, the better. Interactivity is nice, but I never seen anyone complains about multipages applications.
> If you need to track all the otherwise transient UI stuff on the BE
So don’t add transient stuff? You send a page or a form according to the URL, the user does whatever it wants and either request a new page or submit the form. Each page is standalone like activities in an Android app. Anything transient is taken care of on the client side.
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.
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 have never been able to pick the framework and libraries for my day job. I’m almost always working on something someone started years prior or bound to an organization that has strict choices. Personally I wouldn’t pick react :)
React wins because it has become a default choice and folks like what’s comfortable to their preferences
I mean, that means someone at your work liked React enough to choose it over the alternatives.
I see a lot of personal projects, solo founder applications etc running made in React. I respect your opinion but other people definitely do choose it when they have fully control of what they use.
I've been in the situation a couple of times where we had full control over choosing the frontend framework. Every time we chose React, the main argument was hirability and the fact that the engineers in question were most proficient in React. That is, inertia.
Secondly, when someone new asks me what web framework to learn, I tell them React. And the main reason, every time, is that this is more likely to get them a job, i.e., inertia.
We got here somehow. Clearly, React didn't get here purely on momentum, and must have done something less poorly than the other frameworks. But I think it's hard to deny that inertia plays a big role in its current popularity.
Most decision-makers make decisions based on what they already know. Most of my colleagues only know React, because they've only been exposed to React. Why do you think Java dominates the market still? React solved a huge problem when it was new, and it still solves that problem fine (change detection - the reactivity model). There are better alternatives available now (Vue - signals), but the difference isn't big enough to create a new monoculture. Sure there are peripheral concerns like how mature the ecosystem is or the particular ergonomics of a framework, but these are mostly fluff.
That doesn’t mean they like it now, and more importantly it doesn’t mean it was actually the best choice at the time.
I used to be on a team that used Mongo for a relational database because Mongo was trendy at one time. So all joins had to be done in the application layer.
React is bad exactly because this predictability doesn't exist, it changed radically for the worse at least 2 times without any consultation to the community
React does have its benefits, but there is also a tendency to pick it because of the inertia it has over whether it is the best tool for the job. "Everyone uses react and this will maximize our hiring pool / set of contractors we can use", "A react project will look good on my resume".
I don't see why "inertia" or adoption should be excluded when deciding what library to use for the job. If you are manufacturing a physical product you will need to consider how easy it is to source any component before adding it to your bill of materials. I don't see why software engineering should be different. There is a reason why we are all working in boring languages and not Haskell or LISP despite their supposed technical superiority.
On the contrary, I am forced to use React and Next.js as many SaaS vendors have partnerships with Vercel, and only make extension points available with them.
If I want anything else, I have to implement the integrations myself, search for some open source project that has already done it, or ask AI.
Doable on hobby projects, unthinkable in professional settings.
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.
I never get this take. A react component is not just a function, it's a function plus a magically injected context that is accessed through hooks which requires all kinds of guarantees that you have to be aware of otherwise it will have hard to debug consequences. Imo it's anything but elegant.
I did projects in all major frameworks and am building a huge angular web app currently. In angular a component is represented as a class plus template (plus styles). A event listener is mostly calling a method on the class. A state can be as simple as a property on the class. It's very natural and there are way less caveats (although not zero).
Interesting that you still stand by that, even after Apple moved to the exact same model with Swift UI.
Narrowmindedly worrying about syntactical differences is contributing nothing to the conversation. The point is relinquishing control of state to the framework (be it via props, hooks or @State), and drawing the UI as a pure representation of whatever the framework tells you. Hence ui = f(state). This gets you a metric ton of advantages, which is why every modern framework is doing it.
Classes, by themselves, are inadequate as containers for state unless that state must only exist in memory and never be observed, synchronized or serialized. You can attempt to patch that with decorators, ORMs or whatever, but now you're doing the same thing as React is doing with functions.
How long have you used Vue? I had a similar opinion on Vue a few years ago, coming from a background of React as well. But now I prefer it over React, and reach for it in both personal and professional projects. The ergonomics are a bit different; there are things that are easier to do in React, and things that are easier to do in Vue, but the fact that it uses signals is a huge plus for me.
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.)
They are actually speaking to trying to make an in-app back button use the history stack so that it _doesn’t_ “break” your browser’s back button.
The problem with just calling history.back() with no fallback is it will bounce users out of your app (back to Google or wherever they came from) and PMs won’t like that…
`history.back()` shouldn't even exist, it's almost never correct to use it instead of a logical back button that works on the logical navigation structure e.g. going up a level, or to the previous page, etc.
For example, if you are on Page 5, then pressing "back" inside the app should always take you to Page 4. `history.back()` could take you to any page, it's unpredictable.
Disagreed. In everyday speech "going back" means going to where you came from. If I'm at a friend's place at 123 Main Street and I tell him I'm going back, what I'm saying is I'm heading back to my home, not to 122 Main Street. The web should work similarly.
And the idea of logical navigation is flawed because most websites don't have a well defined logical structure, nor is it feasible to have one. What is the previous page of a Wikipedia article, or an HN submission, or an Amazon listing, or a search result of cheapest direct flights between New York and Cancun? With how the back button currently works, at least there is consistency in what to expect when clicking it. Under your suggestion, there is no way a user knows what the back button does on each website unless he clicks on it first and find out himself.
It’s really common that you can arrive on a view from different places.
For example on instagram you might click through to a post from the explore page or from someone sending it to you via DM. In either case pressing the back button rendered in the app, or swiping back, will take you back to where you came from. It feels natural and seamless. Although I guess there are other ways to skin that cat than history.back()
But I agree with you when there’s a clear hierarchy. Like on a job ad a “back” button should just be a normal link to the index of job openings.
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.
It’s an absolutely not true that react is especially bad for this behavior.
I think that lots of more traditional websites have very poor back button designs, especially around editing and form submissions. Remember clicking back and the browser prompting for form resubmission? Very poor design since you have no clue how the server will even handle form submissions. Or getting stuck deep in an application, hard to get back to the root. Or, consider encoding current page data that you’re editing into the URL, and back buttons don’t return to root and just strip query params. Often a very frustrating experience.
Often, “go back to what I was doing before” is what I actually want, not “go strictly to the previous state in the URL bar.”
Sure, plenty of people mess that up too, but the reality is that controlling the navigation stack can help you build more useful designs.
Isn't the best way to solve the back button question to not be so damned complicated and just make certain that only things which you want to go back to ends up in the history? The whole framing of the problem just screams "structure your thing better and it won't be a problem to solve".
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 you could, or even just a vanilla DOM event handler on a button click.
The problem is that you cannot introspect the browser’s history with the history API. So you have to hack your way around that if you want the “go back in history if possible, otherwise navigate to fallback url” behavior. Which I guess is easier if you’re in a react SPA. Or if you’re fully a MPA and can just check document.referrer
There’s a brand new Navigation API that does let you introspect history entries from the same origin, which perfectly addresses the issue.
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.
> Some languages just feel incredibly natural and frictionless for certain things, and nobody has really nailed UIs yet.
Emphatically yes. If you look at books written about the problem in the early 90s[1], they are still applicable today.
> The current solutions, although I find it hard to describe precisely, are always tantalizingly lacking in one way or another.
The best analysis of this I have seen so far is in Chatty's Programs = Data + Algorithms + Architecture: consequences for interactive software engineering [2]. It's a bit hard to get through, but absolutely worth it.
As a short summary, the problem is architectural, or more specifically linguistic/architectural mismatch: the architecture our "general purpose" programming languages induces, which is the call/return architectural style, does not match the architecture required for user interfaces, but rather conflicts with that style.
I also wrote about it in Can Programmers Escape the Gentle Tyranny of call/return?.
My current approach is to first build a programming language that can easily express alternative architectural styles: Objective-Smalltalk [4].
With that I am now working an a UI framework I call interscript, including HTMXNative and other goodies.
As an engineer, it's easy to look at every problem and think to yourself: "There is a perfect solution for this, we just haven't found it yet."
Yet, as the years go by, I find myself accepting a less idealistic answer: Maybe there isn't. Maybe the problem space is just so complex that no one (humanly feasible) general solution exists for all forms of it. If there's one thing that this is true for, UI is probably it.
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.
I like TEA but don't fully grasp how it scales for apps that may have reusable components or sufficiently complex pages. Is there an agreed-upon way(s) to deal with this? I know state is a big NO so it seems a bit at odds, but also does this essentially mean all Elm apps are just a global Redux and React app with no effects? Curious about more details to what you enjoy and how you like to work in Elm. Links also perfectly fine too.
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 wouldn't say Compose UI/Flutter/SwiftUI are "implementing React", but if your point is that other platforms have better solutions than JSX (plus all the bloat React adds to applications), I absolutely agree.
I'd argue that it's directly related. If intuitive use of a library/framework/pattern commonly causes issues, you have to keep forcing yourself to do use non-intuitive approaches to prevent them.
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.
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 basically skipped React. I went from jquery to Vue3, and use even that sparingly. When React got really popular, I read the docs and played with it, but I prefer the Vue model where the component runs once and sets up its reactive tree. Why would you want to recreate the component's inner functions every time it renders? And manually declare dependencies, when every other framework is doing them automatically?
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 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.
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 only migrated projects from React to something more sensible. I am not sure why people like it. Maybe it is good for bigger teams. Astro with OpenProps is what is super simple, fast to develop and maps naturally to the business functionality I work on most of the time.
I have no idea why people go for these super heavy frameworks. Maybe there are some aspects I am not considering that justifies React.
I can see where the arguments for React's alternatives like Preact, Vue, Svelte, Solid, etc. come from. All of them are better than React at least in one aspect and React's dominance is mostly due to inertia: Developers (and now LLMs) know it better and the ecosystem is richer.
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.
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.
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.
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.
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.
Open source tech is a marketplace of ideas. If you have a more perfect alternative then it will prevail.
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.
I am wondering how much the "perfect alternative then it will prevail" still holds given the amount of money spent on marketing by infrastructure companies, for example Vercel that have an interest in promoting Next.
That’s a fair take. What happened to google’s angular ? Facebook is also historically invested in php, why wasn’t php just good enough? Facebook also had flow, Microsoft typescript won.
Sure these companies have influence, but it’s not all or nothing.
I just don’t buy the whole mass hysteria and funding being responsible for reacts prevalence.
“Frontend purity” reeks of the tired, “lazy unskilled engineers should write software in C and assembly on 16kb memory like the old days”
Reacts success is not from being an air tight optimized and perfect abstraction, it succeeds because it has a scalable abstractions which have relatively good ROI when you learn it even with its warts.
> Open source tech is a marketplace of ideas. If you have a more perfect alternative then it will prevail.
React has had Facebook promoting it for over a decade… it's hardly a marketplace of ideas… more "Facebook is using this so it must be good enough for us"
No particularly strong feelings either way. It suffers from the same issue as all the other JS frontend - it evolved along with browsers over years and was constrained by whatever browsers happened to support rather than from a cohesive design
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.
I used to love react of old with redux/flux and little to no hooks and weird side effects. It had super sound software design at the cost of being bulky.
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.
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 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.
> 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.
Subjective depending on who you ask, but for me RSC is not really representative of React usage. (I believe) the vast majority of React apps (and the vast majority of dev experience in React) are front end only. I have been writing React in some form for 8+ years, but never touched RSC.
I actually like React's virtual DOM approach. It might not be the fastest possible solution, not the most elegant syntax, not particularly concise. but I can at least understand what it does and how data flows. I learned the hard way that with reactive programming (whether you call it observables, runes, signals, whatever) you can lose that understanding and it's a huge pain when that happens.
I like scripting so I like having a <div id=root> and then do everything in JS. No need for Typescript or React, innerHTML=`...` works fine. For a serious project, React and Typescript make sense but it can still be used wrong. The default Laravel project that's generated when choosing React looks really bad to me. Too many files and comments and tests. It's over-engineered.
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.
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.
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 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.
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.
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.
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 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.
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
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.
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.
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.
Would be silly to rate your stack without knowing more about what it is and its constraint.
If I had to judge it based on this alone post alone:
Great, seems like a straight forward stack. Would happily work on it.
Only criticism, to get all the ergonomics out of alpine, you sometimes have to lax some CSP or use the CSP build. Not necessarily a deal breaker, it is what it is.
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.
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.
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
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.
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.
I prefer HTML over JSX, and AlpineJS is good enough. Sometimes it's nice to have a few web components.
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.
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.
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.
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 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 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 lived there idea of hooks when they were introduced.
But they’ve honestly not worked out.
React works have been a lot better if the React team has figured out what useEffect was supposed to be right at the beginning, or at least when they changed what it was supposed to be used for they documented that clearly instead of gaslighting devs into believing nothing has changed.
Also, hooks aren’t a thing. Each hook is its own API and concept. Grouping them under the umbrella term “hooks” gave the wrong impression that it was a single concept, but there’s No conceptual similarity between ushered, useState or useEffect. The only similarity are the restrictions on their use and nomenclature.
In every single project I worked on using Next.js as a kind of full stack framework, eventually I need to do something on the FE as well, and end up debugging a spaghetti of useSomething() until I figure out where to actually implement what I need.
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, 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 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.
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 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.
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 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.
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.
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.
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.
A bit out of date, but I like the point-of-view of "The single most important factor that differentiates front-end frameworks" : https://mjswensen.com/blog/the-single-most-important-factor-...
Fantastic article. It is strange that such important aspects of JS frameworks are so rarely discussed.
> A bit out of date
> article just about to turn three years old
JavaScript community never beating the allegations lol
I skimmed through it, and I think the only thing that is out of date is the section on `zone` in Angular. In october 2025, they changed to `zoneless` by default, which uses signals just like Vue. This was a long time coming imo, as the major criticism of Angular was how poorly update management was handled. Also Svelte runes aren't mentioned, as that came out three months after this post. Runes are essentially also signals.
Basically every framework now has a concept of * State - change this and the framework automatically updates UI and triggers effects * Effects - functions that run when parts of state change (or triggered by signals)
And almost everyone solves this with signals except for React.
Any conversation which isn't dead will age fast in tech. What is the state of discussion on generating a random integer? Even that conversation advances.
Great article. I prefer the react model over the other models. Now it'd be good to know, with every framework, which of these it implements.
Terrific read thanks for digging it up
I was deep in Vue 5-6 years ago, so much that I offered internal training for it and had sessions with more than 20 people attending.
IMHO, React wins because you can just treat templates as variables. You don't need "slots" or other special stuff. It's simply more composable.
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.
It does, if you care about ergonomics. The reactivity model is simpler and arguably less error prone.
It does have its own templating syntax, which is trivial to learn. No more cumbersome to learn than JSX, which is a templating language designed by the React team. Not sure why you chose to make the distinction between JSX and Vue’s DSL as if JSX wasn’t developed for the sole purpose of facilitating React’s virtual DOM.
JSX is <div>abc</div> turns into createElement('div', null, 'abc') and you can use that instead of JSX if you like or you can use something like hyperscript. Everything else like mapping or if statements is pure JS and works just like JS anywhere else in your app.
Vue templates mean learning Vue's custom syntax for if statements, loops, dynamic attribute syntax (with its own gotcha), binding dot modifiers, data binding, and whatever else. It requires learning its entire custom directive system. It uses custom syntax for stuff like events too.
I don't see this as remotely comparable with Vue being much closer to something like my time working with Angular 1 (a time I'd rather not repeat).
It’s a distinction without a difference. Both need to be transpiled, what happens under the hood is of little concern to anyone.
Please explain React’s reactive data binding since it’s apparently much simpler than v-model=
;)
It is a massive difference. I do not like magic compilers. The JSX transform is trivial and not even necessary, just create a factory function and React.createElement becomes arguably more readable, just not HTML like.
Is it a massive difference, or is it a small difference? At the end of the day 99% of React projects have a transpilation step and utilize some form of “magic compiler” somewhere along the line.
The simplicity of JSX is overvalued. It just means more code, and typically uglier code, to achieve the same behaviour as Vue. Which is basically the theme of React when you compare the two libraries.
Vue supports JSX, though to be fair, it’s not idiomatic and hence never shows up in any docs.
thankfull. i find reading JSX A visible eyesore, like an LLM reached its comtext length and just snorted blood and bile out its nose
JSX is a very thin layer of templating logic inside JS. Meaning you have all the language features available while templating. Some arbitrary JS can result in templating.
Vue's DSL is whatever language the developer implemented. Which is probably not enough, depends how much effort they put into it and how good they are in language design. Given that they cargo cult HTML tags to organize components in a pseudo-familiar but not-valid-HTML way, I don't have much confidence in their language design skills.
I'd take the former any day.
While I understand the advantage of using the built-in language features (and I know why it is required to be done that way), I still think using
for conditional rendering, or for looping are not the most obvious choices. If you ask people how conditionals and loops are written in JS, you will get 'if' and 'for' or variants of 'while'. So I get where the v-if and v-for are coming from.Vue solve single source of truth much better than react though. The shape of derived data and source data (or even external data) are the same and interchangeable. So you can write an api that works with both without handling implementation quirks at all.
The words borrowed from someone else:
The react is more about view.
The vue is more about reactivity
So JSX is not proprietary?
The company I work for uses Vue. I think the non-backwards-compatible move from Vue 2 to Vue 3 burned a lot of the current devs, so now they're stuck working on Vue 2 apps that are in maintenance mode with no viable case to clean up the mess by moving everything to Vue 3. The experiments to do it with Copilot mostly failed, although that was in the early days so another try today might work better. If we're doing something drastic to improve though, we might as well solve our "Vue devs are hard to find" problem by rebuilding it all in React at the same time.
I am in a process of upgrading fairly big Vue 2 app (technically 2 apps, where one is not traditional and the other uses Inertia) to Vue 3.
It is a fairly painful process - I am using Codex and Claude as a first pass for converting things, but everything has to be checked manually and often fixed or rolled back to try again. Too often instead of "removing" piece of code that is not necessary anymore, AI would try to add a 100 line workaround for it because it would really rather add things than remove them.
It is, however still a faster process than doing manual rewrite. Smaller components are a breeze to convert from older Vue 2 to Vue 3 composition API.
Rewriting entry point app.ts with bunch of custom plugins was a horrendous experience that eventually was done manually. Move from Vuex to Pinia was also 50/50. Some things were easy, some things were not and had to be done manually.
Then there's a process of switching from unsupported packages which is a whole other can of worms.
Overall - if not for AI I'm not sure I'd have gone with an upgrade at this point. Yes it requires careful review and testing, but a ton of trivial stuff was done very quickly.
I led a project to (successfully) migrate a Vue 2 to 3 app and while that was painful and expensive, I still find Vue more pleasant to work with than React once it was done. But TBH depending one team code discipline either could be fine or a nightmare. :)
I definitely sympathize with the feelings about the Composition API. Though I’ve moved past it because looking at React’s visible complexity (useMemo, useEffect - which apparently have changed names again since I last looked) - Vue has clearly chosen a superior API design.
Unless I’m completely missing something, those hooks still have the same names and semantics as always?
Yeah you’re actually right I was looking at the API section instead of the Hooks section. Perhaps another demonstration of React’s verbose API surface.
I'm using Vue and do not feel it's becoming react
This sentiment only really applies if you’re coming from Vue 1/2 to Vue 3. The Composition API is definitely more like React but makes some better design decisions that make it easier to work with than React. Such as implicit reactivity.
If anything, composition API has taken the good parts from React. Once you get the hang of it, it’s amazing. Everything clicks together, is easily composable, and fully typed-safe.
Yup I'd sign this. We use Vue2 in a old codebase with options API and composition API in new projects. Both feel way better than anything I ever had to do with React (how many Hooks do you have to learn by now? 13?)
Vue just has a very simple lifecycle and combined with a simple store like Pinia it's just really fun to work with.
as long as JSX never becomes default in Vue, vue is still winning
Agreed. Like you, I went from hand-written cgi-bin html to jquery to angular v1 to React. I will willingly reach for React as a tool - it does what I want to do.
I like react over angular and vue over react.
same here thus I'm with vue
We are very far away from Angular 1.0 days, and not every single website needs JavaScript.
Exactly right. And this is why Astro works very well for me.
As someone who went through that same journey, agreed.
Compared to previous paradigms, React lets you compose complexity and rich interactivity really, really well. Even for all its flaws.
React was a major improvement over Backbone + Marionette. Pre-jQuery was a shit-show as they hadn't even standardised the DOM.
Before that was XMLHttpRequest (particularly during my .Net WebForm days) and even had to use the ActiveXObject in IE that predated JSON.
Give me Backbone + anything over React. Backbone was the last time I really felt close to the web page I was creating.
We're still using it for our stuff (via our @beanbag/spina TypeScript wrapper for Backbone that has a few additional niceties), and I feel the same way. We can be as close to the DOM as we need (or let something manage it for our view for us), we can be smart about where data lives and how things interact with it/listen for changes, and we get a decent little object model that doesn't dictate how we think about everything.
Very happy still with the Backbone way of building webapps.
XML, XMLHttpRequest, and XSLT in IE 5 was peak web dev for me. Never been more productive.
This feels like the equivalent of "whatever music you liked at 16 defines your taste"
Oh boy the ActiveXObject brings back some ~~ptsd~~ fond memories.
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?
Vue-Router and Pinia have always been optional add-ons for Vue too, however, yet the Vue ecosystem seemed to to fine without those "aaakshually“ kinds of people that feel the need to micro-manage other people’s speech.
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.
you can use React like a library, but I have never really seen it done.
Depends on the definition.
jQuery isn’t a “framework” either, at least not like Angular or Vue, though it can be extended with “plugins.”
Both jQuery and React are foundational technologies, so comparison is valid.
jQuery isn’t exactly a “framework” either, at least not like Angular or Vue, though it can be extended with “plugins.”
Both jQuery and React are foundational technologies, and comparison is valid.
Yep, react is indeed a library. Part of the confusion comes from a fact that react community was keen to hijack "react" name and slap it onto their own projects, for example there were react router, react query, react table, etc., so one could have get a feeling that react was like full-fledged framework, while most of these "react" projects were not affiliated with react the library in any way.
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.
Where would you put custom elements in your list?
What about Angular 2+?
After the disaster of AngularJS that we are still paying external EOL support on, I will never trust another Google led framework.
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.
can you compare it to other frameworks?
I migrated from Angular 4 to 18 (including ngrx and material) and didn't find it especially problematic.
Migrating mostly was little effort and consisted of automatic migration and walking through the provided checklist (mostly to ensure I didn't miss anything important), but I don't have any comparison in the JS SPA ecosystem.
I tried Angular 2+ back in the day. I found it frustrating to learn as the API had changed between versions, and when searching for help you would come across a blog post/stackoverflow answer, start implementing it and realise it didn't work in the version of Angular your project was in. Frustrating.
Tried React afterwards, this frustration didn't really exist and it was much easier to pick up.
The frustation is pretty much there under Vercel's stewardship, especially when React comes in the shape of Next.js.
It is apps or pages, which supports what, what new use cases is "use..." now for, ....
Chesterton’s framework.
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've tried solid and it's much nicer on small projects. How well does it scale though? Modern React is also 'more functional' (for some definition) but it comes at a cost of cumbersome and leaky abstractions. Classic React walked a fine line of being 'just reactive enough'. You could make code declarative and composable while still micromanaging certain lifecycle and data dependency decisions that can be critical for performance.
I've built quite complex applications (e.g. a spreadsheet app) using SolidJS as a base layer, and in that sense it scales really well. It's very easy to separate data management from the UI, so architecturally it scales well, and performance-wise we rarely had issues with it at all.
The biggest issue is in finding people to work with it. If you're hiring React developers over web developers, they will probably struggle more with SolidJS's differences from React, in part because they just look so similar that there's more to "unlearn". But most web developer (i.e. anyone who can understand beyond just the confines of their favourite framework) should find it relatively easy to understand what's going on.
Implementing spreadsheets with fine-grained reactivity is basically cheating.
Haha, that was part of the reason we originally went down this route. In practice, as soon as you want to implement spills, you lose a lot of the benefits because the contents of a spill can depend on any other cell and affect almost any other cell, and you need to evaluate the spill to figure out which cells are relevant. In the end, we rewrote the spreadsheet engine to use a different mechanism that was simpler and that we could optimise better, and then hooked that into SolidJS for everything else.
I guess technically that part of the application didn't scale so well in SolidJS, but it scaled a lot better than it would have in any other framework, and we got to delay writing the engine "properly" until we'd already built everything else and got it running with real users in production.
Could you expand on your experience compared to react?
> 100% pure JavaScript directly
How did the React community convince so many people of this falsehood? Do that many people just not know what javascript is? It baffles me that one could look at JSX and be like, “that right there is vanilla javascript”.
Yeah man it’s pure JS trust me just add this little transpiler and you’re good to go. What do you mean you don’t have a bundler?
What people mean is obviously that you use JS primitives for looping, branching, conditionals, etc. over some DSL. Everybody knows that the tags are added syntax, there is no conspiracy here.
"These burgers are pure beef! Obviously what people mean is that beef is one of the ingredients. Everyone knows that the plastic is added in, there's no conspiracy here"
It's like arguing the moon and sun are the same size because they look the same size when looking at the sky. A hamburger with added plastic is essentially a hamburger. A hamburger made out of plastic that resembles beef is not.
JSX is basically just a subset of E4X.
vanila javascript would not be far off, just replace the tags with function calls. In early versions of react, there were people who wrote code like that. For some reason web devs since collectively agreed that the xml syntax is essential to web technologies
>Sevelte
FYI: https://www.merriam-webster.com/dictionary/svelte
I never wanna use anything but Svelte ever again, honestly.
> 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.
There are four culprits here and neither is due to JS.
First is the pursuit of polish. Each extra 1% in polish adds tons and tons of lines of code. If you want that level of polish on a non-SPA, you'll still have to add all that code then reload it one page at a time. I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.
Second is bloated do-everything libraries. Ant, MUI, Mantine, or whatever else is aimed to be a superset of all possible website needs which means that the components you adopt have tons of features and bloat you don't need that slow down loading, parsing, and execution. Simply replacing that <Paper> component with a <div> and a few lines of CSS will get you the same thing you want, but will save you layers of unnecessary React components and sometimes a layer or two of unneeded DOM nodes as well that were added because the <Paper> component had weird interactions with some other component.
Third is manpower/experience. Many/most JS devs today (sad to say) don't actually know how to make that simple <Paper> component on their own. Those that do often skip it because they've got too much to do already. I've lost count of the number of teams I've seen where a bog-standard backend has 25 people working on stuff while the frontend team has 3x as many total lines of code (which are often times handling human-computer interaction issues the backend couldn't even imagin), but only 3-4 people to maintain it all.
Fourth is of course management. Designs on the backend change at a trickle while changes to the frontend arrive in a torrent. Understaffed frontend teams can't keep up with all the things shoved on their plate, so they usually can't optimize things even if they know how (eg, only a small percentage of SPA actually know/take the time to lazy load various parts of their apps to improve load time).
Fix these things and the SPA performance will improve drastically and almost certainly exceed BE templates with some jQuery spaghetti.
>I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.
having lots of JavaScript tends to make more WCAG problems, because you do interactive stuff that needs to be described. Having bare HTML and the accessibility that is required for that is not tending to bloat in my experience.
Users need interactive stuff. If your site isn't interactive and your competitor's site IS interactive, customers almost certainly will prefer your competitor.
When you try to chain that stuff across multiple backend-rendered pages, you get a whole other list of problems. If you need to track all the otherwise transient UI stuff on the BE, you have now created a whole mess of stateful APIs and turned horizontal scaling into a much bigger issue than it needed to be.
>Users need interactive stuff.
so you argued that the need for internationalization and Accessibility was such that if you tried to add that in to bare html - css solution that you would end up getting bloated, I argued (based on my experience) that accessibility bloat actually comes from the need to support various JavaScript bits of accessibility.
To which you then argue that the JavaScript parts are needed.
If so it is the JavaSript that adds the bloat, because the accessibility bloats to support the JavaSript.
I mean I'm not against JavaSript but I have seen many sites that didn't need it; and I've been forced by work requirements to add in too much of it on sites that needed very little or even none at all.
Users wants something that will help with whatever they want done. And the quicker, the better. Interactivity is nice, but I never seen anyone complains about multipages applications.
> If you need to track all the otherwise transient UI stuff on the BE
So don’t add transient stuff? You send a page or a form according to the URL, the user does whatever it wants and either request a new page or submit the form. Each page is standalone like activities in an Android app. Anything transient is taken care of on the client side.
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.
> Web components are the next big idea. I hope they have a chance to work.
This comment could work equally well in any of the past 15 years. And for all we know, any of the next 15.
Angular supports web components as first class, as do frameworks like Blazor.
It is mostly the React crowd that dislikes them.
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.
Exactly, for most websites out there classical webserver rendering does the job pretty well. Even fancy animations can be taken care by pure CSS.
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 have never been able to pick the framework and libraries for my day job. I’m almost always working on something someone started years prior or bound to an organization that has strict choices. Personally I wouldn’t pick react :)
React wins because it has become a default choice and folks like what’s comfortable to their preferences
I mean, that means someone at your work liked React enough to choose it over the alternatives.
I see a lot of personal projects, solo founder applications etc running made in React. I respect your opinion but other people definitely do choose it when they have fully control of what they use.
I've been in the situation a couple of times where we had full control over choosing the frontend framework. Every time we chose React, the main argument was hirability and the fact that the engineers in question were most proficient in React. That is, inertia.
Secondly, when someone new asks me what web framework to learn, I tell them React. And the main reason, every time, is that this is more likely to get them a job, i.e., inertia.
We got here somehow. Clearly, React didn't get here purely on momentum, and must have done something less poorly than the other frameworks. But I think it's hard to deny that inertia plays a big role in its current popularity.
Most decision-makers make decisions based on what they already know. Most of my colleagues only know React, because they've only been exposed to React. Why do you think Java dominates the market still? React solved a huge problem when it was new, and it still solves that problem fine (change detection - the reactivity model). There are better alternatives available now (Vue - signals), but the difference isn't big enough to create a new monoculture. Sure there are peripheral concerns like how mature the ecosystem is or the particular ergonomics of a framework, but these are mostly fluff.
That doesn’t mean they like it now, and more importantly it doesn’t mean it was actually the best choice at the time.
I used to be on a team that used Mongo for a relational database because Mongo was trendy at one time. So all joins had to be done in the application layer.
React wins because it has a predictable interface that has become industry standard. Industry standard saves money. Not everything must be creative.
React is bad exactly because this predictability doesn't exist, it changed radically for the worse at least 2 times without any consultation to the community
Not very predicatble with Vercel ownership.
React does have its benefits, but there is also a tendency to pick it because of the inertia it has over whether it is the best tool for the job. "Everyone uses react and this will maximize our hiring pool / set of contractors we can use", "A react project will look good on my resume".
I don't see why "inertia" or adoption should be excluded when deciding what library to use for the job. If you are manufacturing a physical product you will need to consider how easy it is to source any component before adding it to your bill of materials. I don't see why software engineering should be different. There is a reason why we are all working in boring languages and not Haskell or LISP despite their supposed technical superiority.
On the contrary, I am forced to use React and Next.js as many SaaS vendors have partnerships with Vercel, and only make extension points available with them.
If I want anything else, I have to implement the integrations myself, search for some open source project that has already done it, or ask AI.
Doable on hobby projects, unthinkable in professional settings.
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.
I never get this take. A react component is not just a function, it's a function plus a magically injected context that is accessed through hooks which requires all kinds of guarantees that you have to be aware of otherwise it will have hard to debug consequences. Imo it's anything but elegant. I did projects in all major frameworks and am building a huge angular web app currently. In angular a component is represented as a class plus template (plus styles). A event listener is mostly calling a method on the class. A state can be as simple as a property on the class. It's very natural and there are way less caveats (although not zero).
> I never get this take. A react component is not just a function,
Exactly.
I did a somewhat longer writeup a while back.
https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
The pull request is still open :-)
Interesting that you still stand by that, even after Apple moved to the exact same model with Swift UI.
Narrowmindedly worrying about syntactical differences is contributing nothing to the conversation. The point is relinquishing control of state to the framework (be it via props, hooks or @State), and drawing the UI as a pure representation of whatever the framework tells you. Hence ui = f(state). This gets you a metric ton of advantages, which is why every modern framework is doing it.
Classes, by themselves, are inadequate as containers for state unless that state must only exist in memory and never be observed, synchronized or serialized. You can attempt to patch that with decorators, ORMs or whatever, but now you're doing the same thing as React is doing with functions.
Maybe you would prefer React's class-based syntax. It's still there if you want to use it
How long have you used Vue? I had a similar opinion on Vue a few years ago, coming from a background of React as well. But now I prefer it over React, and reach for it in both personal and professional projects. The ergonomics are a bit different; there are things that are easier to do in React, and things that are easier to do in Vue, but the fact that it uses signals is a huge plus for me.
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.)
They are actually speaking to trying to make an in-app back button use the history stack so that it _doesn’t_ “break” your browser’s back button.
The problem with just calling history.back() with no fallback is it will bounce users out of your app (back to Google or wherever they came from) and PMs won’t like that…
`history.back()` shouldn't even exist, it's almost never correct to use it instead of a logical back button that works on the logical navigation structure e.g. going up a level, or to the previous page, etc.
For example, if you are on Page 5, then pressing "back" inside the app should always take you to Page 4. `history.back()` could take you to any page, it's unpredictable.
Disagreed. In everyday speech "going back" means going to where you came from. If I'm at a friend's place at 123 Main Street and I tell him I'm going back, what I'm saying is I'm heading back to my home, not to 122 Main Street. The web should work similarly.
And the idea of logical navigation is flawed because most websites don't have a well defined logical structure, nor is it feasible to have one. What is the previous page of a Wikipedia article, or an HN submission, or an Amazon listing, or a search result of cheapest direct flights between New York and Cancun? With how the back button currently works, at least there is consistency in what to expect when clicking it. Under your suggestion, there is no way a user knows what the back button does on each website unless he clicks on it first and find out himself.
It’s really common that you can arrive on a view from different places.
For example on instagram you might click through to a post from the explore page or from someone sending it to you via DM. In either case pressing the back button rendered in the app, or swiping back, will take you back to where you came from. It feels natural and seamless. Although I guess there are other ways to skin that cat than history.back()
But I agree with you when there’s a clear hierarchy. Like on a job ad a “back” button should just be a normal link to the index of job openings.
That's not a react thing, it happened before React was even a thing. It's just self-centered website programmer design.
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.
It’s an absolutely not true that react is especially bad for this behavior.
I think that lots of more traditional websites have very poor back button designs, especially around editing and form submissions. Remember clicking back and the browser prompting for form resubmission? Very poor design since you have no clue how the server will even handle form submissions. Or getting stuck deep in an application, hard to get back to the root. Or, consider encoding current page data that you’re editing into the URL, and back buttons don’t return to root and just strip query params. Often a very frustrating experience.
Often, “go back to what I was doing before” is what I actually want, not “go strictly to the previous state in the URL bar.”
Sure, plenty of people mess that up too, but the reality is that controlling the navigation stack can help you build more useful designs.
Isn't the best way to solve the back button question to not be so damned complicated and just make certain that only things which you want to go back to ends up in the history? The whole framing of the problem just screams "structure your thing better and it won't be a problem to solve".
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 you could, or even just a vanilla DOM event handler on a button click.
The problem is that you cannot introspect the browser’s history with the history API. So you have to hack your way around that if you want the “go back in history if possible, otherwise navigate to fallback url” behavior. Which I guess is easier if you’re in a react SPA. Or if you’re fully a MPA and can just check document.referrer
There’s a brand new Navigation API that does let you introspect history entries from the same origin, which perfectly addresses the issue.
I wrote a polyfill in order to take advantage of the navigation API for this exact problem: https://github.com/kcrwfrd/navigation-ponyfill
Came to ask this myself. Oddly enough, I think they’ve kind of slipped under everyone’s radar.
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.
> Some languages just feel incredibly natural and frictionless for certain things, and nobody has really nailed UIs yet.
Emphatically yes. If you look at books written about the problem in the early 90s[1], they are still applicable today.
> The current solutions, although I find it hard to describe precisely, are always tantalizingly lacking in one way or another.
The best analysis of this I have seen so far is in Chatty's Programs = Data + Algorithms + Architecture: consequences for interactive software engineering [2]. It's a bit hard to get through, but absolutely worth it.
As a short summary, the problem is architectural, or more specifically linguistic/architectural mismatch: the architecture our "general purpose" programming languages induces, which is the call/return architectural style, does not match the architecture required for user interfaces, but rather conflicts with that style.
I also wrote about it in Can Programmers Escape the Gentle Tyranny of call/return?.
My current approach is to first build a programming language that can easily express alternative architectural styles: Objective-Smalltalk [4].
With that I am now working an a UI framework I call interscript, including HTMXNative and other goodies.
It seems to be working out...
[1] For example, Languages for developing user interfaces by Myers et al https://api.taylorfrancis.com/content/books/mono/download?id...
[2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
[3] https://2020.programming-conference.org/details/salon-2020-p...
[4] https://objective.st
As an engineer, it's easy to look at every problem and think to yourself: "There is a perfect solution for this, we just haven't found it yet."
Yet, as the years go by, I find myself accepting a less idealistic answer: Maybe there isn't. Maybe the problem space is just so complex that no one (humanly feasible) general solution exists for all forms of it. If there's one thing that this is true for, UI is probably it.
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.
I like TEA but don't fully grasp how it scales for apps that may have reusable components or sufficiently complex pages. Is there an agreed-upon way(s) to deal with this? I know state is a big NO so it seems a bit at odds, but also does this essentially mean all Elm apps are just a global Redux and React app with no effects? Curious about more details to what you enjoy and how you like to work in Elm. Links also perfectly fine too.
Not the person you were asking, but I shall share my experienc..
>how it scales for apps that may have reusable components or sufficiently complex
It is a lot of boilerplate, but it is mechanical, straightforward changes. I think it is entirely possible to automate it (not even using LLM).
> state..
I have used ELM ports to interact with JS and localstorage/indexeddb.
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.
Flutter, SwiftUI, Jetpack Compose: a whole lot of other platforms have been implementing React as their UI framework
No they are implementing Functional Reactive Programming, it isn't the same thing, even though common folks would say React.
https://wiki.haskell.org/Functional_Reactive_Programming
I wouldn't say Compose UI/Flutter/SwiftUI are "implementing React", but if your point is that other platforms have better solutions than JSX (plus all the bloat React adds to applications), I absolutely agree.
If it is so intuitive, why then does basically every React app contain performance bugs?
What does being intuitive have to do with software optimization? You can write poorly performing code for anything. Most people never touch profilers.
The same kind of bugs don’t happen in Vue because the framework handles them for you.
Maybe fair maybe not, but definitely unrelated to how intuitive it is.
I'd argue that it's directly related. If intuitive use of a library/framework/pattern commonly causes issues, you have to keep forcing yourself to do use non-intuitive approaches to prevent them.
GOTO is also pretty intuitive.
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.
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 basically skipped React. I went from jquery to Vue3, and use even that sparingly. When React got really popular, I read the docs and played with it, but I prefer the Vue model where the component runs once and sets up its reactive tree. Why would you want to recreate the component's inner functions every time it renders? And manually declare dependencies, when every other framework is doing them automatically?
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 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.
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
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 only migrated projects from React to something more sensible. I am not sure why people like it. Maybe it is good for bigger teams. Astro with OpenProps is what is super simple, fast to develop and maps naturally to the business functionality I work on most of the time.
I have no idea why people go for these super heavy frameworks. Maybe there are some aspects I am not considering that justifies React.
I can see where the arguments for React's alternatives like Preact, Vue, Svelte, Solid, etc. come from. All of them are better than React at least in one aspect and React's dominance is mostly due to inertia: Developers (and now LLMs) know it better and the ecosystem is richer.
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.
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.
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.
It’s the best of the options that I’ve tried. So I guess I like it.
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.
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.
Open source tech is a marketplace of ideas. If you have a more perfect alternative then it will prevail.
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.
I am wondering how much the "perfect alternative then it will prevail" still holds given the amount of money spent on marketing by infrastructure companies, for example Vercel that have an interest in promoting Next.
That’s a fair take. What happened to google’s angular ? Facebook is also historically invested in php, why wasn’t php just good enough? Facebook also had flow, Microsoft typescript won.
Sure these companies have influence, but it’s not all or nothing.
I just don’t buy the whole mass hysteria and funding being responsible for reacts prevalence.
“Frontend purity” reeks of the tired, “lazy unskilled engineers should write software in C and assembly on 16kb memory like the old days”
Reacts success is not from being an air tight optimized and perfect abstraction, it succeeds because it has a scalable abstractions which have relatively good ROI when you learn it even with its warts.
> Open source tech is a marketplace of ideas. If you have a more perfect alternative then it will prevail.
React has had Facebook promoting it for over a decade… it's hardly a marketplace of ideas… more "Facebook is using this so it must be good enough for us"
No particularly strong feelings either way. It suffers from the same issue as all the other JS frontend - it evolved along with browsers over years and was constrained by whatever browsers happened to support rather than from a cohesive design
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.
I used to love react of old with redux/flux and little to no hooks and weird side effects. It had super sound software design at the cost of being bulky.
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.
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 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.
"Does Anybody Actually Like ____" is such HN engagement bait
React, too. React or Electron in a submission title is like free money here, like throwing pellets into a koi pond.
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.
A post about React?! Nature is healing
> 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.
why is RSC not considered react? it is designed by core React team, and heavily recommended by core React team. and needs deep support from react.
Subjective depending on who you ask, but for me RSC is not really representative of React usage. (I believe) the vast majority of React apps (and the vast majority of dev experience in React) are front end only. I have been writing React in some form for 8+ years, but never touched RSC.
It is, especially in big corps doing MACH with SaaS products, deploying into Vercel.
Doesn’t mean you have to use it.
> Next.js isn’t React.
But it seems becoming. Many React maintainers are on Vercel's payroll and Next.js is also defining where React is going.
this a million times. the next.js intermixing of backend / frontend code is a security nightmare.
I love it. Easy to write and understand
I actually like React's virtual DOM approach. It might not be the fastest possible solution, not the most elegant syntax, not particularly concise. but I can at least understand what it does and how data flows. I learned the hard way that with reactive programming (whether you call it observables, runes, signals, whatever) you can lose that understanding and it's a huge pain when that happens.
No Server Components though, they are the pinnacle of too clever to be a good idea.
I like scripting so I like having a <div id=root> and then do everything in JS. No need for Typescript or React, innerHTML=`...` works fine. For a serious project, React and Typescript make sense but it can still be used wrong. The default Laravel project that's generated when choosing React looks really bad to me. Too many files and comments and tests. It's over-engineered.
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.
vue is adding a vdom less route. but not going away from it anytime soon
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/
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.
It's called Stockholm syndrome...
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.
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.
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.
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 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.
It depends on application complexity. I will hit a threshold. Below: HTML + CSS + targeted JS. Above: React + npm + webpack + typescript.
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.
This is my favourite quote (and I write this as someone with no experience with HTML frameworks):
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.
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.
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?
Would be silly to rate your stack without knowing more about what it is and its constraint.
If I had to judge it based on this alone post alone:
Great, seems like a straight forward stack. Would happily work on it.
Only criticism, to get all the ergonomics out of alpine, you sometimes have to lax some CSP or use the CSP build. Not necessarily a deal breaker, it is what it is.
I think this is a very sane stack.
Will probably become a hassle when going planet-scale (tm), but I think for most use cases this should be fine.
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.
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.
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
Hat tip to the article's subtitle:
I appreciate the honesty up front!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.
"Probably the wrong framework for most use-cases" is not that much of a recommendation.
Both Scala, Ocaml and some variant of Ocaml like PureScript target Javascript and even have library that wraps React. Worth to explore with AI.
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-...
Yes, and I won't be convinced otherwise until there is an objectively better solution.
I do like React. It's still my choice even after trying other tools (including HTMX).
I prefer HTML over JSX, and AlpineJS is good enough. Sometimes it's nice to have a few web components.
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.
Why does the blog prompts me to install it as an app?
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.
React is probably the most successful framework people constantly complain about.
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.
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 using by using Re-frame. It's a clever loophole to use Lisp while meeting requirements, making everyone happy.
Its bloat. You can do shadow dom and web components in modern native JS.
State library is prob all you need now.
> State library is prob all you need now.
Hopefully if the signals standard proposal (TC39) gets up we may not even need state libraries soon.
Neat! Had not heard of this, lets goooo!
Now if they could just make Typescript semantics native.
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’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.
React removed the joy of web development from me. Datastar brought it back.
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.
Some people do, some people don't.
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 do actively like it. I even prefer the functional style better then class based one.
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 lived there idea of hooks when they were introduced.
But they’ve honestly not worked out.
React works have been a lot better if the React team has figured out what useEffect was supposed to be right at the beginning, or at least when they changed what it was supposed to be used for they documented that clearly instead of gaslighting devs into believing nothing has changed.
Also, hooks aren’t a thing. Each hook is its own API and concept. Grouping them under the umbrella term “hooks” gave the wrong impression that it was a single concept, but there’s No conceptual similarity between ushered, useState or useEffect. The only similarity are the restrictions on their use and nomenclature.
In every single project I worked on using Next.js as a kind of full stack framework, eventually I need to do something on the FE as well, and end up debugging a spaghetti of useSomething() until I figure out where to actually implement what I need.
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
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 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.
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)
React is great, and really the only good thing Meta has ever done.
No
Not really.
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 :]
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.
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.
I'm really sorry to say this, but I actually love React
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.
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.