Run a mock round

Svelte components have a small lifecycle API. onMount runs once after the component is first rendered in the browser. It does not run during SSR, so it is the place for DOM measurement, subscriptions or fetching browser-only data, and it can return a cleanup function. onDestroy runs when the component is removed, for clearing timers or unsubscribing. beforeUpdate and afterUpdate fire before and after the DOM is patched.

<script>
  import { onMount, tick } from 'svelte';
  let el;
  onMount(() => { el.focus(); return () => console.log('bye'); });
  async function focusSoon() { await tick(); el.focus(); }
</script>

tick() returns a promise that resolves after pending state changes have been applied to the DOM, so it guarantees the DOM reflects your latest assignment. Multiple onMount calls are allowed and cleanups run in reverse order. In Svelte 5, $effect largely replaces onMount and afterUpdate.

In Svelte 3 and 4 reactivity is triggered by assignment to the variable the compiler tracks. Mutating an array or object in place does not notify the compiler because no assignment occurs.

<script>
  let items = [1, 2, 3];
  function add() {
    items.push(4);          // no update
    items = items;          // hacky, but triggers
    items = [...items, 4];  // idiomatic
  }
</script>

Use the spread operator or concat, filter and map to produce new arrays, or reassign properties into a new object, for example obj = { ...obj, key: value }. Nested component props also only update when the reference changes, so immutable updates are the norm.

Svelte provides $: reactive statements to recompute derived values when dependencies are assigned. With Svelte 5 $state, arrays and objects are deep proxies, so items.push(4) does update the UI. The runes model removes this common pitfall while keeping assignment intuition for primitives.

SvelteKit renders every page on the server by default and then hydrates it on the client, so the first paint is real HTML. You control this per route with page options. export const prerender = true generates static HTML at build time for routes with no per-request data. export const ssr = false disables server rendering so the page is a client-side app, which is useful for heavy browser-only widgets but worse for SEO and first paint. export const csr = false ships no client JavaScript for purely static content. Prerendering discovers links and can also be driven by entries().

Performance levers: keep load functions fast, avoid waterfalls by fetching in parallel and streaming promises, use enhance for progressive form submissions, and split heavy components with dynamic import(). Disabling SSR for a marketing page is usually a mistake.

Use data-sveltekit-preload-data on links so navigation feels instant, inline critical CSS, and test with the build preview because dev-mode behaviour differs.

A Svelte store is any object with a subscribe method that calls a callback with the current value and returns an unsubscribe function. The built-in writable, readable and derived helpers cover most cases.

import { writable, derived } from 'svelte/store';
export const count = writable(0);
export const doubled = derived(count, $c => $c * 2);
count.update(n => n + 1);

Inside a component you prefix a store with $ to read its value, so $count gives the current number, and Svelte subscribes and unsubscribes automatically. readable takes a start function that returns a cleanup and is useful for subscriptions such as time or sockets. derived can combine several stores and supports an async callback.

Custom stores wrap writable and expose domain methods such as increment, which keeps mutation rules in one place. Stores remain useful for cross-component state and for interop, while Svelte 5 runes in a shared module can replace them for new code.

Svelte is a compiler, not a runtime framework. At build time it parses components and turns reactive statements into precise DOM update instructions. In Svelte 3 and 4, let count = 0 and count += 1 compile into code that schedules a re-render when the assignment runs; the compiler knows which template expressions depend on count and updates only those text nodes or attributes.

<script>
  let count = 0;
  $: doubled = count * 2;
</script>
<button on:click={() => count++}>{doubled}</button>

Because the work happens at compile time, Svelte ships no virtual DOM and the runtime is tiny. The catch is that reactivity is assignment-driven: mutating arr.push(x) or obj.key = 1 did not update in Svelte 3 and 4 unless you reassigned, such as arr = arr.

Svelte 5 replaces the $: label model with runes. $state, $derived and $effect track fine-grained dependencies with signals and work in plain .svelte.js modules too.

Runes are compiler keywords that make reactivity explicit and also work in .svelte.js and .svelte.ts modules, not just components. $state creates a reactive value, deeply reactive through a proxy for objects and arrays. $derived declares a computed value that updates when its dependencies change. $effect runs a side effect after the DOM updates, tracking whatever reactive values it reads.

<script>
  let count = $state(0);
  let doubled = $derived(count * 2);
  $effect(() => console.log(doubled));
</script>
<button onclick={() => count++}>{doubled}</button>

$props() declares component inputs, $bindable() enables two-way binding, and $inspect helps debugging. Effects run in a microtask after rendering and should return a cleanup function for subscriptions.

Unlike $: labels, reactivity follows the value wherever it is defined, so shared state modules no longer need stores. Avoid overusing $effect for derived state; use $derived instead, because effects are for side effects and are harder to reason about.

SvelteKit uses filesystem routing under src/routes. A +page.svelte renders a page, +page.js or +page.server.js exports a load function that runs before the page and returns data, +layout.svelte wraps child routes, and +error.svelte handles errors. Dynamic segments use [slug] and rest parameters use [...rest].

// +page.server.js
export async function load({ params, fetch }) {
  const post = await fetch(`/api/posts/${params.slug}`).then(r => r.json());
  return { post };
}

A universal +page.js load runs on server and client, while a +page.server.js load runs only on the server and can access databases and secrets, returning serialisable data as props. Layout loads run for every descendant route and can nest. Form actions handle POST mutations progressively, and +server.js files are API endpoints.

This model gives SSR by default, with export const prerender = true for static pages and ssr = false for client-only ones.