Scrolls
5 min read
On this page

What Svelte Is

Svelte is a compiler, not a runtime framework. When you build a Svelte application, the compiler transforms your components into plain JavaScript that directly manipulates the DOM. There is no virtual DOM. There is no diffing algorithm. There is no framework runtime shipped to the browser. The code your users download is just the code that does the work.

This distinction matters more than it sounds.

The Compiler Approach

React and Vue ship a runtime to the browser. That runtime includes a virtual DOM implementation, a reconciliation algorithm, a scheduler, and the framework's reactivity system. Your application code sits on top of this runtime and delegates DOM updates to it.

Svelte works differently. At build time, the Svelte compiler reads your .svelte files and generates optimized JavaScript that knows exactly which DOM nodes to update when state changes. The output is surgical: if you change a counter from 3 to 4, the generated code updates that specific text node. No tree comparison. No diffing pass.

<script>
  let count = $state(0);
</script>

<button onclick={() => count++}>
  Clicked {count} times
</button>

The compiler sees this component and generates code roughly equivalent to:

// Simplified representation of compiler output
const button = document.createElement('button');
const text = document.createTextNode('Clicked 0 times');
button.appendChild(text);

// When count changes, update only the text node
// No virtual DOM diffing required
text.data = `Clicked ${count} times`;

The actual output is more sophisticated, but the principle holds: the compiler generates targeted update instructions at build time rather than figuring them out at runtime.

How This Differs from React & Vue

React's Model

React maintains a virtual DOM tree in memory. When state changes, React re-renders the component (calling your function again), produces a new virtual DOM tree, diffs it against the previous one, and applies the minimal set of real DOM operations. This is clever, but it is work that happens on every state change in the browser.

// React: the entire function re-executes on state change
function Counter() {
  const [count, setCount] = useState(0);
  // Everything here runs again on every render
  return <button onClick={() => setCount(count + 1)}>
    Clicked {count} times
  </button>;
}

Vue's Model

Vue uses a reactivity system with a virtual DOM. It tracks dependencies at runtime and knows which components to re-render, but still uses a virtual DOM to determine the minimal DOM operations within each component.

Svelte's Model

Svelte skips both layers. There is no virtual DOM to allocate, no diff to compute. The compiler already determined the relationship between state and DOM at build time. When state changes, the generated code runs the specific DOM operations directly.

The tradeoff: Svelte's compiler does more work at build time so the browser does less work at runtime.

Why Smaller Bundles Matter

A minimal React application ships roughly 40-45 KB of framework code (minified and gzipped) before you write a single line of your own logic. Vue ships around 30 KB. These numbers grow with additional libraries for routing, state management, and other concerns.

A minimal Svelte application ships almost no framework overhead. The generated code includes only the utilities your components actually use, and those utilities are small. A simple Svelte app can ship under 5 KB total.

This matters for several concrete reasons:

  • Mobile networks: Users on slow connections wait less. Every kilobyte counts on 3G.
  • Parse time: JavaScript must be parsed and compiled by the browser before it executes. Less JavaScript means faster time-to-interactive.
  • Memory: Less framework code means less memory consumption, which matters on low-end devices.
  • Caching: Smaller bundles are more cache-friendly and recover faster from cache invalidation.
Bundle size comparison (minimal app, gzipped):
React + ReactDOM:  ~44 KB
Vue 3:             ~33 KB
Svelte 5:          ~3 KB

These numbers shift as applications grow, but Svelte maintains an advantage because it only includes code paths your application actually uses.

The Svelte Philosophy: Write Less Code

Svelte is opinionated about developer experience. The framework aims to minimize the amount of code you write for common tasks. This is not about being terse for its own sake. It is about reducing the surface area for bugs and making components easier to read.

Consider a component that binds an input to a variable:

<script>
  let name = $state('');
</script>

<input bind:value={name}>
<p>Hello, {name}!</p>

Compare with the React equivalent:

function Greeting() {
  const [name, setName] = useState('');
  return (
    <>
      <input value={name} onChange={e => setName(e.target.value)} />
      <p>Hello, {name}!</p>
    </>
  );
}

The Svelte version has less ceremony. bind:value handles the two-way binding that React requires you to wire up manually. The <script> tag is just JavaScript. The template is just HTML with expressions. There is no JSX transform, no return statement wrapping your markup, no fragment syntax.

This philosophy extends throughout the framework:

  • CSS is scoped to the component by default, with no configuration.
  • Animations and transitions are built in, not separate libraries.
  • Stores provide global state without external packages.
  • SvelteKit handles routing, SSR, and deployment without bolting on a meta-framework.

When Svelte Is the Right Choice

Svelte works well for:

  • Performance-sensitive applications where bundle size and runtime speed matter.
  • Content-heavy sites where fast initial load is critical for SEO and user experience.
  • Small to mid-size teams that value simplicity and low boilerplate.
  • Embedded widgets where you need minimal overhead inside a larger page.
  • Progressive web apps targeting mobile users on constrained networks.

Svelte is less ideal when you need a massive ecosystem of third-party component libraries (React's ecosystem is larger) or when your team is already deeply invested in another framework's patterns.

Common Pitfalls

  • Assuming Svelte is "just another framework": Svelte's compiler model means some patterns that work in React or Vue do not translate directly. You cannot dynamically create components the same way, and debugging sometimes means reading generated code.
  • Expecting a large third-party ecosystem: Svelte's ecosystem is growing but is smaller than React's. You will occasionally need to build something that React developers would install as a package.
  • Confusing Svelte with SvelteKit: Svelte is the component framework and compiler. SvelteKit is the application framework built on top of Svelte that provides routing, server-side rendering, and deployment. Most real applications use both.
  • Overestimating the bundle size advantage at scale: For very large applications, the per-component overhead of Svelte's generated code can reduce the gap. The advantage is most dramatic for small to medium applications.

Key Takeaways

  • Svelte is a compiler that transforms components into vanilla JavaScript at build time. No virtual DOM, no runtime diffing.
  • The generated code performs targeted DOM updates, making runtime performance excellent without developer effort.
  • Smaller bundles mean faster load times, especially on mobile and constrained networks.
  • Svelte prioritizes writing less code: scoped CSS, two-way binding, built-in transitions, and minimal boilerplate.
  • Svelte is the component compiler. SvelteKit is the application framework. Real projects typically use both together.
  • The tradeoff is a smaller ecosystem compared to React, but the gap is narrowing.