React vs Svelte: What Changed Since the Classic 10-Example Comparison

React vs Svelte remains one of frontend development’s most useful comparisons—not because one framework universally wins, but because each makes different trade-offs around explicitness, tooling, and how much framework machinery developers should see.

Fireship’s popular 2023 video, “React VS Svelte...10 Examples,” made the contrast approachable by putting everyday patterns side by side: state, props, children, effects, derived values, loops, shared state, and async UI. Its central observation still holds: both build component-based reactive interfaces, but React generally asks developers to work through JavaScript APIs and runtime conventions while Svelte moves more behavior into its compiler. (youtube.com)

The important update is that the examples in that video largely reflect React 18-era and Svelte 4-era conventions. Today, React’s current documentation is on the 19.x line, while Svelte 5 has introduced runes and snippets—changes that make a modern React vs Svelte decision more nuanced than a simple comparison of useState against let.

React vs Svelte begins with the rendering model

React is a JavaScript library for building user interfaces from components. Its runtime manages updates and commits the necessary changes to the browser UI as state changes. That architecture has helped React support a vast ecosystem across web and native development, but it also means developers must understand concepts such as renders, hooks, effects, memoization, and component boundaries. (react.dev)

Svelte takes a compiler-first approach. Instead of shipping a large general-purpose UI runtime for every component update, Svelte compiles component code into targeted JavaScript during the build process. The Svelte team describes the result as components that do minimal work in the browser, written with familiar HTML, CSS, and JavaScript. (svelte.dev)

That difference matters, but it should not become a performance slogan. A smaller client-side footprint can be valuable for lightweight, content-heavy, or performance-sensitive products. Yet actual user experience also depends on routing, images, caching, server rendering, third-party scripts, data fetching, and the application architecture—not just whether a framework uses a virtual DOM-style runtime or a compiler.

State management: hooks versus runes

The original comparison’s most memorable example was the counter. In traditional React, local state typically comes from useState, which returns a value and a setter. That approach is explicit, portable, and deeply familiar to the enormous React talent pool.

In older Svelte code, a top-level let could be reactive automatically. That is the version of Svelte featured in Fireship’s video. Svelte 5 now makes modern reactivity more explicit through runes such as $state, $derived, and $effect; legacy syntax remains supported, but the framework recommends incremental migration for existing projects. (svelte.dev)

This is a meaningful correction to the old “React has boilerplate; Svelte is just JavaScript” framing. Svelte 5 still often reads more directly for UI state, but it now exposes its reactivity model more clearly and lets that model work beyond the top level of a component.

For teams evaluating React vs Svelte, the practical distinction is less about line count and more about mental models:

• React hooks make stateful behavior explicit through functions and conventions.
• Svelte runes tell the compiler what should be reactive, derived, or effectful.
• React rewards disciplined component design and careful effect usage.
• Svelte can reduce ceremony, but developers still need to understand reactive dependencies and component boundaries.

Neither model eliminates complexity. They place it in different places.

Composition has changed more than the old slots comparison suggests

Fireship compared React’s props.children with Svelte slots. That was accurate for Svelte 4, and slots still work in legacy mode. But Svelte 5 has deprecated slots in favor of snippets, which can be passed and rendered as values. Svelte’s documentation specifically notes that snippets are more flexible, and snippets can be passed to components as props. (svelte.dev)

That update closes one of the video’s sharper distinctions: modern Svelte is not limited to a rigid “slots instead of components as props” model. React still has an exceptionally mature composition culture built around JSX, children, render props, context, and a huge package ecosystem. But Svelte’s snippet model makes reusable layout APIs and targeted insertion points more expressive than the old slot-only mental model implies.

Templating remains a genuine preference test. React’s JSX keeps markup and JavaScript in one expression-oriented language. Svelte templates use dedicated control-flow blocks for conditions, loops, and promises. Developers who dislike nested ternaries may find Svelte’s {#if} syntax easier to scan; developers who prefer plain JavaScript expressions and reusable render logic may feel at home in JSX.

Async UI is now less one-sided

The video characterized React’s promise handling as experimental and more intimidating than Svelte’s template-level {#await} blocks. That was fair in 2023. React’s use API is now documented: it can read a Promise or context, suspends while a Promise is pending, and works with a surrounding Suspense boundary to show fallback UI. If the Promise rejects, the nearest Error Boundary handles it. (react.dev)

React 19 also added Actions, targeting common mutation workflows involving pending states, errors, optimistic updates, and sequential requests. (react.dev)

Svelte’s {#await} remains an appealing option because loading, success, and error states can sit visibly alongside the markup they control. React’s approach is more compositional and better aligned with Suspense-enabled frameworks, but it can be harder to grasp without understanding the surrounding architecture.

The takeaway is not that React has “caught up” or that Svelte has a permanently superior syntax. It is that asynchronous UI is now a design choice between two mature patterns: boundary-based composition in React and template-oriented state handling in Svelte.

Shared state should not decide the framework alone

The original video positioned Svelte stores as a built-in alternative to React’s frequent reliance on libraries such as Redux, MobX, or Jotai. Stores are still supported and useful, especially when working with asynchronous streams or when explicit subscription control is valuable.

But Svelte’s own current documentation says that, before Svelte 5, stores were the common answer for cross-component state and extracted reactive logic; with runes, those use cases have diminished. (svelte.dev) This is another reason not to judge modern Svelte only by examples from the Svelte 3/4 period.

React, meanwhile, has context and a broad spectrum of external state-management options. That can be a strength when a product needs a well-known library, deep integrations, specialized devtools, or a hiring-friendly standard. It can also become a liability when teams add global state tools before they have clearly identified a shared-state problem.

The better React vs Svelte choice is contextual

Choose React when your organization benefits from its ecosystem, existing team experience, cross-platform ambitions, established design system, or framework integrations. React’s scale and conventions can be an advantage when many teams need to collaborate on one product.

Choose Svelte when you want a highly approachable component authoring experience, compiler-driven reactivity, and a framework that keeps common UI patterns close to HTML, CSS, and JavaScript. SvelteKit is the official application framework recommended by the Svelte team for building full applications. (svelte.dev)

The enduring value of Fireship’s comparison is not a verdict. It is a reminder to test the workflows that shape your actual product: forms, data loading, reusable components, authentication, charts, error handling, and deployment. Build a small vertical slice in both frameworks, using current React 19 and Svelte 5 guidance, before making a decision that will affect years of maintenance.

Conclusion: compare today’s frameworks, not yesterday’s talking points

React vs Svelte is still a useful debate because the frameworks represent different ideas about frontend development. React prioritizes a flexible JavaScript-centered component model backed by an unmatched ecosystem; Svelte prioritizes compiler-assisted ergonomics and direct, concise UI code.

But the old comparison needs a modern footnote. React’s use, Suspense ecosystem, and Actions have advanced its async story, while Svelte 5’s runes and snippets have evolved the framework beyond the simple let, slots, and stores examples many developers remember. The best choice is the one whose current model helps your team ship a maintainable product—not the one that wins a ten-line counter demo.