Quit React: SolidJS and Svelte are the only logical choices for 2026

If you maintain a React codebase in 2026, you are paying a build tax, a hydration tax and a mental-model tax to solve problems that Quit React: why SolidJS and Svelte are the only logical choices for 2026 is a question every UK frontend lead should be answering out loud. React Server Components, the React Compiler and the Suspense-as-a-router rewrites exist because the original model leaked. SolidJS and Svelte never leaked in the first place. Pick a framework that does less work, and your users, your CI minutes and your on-call rota all get better.

React's 2026 tax is real, and UK teams are already paying it

The Vercel-shaped ecosystem keeps selling React a cure for its own disease. Server Components were meant to stop shipping the world to the browser. The React Compiler was meant to stop you thinking about memoisation. Suspense 2 was meant to stop you juggling loading states. Strip the marketing and each of these is a patch for a model that re-renders on every state change, then asks a compiler to guess which bits to skip.

Look at what UK shops actually ship. Monzo's web app is famously thin because they treat the browser like an afterthought. The BBC News front page has moved large chunks off the client. GOV.UK renders mostly on the server and ships HTML first. None of these teams need a compiler to figure out which div re-rendered. They just don't re-render.

Your weekly bundle audit will tell you the same story. A mid-sized React SPA on Next.js or Remix now ships 120-180KB of framework runtime before a single product byte. SolidJS ships about 7KB. Svelte 5 with runes sits around 10KB gzipped. That delta is not a vanity metric - it is the difference between an interactive page in 800ms on a Vodafone 4G connection in rural Wales, and one that stutters for three seconds while a hydration tree walks the DOM.

SolidJS: fine-grained reactivity without the virtual DOM theatre

SolidJS takes React's mental model - components, props, JSX - and throws away the virtual DOM. State is a set of signals, and only the exact DOM node bound to that signal re-runs. There is no VDOM diff, no memoisation rules to learn, no useMemo dependency arrays to debug at 2am.

This matters for the kind of work UK teams actually do: dense forms, live dashboards, editable tables, GDS-style service patterns. A HMRC-style step-by-step form with 40 fields and conditional branches is brutal in React because every keystroke re-renders the whole tree and you end up reaching for uncontrolled inputs or react-hook-form to escape. In Solid, a signal is just a getter and a setter, and the DOM updates surgically:

import { createSignal } from "solid-js";

export function SalaryStep() {
  const [salary, setSalary] = createSignal(0);
  const tax = () => salary() * 0.2;

  return (
    <>
      <label>Annual salary</label>
      <input
        type="number"
        value={salary()}
        onInput={(e) => setSalary(+e.currentTarget.value)}
      />
      <p>Estimated tax: £{tax().toFixed(2)}</p>
    <>
  );
}

Notice what is missing: no useState, no useMemo, no dependency array, no re-render. The text node bound to tax() updates, and only that text node. The SolidStart meta-framework gives you SSR, file-based routing, server functions and streaming, all using the same fine-grained model. There is no separate "server component" language to learn because the boundary is honest: run this on the server, ship a signal to the client.

The honest tradeoff

The ecosystem is smaller than React's. You won't find a React Native equivalent, and some niche libraries assume React hooks. For most UK product teams - internal tools, fintech dashboards, GDS-pattern public services, B2B SaaS - that tradeoff is a feature. Fewer choices means faster decisions.

Svelte 5: runes, no virtual DOM, and a compiler that does less

Svelte 5's runes model is the same idea as SolidJS, expressed in a syntax that veteran frontend devs already read. A rune is just a directive that tells the compiler where reactivity lives. There is still a compiler - Svelte will always compile your files - but it does far less than React's compiler does now, because there is no virtual DOM to diff against.

SvelteKit is the mature meta-framework here, and it is what makes Svelte a credible replacement for Next.js or Remix today. It does SSR, prerendering, form actions, server-only load functions, and progressive enhancement out of the box. A typical GOV.UK-style service page with a multi-step form looks like this:

<script>
  let salary = $state(0);
  const tax = $derived(salary * 0.2);
</script>

<label>Annual salary</label>
<input type="number" bind:value={salary} />
<p>Estimated tax: £{tax.toFixed(2)}</p>

Two runes, no hooks, no re-render, no memo. The $derived rune is the entire equivalent of Solid's computed, and the compiler emits the surgical DOM update for you. SvelteKit's load functions let you fetch data on the server, hydrate the client with the result, and ship the same code path. There is no second mental model for "server components."

UK adoption is real. The Guardian has shipped Svelte components in production. NHS Digital teams have prototyped service patterns in SvelteKit precisely because the progressive-enhancement story matches GDS guidance. Sky's design system team has blogged about the bundle savings. This is not a toy framework waiting for its moment.

The migration path UK teams should actually use

Do not rewrite. Strangle. React is a perfectly fine target to render into, and both SolidJS and Svelte let you do that.

• Audit first. Use vite-bundle-visualizer or the Realytics Chrome extension. Find the routes where React framework code dominates product code. Those are your targets.
• Pick a leaf route. A settings page, a reporting dashboard, a transactional email builder. Render it as a SvelteKit app or a SolidStart app behind a reverse proxy at /settings. Users never see a flag flip.
• Use islands if you can't. If you must stay inside the existing React shell, SolidJS mounts as a single element via render(() => <App />, document.getElementById('root')). Svelte 5 has a createRoot helper for the same job. Both produce a small island you can grow.
• Migrate the data layer last. Both frameworks speak fetch, GraphQL and tRPC natively. Your API contract does not change. Your Zod schemas do not change. Only the renderer does.
• Measure honestly. Track Time to Interactive, Total Blocking Time and p95 hydration time before and after. Track your CI minutes - SolidStart and SvelteKit builds are typically 30-50% faster because there is less code to transform.

Budget for two sprints per island before you declare victory, and gate each migration on the metrics above, not vibes. UK engineering managers will respect a Lighthouse delta and a CI-minute delta more than a "developer experience" essay.

When React is still the right answer

I am not a zealot. If your entire team has ten years of React muscle memory and your product is a content site with two interactive bits, keep React. If you ship React Native to iOS and Android and the web is a wrapper, keep React. If you are locked into a platform like Retool or a CMS that emits React, keep React. The point is not "React is bad." The point is "React is now a default you chose because someone else chose it for you, and the defaults have moved."

For greenfield work in 2026, the defaults have moved. SolidJS for dense, interactive, signal-heavy product surfaces. SvelteKit for content-led, form-heavy, GDS-pattern service work. Both compile to small, fast, surgical updates, both ship a mature meta-framework, and both make the React Compiler look like a very expensive patch for a hole that was never in the wall.

FAQ

Is SolidJS production-ready for UK enterprise teams in 2026?

Yes. SolidStart is stable, the core library has been at 1.x for years, and the team ships predictable minor releases. Major UK fintechs and design system teams have it in production. The smaller ecosystem is a real consideration, but for most product teams it is a feature, not a bug.

Will Svelte 5 break my existing Svelte 3 or 4 code?

Mostly no. The runes syntax is opt-in per file. Legacy let-based reactivity still works in Svelte 5, so you can migrate component by component. The Svelte team provides a codemod that flags files that should move to runes, and it is non-destructive.

Do SolidJS and Svelte both support Server Components or SSR streaming?

Yes. SolidStart supports SSR, streaming, server functions and resumability. SvelteKit supports SSR, prerendering, form actions, server-only load functions and streaming. Neither framework needs a separate "server component" mental model because the boundary between server and client is explicit and small, not a new language layered on top of an old one.