react
The front-end choice is made, and it is not my favourite

Between the summer of 2023 and the spring of 2024 I spent a week each with three front-end frameworks: Vue, Svelte and Solid. I came out of it with a clear favourite. Svelte, with SvelteKit, was the one that fit how I think as a backend developer - server first, form actions that are just request handlers, a build that refuses to leak a secret, scoped styles and transitions for someone who would rather not write CSS. I wrote that the next project I started from nothing would probably be SvelteKit.
This month I am starting new projects from nothing, and none of them are SvelteKit. They are React, and where there is a server, Next.js. For web applications, the decision is made, and I want to write down why, because the 2024 version of me would not have predicted it, and I have not stopped liking Svelte.
What changed is who writes the code
In 2024 the question was which framework I would enjoy writing. Most of the front-end code in my projects is no longer written by me. It is written by a coding assistant - Claude Code, Codex, Cursor, depending on the day and the task - and reviewed, corrected and steered by me.
That changes what "the best framework for me" means. The framework that produces the best results is now the one the assistant is most fluent in, rather than the one whose syntax I find most pleasant, because fluency decides how often the first attempt is right, how idiomatic it is, and how much of my time goes into correcting it rather than into the parts of the system I actually care about.
And in my experience, the assistants are most fluent in React, by a distance.
The numbers behind the fluency
The 2025 Stack Overflow Developer Survey asked which web frameworks people used in the past year. Among all respondents:
- React: 44.7%
- Next.js: 20.8%
- Angular: 18.2%
- Vue.js: 17.6%
- Svelte: 7.2%
Among professional developers, React is at 46.9% and Next.js at 21.5%. Svelte is at 6.9%. Solid is further down the list. Only Node.js, which is a runtime rather than a framework, is used more than React.
Those are percentages of survey respondents, not lines of code, but they point in the same direction as everything else I can see. More React has been written than anything else in front-end development, more questions have been asked and answered about it, more open-source components, examples, tutorials and production codebases exist for it. That is the material the models learn from, and the gap shows. React code comes out idiomatic. Svelte code, more often than I would like, comes out as Svelte 4 syntax in a Svelte 5 project, because the runes arrived in October 2024 and most of the Svelte on the internet is older than that.
The same survey found that 84% of respondents are using or planning to use AI tools in their development process, and the most common frustration, cited by 66%, is "AI solutions that are almost right, but not quite". Almost-right is the cost I am trying to minimise. It is lowest where the model has seen the most examples, and for front-end code that is React.
The ecosystem is the other half
Fluency alone would be a reason for today. The ecosystem is a reason that will outlast it.
For almost anything a web application needs, the React answer exists, is maintained, and is usually the reference implementation. Headless components with accessibility handled, from Radix and its descendants. shadcn/ui, which is not a dependency but a set of components copied into your project, which suits an assistant well because the code is right there to read and change. TanStack Query for server state, React Hook Form and Zod for forms, charting, tables, drag and drop, rich-text editors, maps. Every payment, authentication and analytics provider I am likely to integrate ships a React SDK first, and sometimes only that.
In 2024 I listed the small ecosystem as the first thing that was bad about Svelte, and said that for some needs there was no choice and you wrapped a plain JavaScript library yourself. That is still true, and with an assistant doing the wrapping it is less painful than it was. But it is still work that would not exist in React, and it is work in the one place where the assistant is least reliable.
There is also mobile. React Native with Expo means the knowledge, the patterns and a fair amount of the code carry over from the web application to an app, and the assistant's fluency carries over with them.
Next.js caught up with what I liked
Part of why this is easier to accept than it would have been in 2024 is that the React side has moved towards the things that won me over in SvelteKit.
Server Components and Server Actions mean the default place for data and secrets
is the server, which is what I liked about SvelteKit's load functions and form
actions. A form can post to a server function without a hand-written API route in
between. Next.js 16, in October, made Turbopack the default for development and
production builds, so the webpack-era pause after every save that I complained
about in 2023 is gone from Next.js too.
And React Compiler reached 1.0 the same month, which memoises automatically. In
the Vue article I said most of the React bugs I had written were dependency
arrays being wrong; the compiler removes a large share of the places I would
have written one.
It is not all better. The App Router's caching model has been reworked more than once, the boundary between server and client components is still the most common thing I have to explain in review, and December's critical Server Components vulnerability had every App Router project I know of patching in the same week. Next.js is more complicated than SvelteKit, and I do not think anyone who has used both would argue otherwise. But much of that complexity is now the assistant's to handle, and in my experience it handles it better than it handles Svelte.
For someone who avoids CSS
The part of front-end work I disliked most has, to my surprise, become the part I think about least.
The assistant writes the styles now, and it writes them in Tailwind, alongside shadcn/ui components, in React, fluently. My contribution is to say that something looks cramped or that the spacing is inconsistent, and to check the result. Svelte's scoped styles and built-in transitions were a large part of why I liked it, because they made the CSS I had to write smaller and safer. When I am not the one writing it, that advantage mostly goes away.
This is about the current stage of AI
The assistants are better at React today because of what they were trained on, and that will change. Models are improving quickly in every language and framework, and they are getting better at reading documentation and following a project's own conventions rather than falling back on the most common pattern they have seen. A file that tells the assistant "this is Svelte 5, use runes" already helps a great deal. I expect that in a couple of years the gap in fluency between React and Svelte will be much smaller, and possibly not worth deciding on.
What will not change as quickly is the ecosystem. Better models do not create the component library, the SDK or the maintained integration that does not exist. They make it cheaper to write the wrapper yourself, but the libraries, dependencies and the millions of codebases that already exist will still be React, and new ones will keep being started in React because that is where the libraries are. That is a loop that reinforces itself, and it was running long before assistants arrived; they have made it faster.
So my expectation is that React remains the default for web applications for a long time, even after the fluency argument has faded.
Where I landed
Svelte is still my favourite framework. If I were writing every line of a front end by hand, for my own enjoyment, I would still choose it, and I still think SvelteKit is the best-designed full-stack framework of the ones I have used.
But React is now my go-to framework for my projects - React for the front end, and Next.js when the application needs a server. The reasons differ from the ones that decided the 2024 ranking: most of the world's front-end code is written in it, the libraries I need are there first, and at this stage of AI the assistant writing most of the code performs best in it. For someone who cares most about the backend, the database and the deployment, that is the right trade.
I will revisit this when the models are as fluent in Svelte as they are in React, which I expect to happen, though I do not expect it to change the answer as much as I would like.


