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. But 2024 was a year of coming to terms with reality.
The past several years have been an exploration to discover the unknown. We entered this year excited. It was finally time for these advancements to find refinement. They have. But one thing is abundantly clear:
The quest for simplicity hasn't resulted in making web development simpler.
Clearly, some things have become easier to do but the overall picture hasn't simplified. We already knew this. But something changed in 2024 aided in part by pressure from the global economy tightening budgets and keeping solutions on the safe path. I think it has finally been acknowledged there are no silver bullets. Difficult problems are difficult to solve.
It isn't just that the tools are complicated but the problems. It has taken hitting obstacles around every corner while going back to basics to only re-invent the wheel to return to that fundamental place.
It is a sobering thought but it gives me hope in 2025 that we can take some time and re-evaluate. And that starts with reflecting on 2024.
The Promise of the Server
Making things "server-first" has been the narrative over the last 5 years in the front end. This is not a new concept, the web was born on the server, but after a decade of client-centric single-page apps, it was clear the pendulum had swung too far. Especially for page load-sensitive websites, which did not benefit as much from increased interactivity.
The pandemic only amplified this with both the rise of online shopping habits and the influx of capital driven by low interest rates. The result is we got a bunch of new server-first meta-frameworks like SvelteKit, Astro, Remix, SolidStart, Qwik, Fresh, and Analog along with significant upgrades to existing ones like Next and Nuxt.
The last couple of years have seen SPA-influenced isomorphic (same code runs differently on client/server) approaches up against MPA-influenced split-execution (Islands/Server Components) approaches in a search to find a universal solution for all. It is an exercise of two opposites trying to approach each other in the middle. This has resulted in amazing developments in routing like Next App Router and View Transitions Routing, as well as technology like Server Functions, Optimistic Updates, Server Islands, and Single-Flight Mutations. But even so, the gap remains larger than anyone imagined.
When you assemble all these features, things are not so simple anymore. And it is arguable whether we are even solving the problems we set out to:
It has been incredibly difficult to measure success. We've seen benchmark fails:
We've seen performance attributed to new technologies when the root cause was elsewhere:
Not wanting to wade through this mess, has led the conversation back to more traditional server approaches. Ones that exist outside of "SSR". Ones where you aren't trying to run a client JavaScript framework on a server. This has always been a great choice for projects where it makes sense. But it is also uninteresting.
We wouldn't be where we are if there wasn't a need to improve upon what came before. And that can take a lot of trial and error. The simplest tool for the job is the correct answer, but when the problems cease being simple you will want options that scale with you.
If 2021/22 was a reset to a simpler base, a return to our beginnings on the server, 2024 reminded us that simple doesn't always cut it.
Compilation to the Rescue
Compilation is an ever-present aspect of JavaScript development. Whenever we've hit an obstacle, whether it be browser feature support, clunky syntax, or the ability to address the language's shortcomings we build a compiler for that.
It is so ubiquitous at this point Standards committees are considering going that direction to introduce new features. Compilation and through extension bundling is the core of how modern JavaScript applications are created. It is also the root of most complexity in JavaScript tooling.
The benefits are immense. Types, Linting, Treeshaking, Code Splitting, Minification, Isomorphism, Macros, DSLs, Monolithic Authoring/Distributed Deployment. Every advancement in the past 15 years in this field has been built on this foundation. There is no alternative that could even remotely be considered adequate by comparison. Call it unfortunate. Call it a limitation of the JavaScript language. Call it necessary complexity. But to deny this is futile.
However, if we want to understand complexity it is at least important to understand its source. The most interesting development in 2024, thanks largely to both the release of the React Compiler and Svelte 5 Runes is how muddled the conversation has gotten.
On one side we have the React Compiler, an auto-optimizing compiler, that transforms code in a way that reduces unnecessary re-execution without manual intervention. Very similar in principle to the Svelte 3 compiler released back in 2019. And on the other, you have Svelte 5 Runes which brings a syntactual sugar over a fine-grained Signals renderer similar to what SolidJS released back in 2018.
These are two major compiler projects that couldn't be more different that called into question the fundamental nature of both projects. React acknowledging that re-renders do matter enough to optimize around. Svelte traded away its minimal syntax for a more expressive language with increased capability and a better fundamental basis for performance. Ironically, these stances are both exactly opposite of their initial selling point.
And interestingly both choices come at the expense of increased complexity in tooling compared to their existing approaches.
The verdict is still out on whether these will ultimately be good moves for these projects. The common ground is the foundation we build upon continues to get more complicated as we attempt to create solutions to make development easier.
AI and Dev Tools
If compilation and bundling are fundamental, it is clear at this point these are foundational pieces for giving AI the tools it needs to create very dynamic solutions in the future. While we are seeing a bigger impact every year on what these tools are capable of in improving our local developer experience, AI's impact on JavaScript frameworks themselves is still minimal.
Early in the year, we saw Devin make headlines by creating simple apps. Although it did call into question what our expectations are from this technology. Is it simply enough to make something functional or does it need to be good?
In that sense technology like Vercel's v0 has been largely a success at creating prototypes. Maybe that is where the biggest benefit is for now.
MillionJS developer Aiden Bai got our attention again with React Scan which scans your application for performance issues.
While one might argue that re-renders aren't necessarily a sign of a problem or that this exercise of finding re-renders in React is like shooting fish in a barrel, it definitely opened my eyes to the potential of development tooling just around the corner.
If tasks are complicated and core tooling more complex it makes sense that supporting tools rise up to meet that. It is more than the shift left in development. The need is fully integrated across the whole spectrum. While Biome (and previously Rome) set out this goal newer players in the space like VoidZero (from Vue/Vite creator Evan You) show that this foundation is essential for where things go next.
Looking Forward
Server-second
We already have started seeing some of the swing back of the pendulum towards the middle of 2024 with SPA modes in Sveltekit, SolidStart, and Remix. Remix ported back their non-server functionality to React Router. SolidStart's additive approach to Server Functions and Single Flight Mutations laid down the eventual foundations for Tanstack Start a React framework built on the same principles.
We've also seen an increase in local-first/sync engine technology. How that is to manifest itself is still left to be seen, but I expect it to be a continuing trend into 2025.
Slow & Steady Wins the Race
One thing that caught me looking at the results of the JavaScript Survey this year is that in the sea of growing dissatisfaction with our tools some have shown more positivity growth than others. This differs slightly from say Retention(Satisfaction) which is focused on current users of the tool and caters to smaller players (SolidJS and Svelte have sat on the top of that list for years).
They aren't the tools I talk about as much, but when the economy is tight and maintenance a concern, they tend to shine. Both Vue and Angular are frameworks I'd have my eye on this next year. Not because I expect to be blown away by some innovation here, but because these tools go the extra mile in making developers happy. Sometimes the best tool isn't the "best" tool.
Signal Growing Pains
It is no secret that pretty much all non-React frameworks run off Signals now. But some time has passed and developers are starting to understand the depths of tradeoffs present. While it is this author's biased opinion these are minor issues, I do expect people to come to a new appreciation for React. It's an appreciation they should have probably always had and that doesn't excuse any of React's flaws. But everything is a series of tradeoffs and you can only appreciate the choice you've made once you understand both sides.
That being said Signals are still evolving. The collective experience in this area has grown immensely the past few years. I expect the collective result of smaller innovations over the next year will showcase the unique value prospect of this approach in ways we've never seen.
Web Components
...Just kidding.
Conclusion
Unlike previous years I'm not predicting some big technology leap in the next 12 months. I don't know if the community at large would be that accepting. I've watched the conversation devolve from whether Resumability makes sense vs Partial Hydration to who has the best templating syntax again. This is a part of the cycle that lends to reflection and innovation on the horizon. But not today. And that's okay.
We have a lot of complexity to catch up with. A lot of hard decisions to make on what technology is worth our investment and effort. The raw capabilities for the next generation of solutions exist now but I'm not sure we've seen the right combination of pieces yet in a consumable form. But at least we are beginning to acknowledge that in our quest for simplicity, we set ourselves on a path to add back that complexity in new ways.
A single solution hasn't shown itself. HTMX is not going to take over the world, but it is a great option to have. React isn't necessarily any more complex at doing things than other solutions. Async and Client/Server interaction by extension is a complex thing. Compilers can't solve all issues. But they can do a lot:
We live in a world full of complexity and that doesn't appear to be changing any time soon. So 2025 feels like a good time to hunker down and get stuff done.
And, for those looking for the next great thing? Look around. There are plenty of interesting problems to solve. Between you and me, this is the type of environment I thrive in.
Top comments (29)
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.
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
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
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)
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.
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...