Svelte 5 Runes: $state, $derived, $effect Reactivity

For years, Svelte's headline trick was that reactivity looked like nothing at all. You wrote a plain let count = 0, reassigned it, and the UI updated. A top-level let in a component was implicitly reactive, and a dollar-colon label turned any statement into a re-running derivation. It felt magical the first time, and confusing the tenth, because whether a variable was reactive depended on where it lived rather than on anything you could see in the line itself.

Svelte 5, released stable in October 2024, keeps the compiled-away output but throws out the implicit rules. Reactivity is now declared with runes — explicit symbols you can read at a glance. I have shipped enough Svelte components to have been bitten by the old model, so this trade of a little more typing for a lot more clarity is one I welcome.

What a rune actually is

The official docs define runes as symbols you use in .svelte and .svelte.js or .svelte.ts files to control the Svelte compiler. They use a dollar-sign prefix and look like function calls, but they are not functions: you do not import them, you cannot store them in a variable or pass them as arguments, and they only work in specific positions. They are keywords in the Svelte language, validated by the compiler.

The core set is small. $state declares reactive state, $derived computes values from other state, $effect runs side effects when dependencies change, and $props declares the inputs a component receives from its parent. There are a few more — $bindable, $inspect, $host — but those four carry nearly every component you will write.

The four runes you will use every day

$state is the starting point. You write let count = $state(0) and, as the docs put it, count is just a number, rather than an object or a function, and you can update it like you would update any other variable. For arrays and plain objects, $state returns a deeply reactive proxy, so mutating a nested field or calling push is tracked. $derived takes an expression that must be free of side effects and recomputes whenever its dependencies change; $effect runs after the component mounts and re-runs in a microtask after the state it read changes.

<script>
  // $state declares reactive state — count is just a number
  let count = $state(0);

  // $derived recomputes automatically when count changes
  let doubled = $derived(count * 2);

  // $effect runs after mount and re-runs when its deps change
  $effect(() => {
    console.log('count is now', count);
  });
</script>

<button onclick={() => count++}>
  clicks: {count} (doubled: {doubled})
</button>

The example above shows all three cooperating. count is reactive state, doubled is derived from it and never assigned by hand, and the effect logs whenever count moves. Notice there is no subscribe call and no dependency array — Svelte tracks which state each derivation and effect reads, and re-runs exactly those that depended on what changed.

Why the team abandoned the magic

The move was not fashion. The Svelte team explained that in Svelte 4, if you change a single property of a reactive object, the entire object is invalidated, because that is all the compiler can realistically do. Meanwhile other frameworks adopted fine-grained reactivity based on signals and leapfrogged Svelte's performance. The old dollar-colon statement also conflated two concepts — derived state and side effects — that really should be kept separate. Runes split those apart and let the compiler wire up fine-grained, signal-based updates instead of invalidating whole objects.

Reactivity that escapes the component

The change that quietly matters most is universal reactivity. Because runes are a compiler feature rather than a component feature, they work in .svelte.js and .svelte.ts modules too. That means you can write reusable reactive logic once and import it anywhere, using a single mechanism instead of the old stores API.

// counter.svelte.js — universal reactivity outside components
export function createCounter() {
  let count = $state(0);
  return {
    get count() { return count; },
    increment: () => count += 1,
    reset: () => count = 0,
  };
}

// any .svelte component can now import and use this:
//   import { createCounter } from './counter.svelte.js';
//   const counter = createCounter();

In Svelte 4, sharing reactive state across components meant reaching for writable stores and their subscribe or dollar-prefix access. With runes you can express the same thing as ordinary JavaScript that happens to be reactive, exposing state through getters. Stores still exist and still have their place, but for most shared logic a .svelte.js module is now the simpler default.

Migrating from Svelte 4

The mental model maps cleanly, and there is an automated path. Running the migration command upgrades core dependencies and rewrites most of the old syntax for you, though some manual cleanup remains. The key substitutions are:

• Implicit reactive let becomes $state — a variable is reactive only when created with the rune.
• A dollar-colon derivation becomes $derived; a dollar-colon side effect becomes $effect — the two responsibilities the old syntax mixed are now separate runes.
• export let for props becomes a single $props destructuring, with defaults, renaming, and rest props all expressed in one place.
• Run npx sv migrate svelte-5 to bump dependencies, convert let to $state, switch on:click to onclick, and turn slots into snippets and render tags.

Svelte 4 versus Svelte 5 runes

My advice is to start a new feature in runes rather than converting a whole app on day one. The explicitness pays off fastest in code you are actively changing, where knowing at a glance which values are reactive removes a whole class of debugging. Run the migration script on a branch, read its diff, and treat the leftover manual fixes as a chance to learn where the old magic was hiding.