React 19 Signals vs Svelte 5 Runes vs SolidJS Reactivity

For almost a decade, the virtual DOM was the dominant mental model for building web UIs. React popularized the idea: describe your UI as a pure function of state, let the framework diff a virtual tree against the real DOM, and batch the minimal set of updates. It worked. It scaled. And it introduced an entire generation of developers to declarative rendering.

But diffing is fundamentally wasteful. Every state change triggers a re-render of the entire component tree (or at least large subtrees), and then the framework spends CPU cycles figuring out what actually changed. When your component tree is deep and your updates are frequent, that overhead becomes measurable. The industry noticed, and the response has been a collective pivot toward fine-grained reactivity: systems that know exactly which piece of DOM depends on which piece of state, and update only that piece when the state changes.

Three frameworks represent the most important approaches to this problem in 2029. React 19 attempts to optimize the virtual DOM model with compiler-driven auto-memoization rather than abandoning it. Svelte 5 Runes compiles reactive declarations into surgical DOM updates at build time, eliminating both the virtual DOM and a runtime reactivity engine. SolidJS built fine-grained signals into its foundation from day one, delivering React-like JSX syntax with zero re-renders and proxy-based stores.

Each approach carries real consequences for performance, developer experience, and long-term maintainability. If you are choosing a reactivity model for your next product, this comparison will give you concrete numbers and honest tradeoffs rather than framework evangelism.

React 19 does not abandon the virtual DOM. That is the single most important thing to understand about its reactivity story. Instead of replacing the core diffing model, the React team built the React Compiler (formerly React Forget) to solve the performance problems that the VDOM model creates. The compiler analyzes your component code at build time and automatically inserts memoization (the equivalent of wrapping everything in useMemo, useCallback, and React.memo) so that components skip re-rendering when their inputs have not changed.

This is a pragmatic choice. Billions of lines of React code exist in production. Ripping out the VDOM would break every React application on the planet. The compiler approach gives existing codebases a performance upgrade without rewriting anything. In practice, teams upgrading to React 19 with the compiler enabled report 20% to 60% fewer re-renders depending on component structure, with zero code changes required.

Beyond the compiler, React 19 introduced several reactivity-adjacent features that change how you think about data flow:

• useOptimistic lets you optimistically update UI state before a server response arrives, then reconcile when the real data comes back. This eliminates the janky loading states that plague form-heavy applications.
• use() is a new hook that can unwrap promises and context values inline, simplifying async data patterns that previously required useEffect chains or Suspense wrapper gymnastics.
• Server Components move rendering to the server by default, so the client never receives or processes components that do not need interactivity. This is a different kind of reactivity optimization: instead of making client-side updates faster, it eliminates client-side rendering for large portions of your application entirely.
• Actions and useActionState provide a structured pattern for mutations that integrates with transitions, pending states, and error handling without manually managing loading booleans.

The net result is that React 19 remains VDOM-based, but the compiler makes the VDOM fast enough that the overhead is rarely noticeable. For teams already on React, this is the path of least resistance. You get meaningful performance improvements without learning a new reactivity model. The tradeoff is that React will never match the theoretical performance ceiling of truly fine-grained systems like SolidJS, because the diffing step still exists even when heavily optimized. For a deeper look at how these features affect startup engineering, check out our React 19 features guide.

Svelte 5 introduced Runes, and they represent the most significant rethinking of Svelte's reactivity model since the framework's creation. The old Svelte reactivity system relied on the compiler detecting top-level let assignments and transforming them into reactive statements. It was elegant but limited: reactivity only worked inside .svelte component files, and there was no way to create reactive state in plain .ts or .js modules.

Runes fix this by introducing explicit reactive primitives that work everywhere:

• $state declares reactive state. Unlike React's useState, $state values are deeply reactive by default. Mutate a property on an object or push to an array, and the UI updates. No spread operators, no immutable update patterns, no reducers.
• $derived replaces the old $: reactive declarations with an explicit computed value. The Svelte compiler statically analyzes which $state values a $derived expression depends on and only recalculates when those specific dependencies change.
• $effect replaces $: statements that produce side effects. It runs after the DOM updates, similar to React's useEffect, but with automatic dependency tracking. You never write a dependency array. The compiler figures it out.

The critical difference from React and SolidJS is that Svelte's reactivity has no runtime engine. The Svelte compiler transforms your $state, $derived, and $effect declarations into vanilla JavaScript that directly manipulates the DOM. There is no signal graph maintained in memory. There is no virtual DOM. There is no scheduler. The compiled output is just imperative code that sets element.textContent = newValue when the relevant state changes.

The biggest win in Svelte 5 is universal reactivity. You can now create a reactive store in a plain .svelte.ts file and import it anywhere. This means your business logic, form validation, API caching layers, and shared state can all be reactive without being tied to component files. This was Svelte's most significant limitation before Runes, and it is now completely solved. We covered the full Runes API and migration path in our Svelte 5 Runes deep dive.

The tradeoff is that the compiler is doing heavy lifting. Debugging compiled output is harder than debugging the code you wrote, and the gap between source code and executed code is wider than in React or SolidJS. Source maps help, but when something breaks in production, you are sometimes reading generated code that looks nothing like your source.

SolidJS took the most radical position of the three: build a framework that looks like React (JSX, components, props) but behaves fundamentally differently under the hood. In SolidJS, components run exactly once. There are no re-renders. The JSX you write is compiled into real DOM creation code that runs a single time, and then fine-grained signals handle all subsequent updates by directly mutating the specific DOM nodes that depend on changed state.

The core primitives are intentionally simple:

• createSignal returns a getter function and a setter function. Call the getter inside any reactive context (a component's JSX, a createEffect, a createMemo) and that context automatically subscribes to changes. Call the setter and only the subscribed contexts update. No component re-render. No diffing. Just direct DOM mutation.
• createMemo creates a derived value that recalculates only when its dependencies change. It caches the result so downstream subscribers do not trigger unnecessary updates.
• createEffect runs a side effect whenever its tracked dependencies change. Like Svelte's $effect, you never specify a dependency array. The runtime tracks which signals you read and re-runs the effect when they change.
• createStore provides proxy-based nested reactivity for complex objects. You can mutate deeply nested properties and only the specific DOM nodes reading those properties will update. This is similar to Svelte 5's deep $state reactivity but implemented with JavaScript proxies at runtime rather than compiler transforms.

The "no re-renders" model has profound implications. In React, you think about when components re-render and how to prevent unnecessary re-renders (with memo, useMemo, useCallback). In SolidJS, you never think about re-renders because they do not exist. Every piece of your JSX is either static (created once and never touched) or dynamic (wrapped in a signal getter that updates just that piece). This eliminates an entire category of performance bugs.

SolidJS also has SolidStart, its meta-framework for server-side rendering, routing, and API endpoints. SolidStart uses Vinxi under the hood and supports multiple deployment targets. It is less mature than Next.js or SvelteKit in terms of ecosystem and community resources, but it handles the core full-stack requirements well.

The tradeoff is the learning curve. SolidJS looks like React, and that creates a dangerous familiarity trap. Developers who assume it works like React will write broken code, because destructuring props kills reactivity, early returns can skip reactive subscriptions, and conditional rendering requires the Show component rather than inline ternaries. The rules are different, and the similarity to React makes those differences harder to learn than if the syntax were completely unfamiliar.

Let us talk numbers. The JS Framework Benchmark is the most widely cited performance comparison for frontend frameworks. It tests operations like creating 1,000 rows, updating every 10th row, swapping rows, selecting rows, removing rows, and appending rows. Here is where the three frameworks land as of their latest stable versions:

Benchmark scores (lower is better, 1.0 = vanilla JS):

• SolidJS: Geometric mean around 1.04 to 1.08. Consistently the fastest framework in the benchmark, often within 5% of hand-written vanilla JavaScript. Some operations (partial updates, row swapping) are essentially indistinguishable from raw DOM manipulation.
• Svelte 5: Geometric mean around 1.10 to 1.18. The Runes rewrite brought a measurable improvement over Svelte 4. Svelte 5 is especially competitive in initial creation and memory usage benchmarks. For most operations, it is within 15% of vanilla JS.
• React 19 (with compiler): Geometric mean around 1.35 to 1.50. The compiler reduces unnecessary re-renders, which helps in update benchmarks, but the VDOM diffing overhead keeps React consistently slower than Svelte and SolidJS in synthetic tests. React's performance is still absolutely fine for production applications, but it is measurably behind in benchmarks.

Bundle size (framework runtime, minified + gzipped):

• SolidJS: Approximately 7 KB. The signal runtime is tiny.
• Svelte 5: Effectively 0 KB runtime (the framework compiles away), but the compiled per-component output adds size. For small apps, Svelte produces the smallest total bundle. For large apps (100+ components), the per-component overhead can make the total bundle comparable to SolidJS.
• React 19: Approximately 42 KB (React + ReactDOM). This is the fixed cost you pay regardless of application size. For large applications with many components, the fixed runtime cost is amortized. For small, performance-critical widgets or landing pages, it is harder to justify.

Memory usage:

• SolidJS and Svelte 5 both use significantly less memory than React 19 in benchmark scenarios with thousands of DOM elements. SolidJS does not maintain a virtual DOM tree in memory. Svelte does not either. React maintains both the fiber tree and the virtual DOM, which adds memory overhead proportional to your component tree depth.

The real-world implication: if you are building a data-heavy dashboard with thousands of updating cells, a real-time collaborative editor, or a mobile web app where memory and CPU are constrained, SolidJS and Svelte 5 will give you meaningfully better performance. For standard SaaS products with forms, lists, and navigation, React 19 with the compiler is fast enough that users will never notice the difference.

Performance benchmarks are one dimension. The harder question is how each reactivity model affects your team's daily productivity, your ability to hire, and your long-term maintenance burden.

Mental model complexity:

React 19's model is the most familiar but also the most complex. You need to understand component lifecycles, the rules of hooks, the difference between state and refs, when to memoize, how Suspense boundaries work, how Server Components interact with Client Components, and how the compiler's auto-memoization interacts with all of the above. The React team has simplified some patterns (useOptimistic, use()), but the total surface area of concepts you need to hold in your head is large.

Svelte 5's model is arguably the simplest to learn from scratch. $state is reactive state. $derived is a computed value. $effect is a side effect. The compiler handles everything else. You do not think about memoization, dependency arrays, or re-render optimization. The mental model is close to spreadsheet-style reactivity: change a cell, and everything that depends on it updates automatically. The learning curve steepens when you need to understand the compiled output for debugging or when you hit edge cases around $effect cleanup and lifecycle timing.

SolidJS sits in a tricky middle ground. If you have never used React, SolidJS is straightforward: signals, memos, effects, done. If you have years of React experience, SolidJS is actively confusing because it uses similar syntax with different semantics. Destructuring props breaks reactivity. Components do not re-run. Conditional logic in JSX needs wrapper components. Every React instinct you have will mislead you for the first few weeks. Once the mental model clicks, many developers find SolidJS the most intuitive of the three, because the reactivity model is consistent and predictable.

Ecosystem maturity:

React dominates here and it is not close. npm downloads, community packages, component libraries, tutorials, courses, Stack Overflow answers, hiring pool size: React leads every metric by a factor of 10x or more. This matters. When you hit a problem at midnight before a launch, the probability that someone has solved your exact problem and posted the solution is highest with React.

Svelte 5 has a healthy and growing ecosystem. The Runes migration fractured some older libraries, but the core ecosystem (SvelteKit, Skeleton UI, Superforms, Paraglide) has fully adopted Runes. The community is enthusiastic and the documentation is excellent. You will occasionally find gaps for niche requirements.

SolidJS has the smallest ecosystem of the three. The core library and SolidStart are solid, and community libraries exist for common patterns (routing, state management, animation). But for specialized requirements, you will more often need to build from scratch or adapt a React library. The SolidJS community is passionate but small.

TypeScript support: All three have excellent TypeScript integration. SolidJS has arguably the best type inference because signals are just functions, and TypeScript understands function signatures natively. Svelte 5's Runes provide good type inference within .svelte files and excellent inference in .svelte.ts files. React 19's TypeScript story is mature and well-documented but requires more explicit type annotations for complex patterns.

SSR and hydration: React 19 with Server Components offers the most sophisticated SSR story, streaming HTML and selectively hydrating interactive islands. Svelte 5 with SvelteKit provides clean SSR with minimal hydration overhead because there is no runtime to hydrate. SolidJS supports streaming SSR through SolidStart and has a unique approach where hydration reuses the server-rendered DOM without walking the entire tree. For a broader comparison of these frameworks beyond reactivity, see our React vs Vue vs Svelte breakdown.

Migration difficulty:

If you are already on React 18, upgrading to React 19 is the easiest path. The React team has maintained strong backward compatibility, and enabling the compiler is a build configuration change. Most React 18 codebases work with React 19 without modifications. The new hooks (useOptimistic, use()) are additive, not mandatory.

If you are on Svelte 4, migrating to Svelte 5 Runes requires rewriting reactive declarations. The old $: syntax still works in a compatibility mode, but the Svelte team recommends migrating to Runes for new code. The migration is mechanical (there is a migration tool), but it touches every component file. For large codebases, expect a multi-sprint effort.

Migrating to SolidJS from React is the hardest path. Despite the JSX similarity, the reactivity model is different enough that components cannot be ported mechanically. You are rewriting your application. For small applications (under 50 components), this is a weekend project. For large applications, it is a multi-month effort that should only be undertaken if the performance benefits justify the cost.

Hiring and talent pool:

React developers are the easiest to find by an enormous margin. Any frontend job posting will attract React candidates. Svelte developers are less common but growing, and most can be productive within a few weeks because Svelte's learning curve is gentle. SolidJS developers are rare. You will mostly hire React developers and train them on SolidJS, which means budgeting for the learning curve and accepting reduced productivity during the transition.

Best use cases for each:

• React 19: SaaS products, enterprise applications, teams that need to hire aggressively, projects where ecosystem breadth matters more than raw performance, applications that benefit from Server Components for SEO and initial load speed.
• Svelte 5 Runes: Content-heavy sites, marketing platforms, interactive storytelling, applications where bundle size directly impacts revenue (e-commerce, media), teams that value developer experience and simplicity over ecosystem size, projects where universal reactivity (shared state outside components) is a key architectural requirement.
• SolidJS: Performance-critical dashboards, real-time data visualization, collaborative editing tools, embedded widgets where every kilobyte matters, teams with experienced frontend engineers who want the fastest possible runtime, projects where the "no re-render" mental model eliminates complexity.

Our honest default recommendation for most startups in 2029 is still React 19. The compiler closes the performance gap enough that it rarely matters, the ecosystem is unmatched, and the hiring advantage is real. But if your product's success depends on UI performance (real-time collaboration, complex data grids, mobile-first experiences on low-end devices), SolidJS and Svelte 5 are not just alternatives. They are genuinely better tools for those specific jobs.

The worst choice is no choice. Pick a reactivity model that fits your team, your product, and your hiring plan. Then ship. The framework matters far less than what you build with it.

Need help deciding which framework and reactivity model fits your product? Book a free strategy call and we will give you a specific recommendation based on your use case, team size, and performance requirements.