I admit I wasn't sure I'd be writing this article this year. It's easy to write articles that excite people about the potential of new technology. ...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for the article. It was interesting.
I understand you're somewhat of a public figure and you probably mind what you say and how you say it, but I don't have a problem saying it how I see it: React is dead. Sure, there are millions of applications written in React, and those require maintenance, but what's beyond my comprehension is starting new projects in React. The React compiler adds so little that is just not worth it. How much time was it invested in its development? For these results? Just archive the project.
The fact is that both React and Angular are among the worst performers out there and people should just stop the madness. I chose Svelte, and I agree that SolidJS is also excellent. I just happen to like Svelte's syntax better.
So, I do understand that there might be a thing or so that is commendable in React (I can't think of one right now, though), but in practical terms, I think React should just give way to the next best thing.
How did Angular get pulled into this? Angular has already done what Vue wants to do with Vapor by using signals. Event replay is one of the things QwikJS wanted to bring to the public. Server side and partial rerendering per route. Templating on .html files gives you a syntax that's cleaner than DSL files like .astro and .svelte. I don't understand what you're calling out here.
I could probably agree with you if you had any details to share.
What version of Angular uses signals? I would like to locate it in the benchmarks. Last I saw it, it was as awful as React.
I suppose the only metric you're using to determine if something is bad or good is krausest? Signals have been in Angular since 16, the current version is 19. Async signals via resources are experimental. zone.js is deprecated. rxjs is de-emphasized. Angular and Wiz are merging as a single framework incrementally. (Meaning it's implementing everything Qwik does.)
Does that mean it can get all greens on krausest? No. But Angular powers Google search now. Signals were merged from Angular to Wiz for YouTube for a 30% performance improvement.
There is no context API or virtual DOM, which are the source of most of the frustration around React, not krausest benchmarks. There is just dependency injection and templating.
So I think it'd be better to dig deeper into why you don't like React. Can't say I agree or disagree with anything you're saying because you're just saying "react bad." I have a bias towards "react bad" but I could also back it up.
Well, over a dozen other UI framework/libraries get a lot more greens on krausest. Just because Youtube runs 30% faster now and Google Search uses something (Angular), makes that something king? No, would be my answer.
But let's see a different benchmark: github.com/transitive-bullshit/ts-...
Here's the chart, with Angular signals being second-to-last in the race:
On the bright side, SolidJS and Svelte lead the race.
In light of this appalling results by Angular, what would be the argument for choosing Angular over SolidJS or Svelte, which so happen to get most greens on krausest as well?
Finally, to answer your question: React is slow and has a high learning curve. When compared to Svelte, Svelte code base is between 25 and 35% smaller (I have done a rough estimation, find it in my blog, so this not a fact taken out of thin air), and Svelte's learning curve is much flatter.
If there were no other options available, I guess React would be an appealing choice. The reality, however, is that there ARE choices, much, much better choices. Does this answer your question?
Why is this so extremist and angry? Creating an all or nothing, if you say a positive thing about A, then you are my enemy? This is very Reddit politics. Let's take a deep breath. I see this a lot in the Svelte community, which is why I never got into it. I don't know how it got such an angry internet user fan base. And I feel bad that something well done is represented in this way.
First, I've been working with React and NextJS for about 8 years. (Yes, Next has been around that long.) Prior to that I was all about PHP and shipping no JavaScript. I'm new to Angular, learning it out of interest of new features and it being very stable; we'll get back to that. Second, performance benchmarks aren't everything. Signals aren't everything. I am not arguing with you, this is not a battle. I'm trying very hard to agree with you. You can throw graphs at me, but it's just going to raise more questions about what's actually being measured. What, in detail, makes you assign so much value to one benchmark over another? Why is this one the end all be all truth? Are you just looking for a confirmation bias? Those are rhetorical questions that I don't believe have any answer.
Instead, let's make a better argument.
Why I don't like React anymore:
Why I'm currently enjoying Angular:
As an additional note, it is not fair to say that with Angular you have everything you need out of the box and you don't need to install dependencies. Because Angular is not a UI library/meta-framework pairing. So you have to compare Angular not to React, but frameworks like Next and TanStack Start. Angular also uses many individual packages. So there is @angular/router and @angular/forms. TanStack has the framework Start, Router, and Forms.
This is why I say TanStack as a suite is more of a framework than Start itself. I think we need to raise the bar on what we call "framework" as JS developers.
I'm not angry at all. I simply state the facts. The problem is that the facts are too ugly, perhaps? I simply find hard to believe that there are so many users that choose to be blind to these facts. I'm not anyone's enemy. I just want you (royal You) to argue with the same rationale and providing facts as well. It is very difficult to argue about anything when one of the parties does not provide facts and does not follow the rules of formal logic.
All right, with that out of the way, allow me some time to read this article you just posted. 😄
Ok, I have read most of what you posted.
I feel compelled to answer this: Because I'm a scientist. We believe in what can be measured. Anything else is subjective. You cannot build airplanes based on subjective things. Things that work work because they rely on objective measurable things. It is as simple as that. Are the benchmarks perfect? Probably not, but they are far, far better than mere opinions and feelings and personal preferences, and even imperfect as they might be, they disclose important objective information.
Great, I think I have fully explained my reasoning. We can recap:
Ok, after the recap, we can say that:
This "fact" is not a universal fact. I'm a back-end developer of "those days", and my preferred language is C#. I fit your bill perfectly. My case was the other way around: I came to the team to find an absolute React mess made by 2 dozen contractors. Because I am the team leader, I had no choice but to:
This is how I learned about Svelte. I researched the options. Now we are migrating everything to Svelte with the assistance of
single-spa. So I don't think of myself as a front-end fanboy. I weighted my options and Svelte came on top (Svelte v4, so no signals).As the team leader, I am continually pushed to learn more about the front end: TypeScript, how to type fetch responses, a better configuration system than outdated .env files, the creation of data table components, etc.
I think you need to be more open minded here. I’ve used a lot of frameworks and always ran away from react but i’m always willing to give second chances - and I have recently and been pleasantly surprised with the progress of the framework. One thing I’ve done was build a website that actually renders a 3D scene at first paint (and no I’m not using web workers or wasm), plain react but with careful compression of meshes, optimization of images and audio sizes, preloading and caching assets and all that jazz… I also built that same site in plain JS using webpack as a bundler… and built it using Astro with qwik and svelte. Finally I built it with next JS canary with the react compiler and PPR. The NextJS version has a near perfect lighthouse score on desktop, with 99 performance (it’s slightly lower on mobile obviously but depends on the phone) and 100 on accessibility, seo… that’s 1% less than what I was getting in Astro and the scene has higher quality, I’m using react three fiber instead of plain threeJS (a luxury of sorts) and I’m also loading “motion” and a million other things… but I do lazy loading (as I would in plain vanilla) and I also fetch with high priority above the fold…
TLDR: react is here to stay and I’d say that the framework is going to matter less and less in the future as they’re all moving in a direction of static and server rendering, so you should really be picking the framework with greatest financial backing and more usability. It’s going to increase your productivity and you’ll deliver safer products and more maintainable ones. If you want to experiment and challenge your self build libraries for those frameworks. Try everything and if it’s not good enough stop then try again later. You’ll learn a lot more than by avoiding things.
as a last note so people don’t think I’m a react fanatic. I’ve avoided frontend dev with a passion until I realized I gain nothing from doing that. I’m the type of person that has spent days building a server in ASM because id already done it in C, C++, Rust, Zig, Julia, Lua, Nim, Python… I love driving myself to madness with lower level programming.
dont let yourself get lost in the world of “blazingly fast”. Be blazingly productive and blazingly humble. It’s better
I am open-minded. Why do you think I'm not? Maybe it is because you just read my initial comment? Perhaps you'll see a bit better from where I come if you read the responses I have given to Ethan's comments.
A quick summary: Both Angular and React are objectively bad choices today. If I can go with Svelte because it is objectively superior, I will go (and went, actually) for it. To me, this is being open-minded. Is it not?
This statement from you has no supporting arguments or any logical path that I can follow. Svelte code is more maintainable than React code. This is an observable and measurable fact. It has nothing to do with the company backing it, and everything to do with the nature of both React and Svelte.
Yes, that is exactly what I have done. Is that a bad thing? Is a framework/library a good one only when other people do the libraries for you? Is it a sin or frowned upon somehow? To me, this fact has no consequence. After all, I LOVE programming.
This is a response to Ethan Glover, who have chosen to block me out of fear of what I have to say. Ethan:
How are facts a "rant"? Perhaps your ego could not take the reality of what is observed and measured and you preferred to live in ignorance? Perhaps you weren't prepared to read what I wrote? I'm open to discussion so long the discussion is based on facts and logical reasoning. Are you capable of arguing with facts and reason? If yes, by all means, let's argue.
If you feel up to the challenge, unblock me and let's have a rational discourse on the topic.
You’re right I do admit I only read your main post. Also I did not mean to sound paternalistic or aggressive, if I did sound like that it wasn’t my attention, just a discussion!
What you said makes sense, the comment to me is good, was glad to read it. The bit about svelte and react’s differences in maintainability, I can tell you exactly what I meant:
Svelte is fantastic, I love how close to vanilla it is, same reason why I do like Solid. Qwik is a masterpiece but it’s not like rust, you fight a compiler that is nowhere near as helpful.
My point to maintainability - less lines of code is better. But the most important, the more people can work with your code the more maintainable it is. And fact is react is more widely used.
Hello! Yes!, the less lines of code, the better for sure! It is one of the measurable attributes I assign to the definition of "code maintainability". We fully agree. Thanks also for defining your frame of reference. Indeed, React's code is more maintainable than Vanilla TS under it.
Perhaps I'm stating the obvious, but clarity is more important than brevity. Some engineers elevate brevity to such a high status that they sacrifice clarity, which usually ends up sacrificing time.
I've been in situations where I had to try to decipher too-clever code where the dev wrote like they were trying to win the JavaScript 5k contest (anyone here old enough to remember that?). If I have to spend 3 minutes deciphering things like extremely abbreviated names and arcane use of bitwise operators vs. spending 1 minute reading 3 extra lines of self-explanatory code, I'll gladly take the 3 extra lines.
Agreed. The measure is not to be taken to the extreme. Generally speaking, if you have less code to maintain, it is easier to maintain. It should not be taken further for the purposes of measuring "code maintainability". Common sense to be applied. 😄
Yeah, as mentioned, obvious to some 😊. I get the impression there are a fair number of junior devs here, so I just want to encourage clarity over brevity.
I would just avoid him. He's just here to rant about Svelte. I don't know what happened to that community. The vegans of JS.
You make great points. React is a nice go-to when you want to do some very heavy UI. I don't know how it's possible to do anything less than 100 on Lighthouse with Astro. But lighthouse isn't a great measurement to begin with imo. The numbers you get from field data are always wildly better.
But the problem with React is maintenance and scale. While it's very easy to get a complex project going, it will fall apart under bad lifecyle management and state management. As long as there's more than one developer working on it, it has no chance. I've done enough contracts now to know this. Nobody really knows how React works... everyone knows the rules... but React itself doesn't work. Why are all state managers using "external state"? Why can React never be reactive?
I think these are the main gripes that are the real core of complaints about it. Nothing about whether or not you can do a fancy thing really fast. That's great, and honestly you should be able to do that with anything. It all comes down to what you know best.
So I think those arguments are void. What are the real technical differences that drag react down? Reactivity, and lifecycle management.
I think a reality in 2025 will be: "please let us cacthup before any new feature 😭"
I mean we all are exicited by resumability, Rolldown or wathever, but really for real day job on real large codebase, most of us have yet to test SSR: bsky.app/profile/tannerlinsley.com...
Migrating those big production apps takes time, but you do get different insights from what you get on test or greenfield projects.
So please, if you wanna be cool in 2025: be the one who brings easy upgrades or migrations. Else we'll just stay on React CSR forever. Svelte 5 migration script has quite the heads up here. Just sayin'…
I really love to read articles like these, thank you a lot for taking the time and effort to share! ❤️
Dude, just amazing,
When I first show title, I was "dude, once again this repetitive post of list of frameworks with bunch of advantages ", but nah it was something new, or I'm seeing this type of content first time with real facts not by some you tubers saying overall advantages, they say what happens on upper layer like performance but what happens really inwards nobody says that
Thanks for this
It helps being a framework author myself (SolidJS) and being very well versed in the work most JavaScript Frameworks are doing. This type of content isn't always the most accessible but if you like it you should check out some of my other articles. Thanks for reading.
Definitely do
The cyclical nature of technological evolution is evident in the realm of front-end development. Initially, we began with a modest toolkit comprising basic HTML, CSS, and JavaScript, relying on server-side rendering (SSR) technologies like JSP and ASPX. As the field progressed, we witnessed an exponential growth in complexity and tooling.
The front-end landscape expanded to encompass a myriad of new elements: compilers, Node.js integration, pre-processors, templating engines, micro frontends, and headless architectures. Package managers evolved from Bower to NPM, bringing with them an ever-expanding universe of JavaScript libraries and, admittedly, some superfluous packages.
We observed a significant shift towards client-side rendering (CSR) with the rise of frameworks like Angular, React, and Vue.js, which currently dominate the industry. However, the pendulum is now swinging back towards server-side rendering, driven by the pursuit of enhanced performance and optimization.
This oscillation between SSR and CSR reflects a broader pattern of technological refinement. As developers continue to seek the perfect balance between user experience, performance, and maintainability, we may find ourselves revisiting and reimagining familiar concepts.
It's conceivable that in the near future, we might see a resurgence of SSR techniques, potentially integrating modern approaches with traditional server-side technologies like JSP and ASPX. This hybrid approach could leverage the strengths of both paradigms, offering a more nuanced solution to the challenges of web development.
As we navigate this evolving landscape, it's crucial to recognize that innovation often involves reexamining and repurposing existing ideas in light of new contexts and capabilities. The cyclical nature of front-end development serves as a reminder that progress is rarely linear, but rather a continuous process of adaptation and refinement.
Well written and thoughtful. The point on compilers hits hard on the trend that was "no build step." Which I never understood. I don't know why JavaScript has to be the only language on the planet that has no build step. It only benefits.
I don't mind the build step. It doesn't matter - with Vite, I don't even notice it's happening.
but that's a fairly odd argument 😄
how many of these scripting languages require a build step: JavaScript, Typescript, Python, Ruby, PHP, Perl, Lua, Bash?
the correct answer is 2 😉
scripting languages generally don't require a build step - that's the reason why scripting languages are even a thing in the first place, you trade off computational efficiency for developer efficiency.
but JS hasn't been a scripting language in many, many years. it isn't even one programming language, it's more like a meta programming language with many, many subtle variations, and it has been, for a very long time.
so I can kind of see the point that JS sticks out.
but also, it doesn't really matter anymore, not since tools like Vite or Deno - the experience simply isn't significantly different from using a scripting language, because things compile and update faster than you can ALT-TAB and press refresh. (assuming you don't have HMR, which makes updates practically real time haha)
Such a lot of strong opinions in the article itself (which is amazing) and even more in the comments 😅 Thanks for this insightful read.
The most important thing IMO (another one) is
This is a such a well-written articles that consider multiple perspectives in a very impartial tone. I love that you acknowledge the power and shortcomings of signal-based reactivity too.
As I work more with Solidjs, I have also started to encounter these trade-offs too, mostly with DX and not be able to destructure objects easily, and have come to quite appreciate React's given simplicity due to "re-running everything". Still it's a good experience learning other frameworks.
And compilers are getting so awesome too. Hope that the Svelte compiler can bring the syntactic sugar to other parts of universal reactivity
Cut out the middleman. Use MPA and progressively enhance with html-form and web components. If you have a highly dynamic page then use a small front end lib for it, like vanjs, Signals, Svelte, etc. Use service workers to make it work offline, if needed. And make it a PWA while you're at it. That makes for great DX and UX.
The "server first" trend is something I'm old enough to have seen switch back and forth several times in the way pendulum trends typically do. I strongly suspect it's over-corrected and due for a reversal soon (if the growth of "hydration" isn't already signalling something like this). At the end of the day, the systems engineer in me shudders to think of the wasted compute cycles just sitting idle on a billion user devices when some small set of servers are driving their hamsters crazy with the time and energy needed to custom-render responses for every corresponding frontend request and the corresponding state associations...
I guess this explains why browsers are the biggest resource hogs in tech today yet still don't work quite right.