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.
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
Legend!
I really love to read articles like these, thank you a lot for taking the time and effort to share! ❤️
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'…
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
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)
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
Great article as always! And if anybody's curious here's a link to the chart Ryan mentioned in this year's State of JS survey.
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...
Sorry for off-top, I was looking for a way to communicate to you @ryansolid, just wanted to discuss my idea for a framework since it is very similar to SolidJS, but I'm not sure if I even should continue with it further. Sorry again.
I guess this explains why browsers are the biggest resource hogs in tech today yet still don't work quite right.
In 2025, we can and should simplify Web development!