Having worked through React, Angular, and Vue, Svelte is the genuine outlier — and the reason it's the perfect contrast piece. React, Angular, and Vue all ship a runtime to the browser: a framework library that runs alongside your code, doing reconciliation (a virtual DOM, or change detection) to figure out what to update. Svelte takes a fundamentally different path: it's a compiler. Your components are compiled at build time into small, surgical vanilla JavaScript that updates the DOM directly — and the framework itself mostly disappears, never shipped to the browser at all.

No Virtual DOM, No Runtime

When data changes in React or Vue, the framework re-runs render logic and diffs the result against the previous one to find what changed. Svelte's compiler instead analyzes your component ahead of time and generates precise code that updates exactly the right DOM node when exactly the right value changes — no diffing, no virtual DOM, no reconciliation library along for the ride. The practical results: very small bundles (no framework runtime weight) and excellent performance, with code that often looks like less than the equivalent in the other three.

The .svelte File

A Svelte component is a .svelte file with three optional parts: a <script> block for logic, the markup (written directly, not wrapped in a <template> tag), and a <style> block. This is close to Vue's Single-File Component, with one notable difference: the markup is just there at the top level of the file — no enclosing template element. {name} is interpolation, the same single-brace style as React's JSX rather than Vue/Angular's double braces.

Scoped Styles by Default

The <style> block's rules are automatically scoped to this component only — no scoped attribute needed (Vue) and no setup at all (unlike React). Two components can both style h1 differently with zero collision. Svelte achieves this by adding a unique class to the component's elements at compile time, with no runtime cost.

Creating a Project with Vite

npm create vite@latest -- --template svelte scaffolds a plain Svelte + Vite project — ideal for learning the component framework on its own (we add SvelteKit later). npm run dev starts the dev server with live reload, exactly as it did for React and Vue. To start a full SvelteKit app instead, you'd run npx sv create my-app — but the bare Vite template keeps the early chapters focused.

• src/main.js — the entry point; mounts the root App component.
• src/App.svelte — the root component, the first one you'll edit.
• index.html — the single real HTML page everything mounts into.

Mounting the Root Component

mount(App, { target }) attaches the root component to an element in index.html — the Svelte 5 equivalent of React's createRoot(...).render(), Angular's bootstrapApplication(), and Vue's createApp(App).mount(). (Older Svelte code used new App({ target }) with the new keyword — replaced by the mount function in Svelte 5.)

Coding Challenges

Chapter 1's interpolated values never changed. For a value that changes and updates the UI, Svelte 5 uses the $state rune — a compiler keyword (recognizable by the $ prefix) that marks a variable as reactive. This is Svelte's answer to React's useState, Vue's ref, and Angular's signal — but it reads the most like ordinary JavaScript of any of them.

$state — A Reactive Value

let count = $state(0) declares a reactive variable holding 0. The remarkable part: you read it as plain count and update it with plain assignment — count++ — and the UI updates automatically. No .value (Vue), no setter function (React's setCount), no .update() call (Angular). The $state rune tells the compiler "track this variable," and the compiler rewrites your ordinary count++ into the precise DOM update behind the scenes.

Why Not a Plain let?

A plain let count = 0 increments fine in memory, but Svelte 5 doesn't treat it as reactive — nothing tells the compiler to wire it to the DOM, so the displayed number never changes. The same trap as a plain variable in React or Vue. The $state rune is the single thing that makes it reactive.

Reactive Objects and Arrays

$state makes objects and arrays deeply reactive — mutating a nested property (user.age++) or even calling .push() on an array triggers a UI update. This is a notable contrast with React, where you must create a new object/array (spread, map, filter) because React compares by reference and never mutates. Svelte lets you mutate directly, which often reads more naturally — under the hood it uses a proxy (like Vue's reactive) to detect those mutations.

Markup Expressions

Interpolation isn't limited to a bare value — any JavaScript expression works inside { }: arithmetic, method calls, ternaries. Identical to React's curly braces and Vue's interpolation: expressions only, no statements. (For a value reused in several places or with heavier logic, you'd reach for $derived — next chapter.)

Coding Challenges

Two more runes complete Svelte's reactivity core. $derived computes a value from other reactive state and keeps it up to date automatically — the counterpart to Vue's computed, Angular's computed signal, and React's useMemo. $effect runs a side effect whenever the state it reads changes — the counterpart to watch/useEffect. Both, like $state, track their dependencies automatically.

$derived — A Computed Value

$derived(price * quantity) creates a value that automatically recalculates whenever price or quantity changes. Notice the syntax is even lighter than the others: you pass the expression itself, not a function returning it (no () =>). It's read as a plain variable ({total}), just like $state. Like Vue's computed and Angular's computed, it's cached (only recomputes when a dependency changes) and its dependencies are auto-tracked — no dependency array like React's useMemo.

$derived.by — For Multi-Line Logic

When the derivation needs more than a single expression, $derived.by(() => {...}) takes a function with a return — useful for filtering, conditionals, or any multi-step computation. This is the natural home for "filter a list before rendering it," the same pattern seen in Vue's computed filter and React's filter-before-map.

$effect — Running a Side Effect

$effect(() => {...}) runs its function after the component mounts, then again whenever any reactive value it reads changes — automatically tracked, no dependency list. This is for genuine side effects: logging, syncing to localStorage, manually touching the DOM or a third-party library. It's the equivalent of React's useEffect with auto-detected dependencies, or Vue's watchEffect.

Effect Cleanup

Returning a function from an $effect gives a cleanup function — run before the effect re-runs, and when the component is destroyed. This is exactly React's useEffect cleanup return, used the same way: anything that "starts" something ongoing (a timer, a listener, a subscription) returns its matching "stop." This is also how you handle teardown that the other frameworks put in a separate lifecycle hook (Vue's onUnmounted, Angular's ngOnDestroy).

Coding Challenges

With reactivity covered, this chapter connects it to the DOM: handling events, two-way-binding form inputs, and toggling classes/styles conditionally. Svelte leans toward standard HTML here — event handlers are plain DOM attributes — with a few concise directives layered on top.

Event Handlers

In Svelte 5, events are just standard lowercase DOM attributes — onclick, oninput, onsubmit — set to a function. onclick={() => count++} uses an inline arrow; oninput={handleInput} passes a function reference. This is closer to plain HTML than any of the other frameworks (which all use their own syntax — onClick in React, (click) in Angular, @click in Vue). The native event object is the handler's argument, exactly as in vanilla JS.

bind: — Two-Way Binding

bind:value={name} keeps a form input and a $state variable synchronized in both directions — typing updates name, and changing name in code updates the input. This is Svelte's equivalent of Vue's v-model and Angular's [(ngModel)], and it collapses React's manual value + onChange controlled-input pattern into one directive. The bind: prefix marks a two-way binding (vs a one-way attribute).

bind: on Different Input Types

Like Vue's v-model, Svelte's bind: adapts to the input type — checkboxes use bind:checked (a boolean), a <select> binds to the chosen option's value, and a type="number" input even auto-coerces the value to a number for you (a small nicety React makes you do by hand). Same simplicity benefit as Vue over React's per-type handling.

class: — Toggling a Class

class:active={isActive} adds the active class when isActive is truthy and removes it otherwise — a clean, declarative toggle, the equivalent of Angular's [class.active] and Vue's class binding. When the variable name matches the class name, you can shorten it to just class:active. Multiple class: directives can sit on one element.

style: — Binding a Style Property

style:color={...} binds a single inline style property to a reactive expression — handy for values that change dynamically, like a progress bar's width or a conditional color. The parallel of Angular's [style.color], expressed as a directive.

Form Submission

Svelte uses the standard onsubmit handler and standard e.preventDefault() — no special "prevent" modifier like Vue's @submit.prevent. Because bind:value keeps value in sync, the handler reads the current value directly and clears it by reassigning, with reactivity handling the rest.

Coding Challenges

Svelte handles conditionals and lists with logic blocks — special {#...} markers in the markup, closed with {/...}. This is a distinct style from all three other frameworks: not JavaScript-in-JSX (React), not directives-on-elements (Vue/Angular), but dedicated block syntax that reads almost like a templating language. Svelte even has a block for handling promises directly, which the others lack.

{#if} / {:else if} / {:else}

An {#if} block conditionally renders its contents, with optional {:else if} and {:else} branches. The opening tag uses #, continuation branches use :, and the close uses / — a consistent convention across all Svelte blocks. Like Angular's @if and Vue's v-if, a false branch genuinely removes its elements from the DOM. The whole {#if}/{:else if}/{:else} chain cleanly handles the loading/error/success pattern.

{#each} — Rendering a List

{#each items as item} repeats its contents once per array entry — Svelte's .map() equivalent. For lists that change (items added, removed, reordered), you should provide a key in parentheses so Svelte can track each item efficiently — the same role as React's key, Vue's :key, and Angular's track:

The (todo.id) after the item is the key. Unlike Angular's mandatory track, it's optional in Svelte — but strongly recommended for any list that mutates, for exactly the same correctness reasons.

{#each} with Index and an Empty Fallback

A second variable after the item gives the index — todo, index. And neatly, {#each} supports its own {:else} branch, rendered when the array is empty — handling the "empty list" case inline, the same convenience as Angular's @empty but built right into the each-block.

{#await} — Rendering a Promise Directly

This block has no equivalent in the other frameworks. {#await promise} renders the three states of a Promise directly in the markup: pending (before {:then}), resolved ({:then data} with the result), and rejected ({:catch error}). The loading/error/success pattern that took manual status state in every other framework's data-fetching is handled declaratively here, with the promise itself as the source of truth. (The {:then} and {:catch} branches are both optional if you only care about some states.)

Coding Challenges

Chapter 1's child components were static. Props make a component reusable by letting a parent pass data in — the same concept as React props, Vue's defineProps, and Angular's @Input. Svelte 5 declares them with the $props rune, and the result reads like plain JavaScript object destructuring.

Declaring Props with $props

let { name, age } = $props() declares the props this component accepts by destructuring them from the $props() rune. The destructured variables are then used directly in the markup ({name}), and — because $props is reactive — they automatically update if the parent passes new values. This is strikingly close to React's function UserCard({ name, age }) destructuring, just pulled from a rune instead of function parameters.

Passing Props from a Parent

Import the child, then place its tag with props as attributes. The familiar string-vs-expression rule applies, exactly as in JSX: name="Philip" passes the literal string, but age={35} (with braces) passes the real number. This is identical to React's quoting rule and the same idea as Vue's :age vs age — Svelte just uses JSX-style braces rather than a binding prefix.

Default Values

Because props are destructured, plain JavaScript default-value syntax gives a fallback when the parent omits a prop — age = 0, isAdmin = false. No special "default" option object like Vue's or Angular's; it's just destructuring defaults, the same as React's. Clean and familiar.

Rest Props and Spreading

The rest pattern (...rest) collects any props you didn't name explicitly, and {...rest} spreads them onto an element — the standard way to build a wrapper component that forwards arbitrary attributes (e.g. a custom <Button> that still accepts disabled, type, etc.). This is exactly React's {...rest} spread, working the same way.

Passing Objects and Arrays

Anything that isn't a plain string goes in braces — numbers, booleans, arrays, objects, functions. Note Svelte uses the JS-native inStock (camelCase) attribute name directly, with no kebab-case conversion (unlike Vue's :in-stock convention) — props are passed exactly as named.

Coding Challenges

Props (Chapter 6) send data down. To send something back up — a click, a deletion, a chosen value — Svelte 5's primary approach is a callback prop: the parent passes a function down as a prop, and the child calls it. This is exactly React's model (Project 1's todo delete), and a notable shift from Svelte 4's event system.

Callback Props — Child Calls a Function

onDelete is just another prop — a function. The child calls onDelete(id) when its button is clicked, and the parent's removeTodo receives the id. There's no special "emit" mechanism (unlike Angular's @Output or Vue's defineEmits) — it's a plain function passed as a prop, identical to how React does it. Naming it onSomething is the convention, matching the event-handler naming.

Multiple Callbacks

A component takes as many callback props as it needs, each a separate function. This scales cleanly — a dialog with onSave and onCancel, a form with onSubmit and onReset — all just functions passed down, with payloads passed as arguments when calling them.

$bindable — Two-Way Component Binding

Sometimes you want genuine two-way binding on a custom component — like a reusable input where the parent uses bind:value directly on it. The $bindable() rune marks a prop as bindable from the parent:

$bindable('') declares value as a prop the parent can two-way bind (with a default of ''). The child binds it to its real input; the parent uses bind:value={name} on the component itself, and changes flow both ways automatically. This is Svelte's equivalent of Vue's defineModel / v-model on a component, and Angular's value/valueChange two-way convention.

Coding Challenges

Props pass data into a child; content passes markup. Svelte 5's mechanism is the children snippet plus the {#snippet} block — its replacement for the old <slot> system, covering React's children, Vue's slots, and Angular's <ng-content> all at once. It's the most distinctive of the four frameworks' approaches, and worth taking slowly.

The Default children Snippet

Whatever a parent writes between a component's tags becomes a special prop called children — a snippet (a reusable chunk of markup). The child renders it with {@render children()}. So children is React's {children}, but instead of just embedding it, you call it via {@render} — because a snippet is technically a renderable function. Card doesn't know what's inside; it just renders whatever it's handed.

Named Snippets — Multiple Insertion Points

For several insertion points, the parent defines named snippets with {#snippet header()}...{/snippet} inside the component tags — and they arrive as props of those names. Anything not in a named snippet becomes the default children. This is the equivalent of Vue's named slots and React's named-JSX-props approach, expressed through the snippet system.

Fallback Content

Because snippets are just props (a value, or undefined if not passed), fallback content is a plain {#if} check — render the snippet if it exists, otherwise show a default. More explicit than Vue's "put fallback inside the slot tag," but using only tools you already know.

Parameterised Snippets — Passing Data Back

The most powerful case: a snippet can take parameters. The child calls {@render row(item)}, passing data out to the markup the parent provided; the parent's {#snippet row(person)} receives it. List owns the looping and data; the parent decides exactly how each row looks. This is the direct equivalent of React's render props and Vue's scoped slots — and notably, it's the same snippet syntax as the simpler cases, not a separate feature.

Coding Challenges

A component is created, mounted to the DOM, and eventually destroyed. Svelte provides lifecycle functions for the key moments — but with a twist: in Svelte 5, the $effect rune (Chapter 3) handles many cases that would be lifecycle hooks in other frameworks, because an effect with a cleanup return already covers "run on mount, clean up on destroy."

onMount — After the Component Is in the DOM

onMount runs a callback once, after the component is first inserted into the DOM — the standard place for an initial data fetch, the equivalent of React's useEffect(() => {...}, []), Vue's onMounted, and Angular's ngOnInit. Unlike the others, onMount is imported from 'svelte' (it's a function, not a rune). By the time it runs, the DOM exists, so it's also safe to measure or access elements here.

onDestroy — Cleanup Before Removal

onDestroy runs just before the component is removed — the place for cleanup, mirroring Vue's onUnmounted and Angular's ngOnDestroy. The universal rule applies: anything that "starts" something ongoing (a timer, a listener, a subscription) needs a matching "stop" here, or it leaks.

The Cleaner Way — onMount Returning Cleanup

A neat shortcut: if onMount returns a function, Svelte calls it on destroy automatically — so setup and teardown live together in one place, without a separate onDestroy. This is exactly React's useEffect cleanup-return pattern, and it keeps the timer's start and stop side by side.

$effect Often Replaces Lifecycle Entirely

Because $effect (Chapter 3) runs after mount and its returned cleanup runs on destroy, an effect frequently does the job of onMount + onDestroy together — and re-runs if its dependencies change, which a one-time onMount doesn't. The practical guidance for Svelte 5: use $effect for reactive setup/teardown (anything that should respond to changing state); use onMount for one-time, mount-only, browser-only setup (DOM measurement, SSR-sensitive code). You'll reach for onDestroy on its own fairly rarely now.

Coding Challenges

So far, runes have lived inside .svelte components. Svelte 5 lets you use them in plain JavaScript modules too — files named .svelte.js (or .svelte.ts) — which is how you share reactive logic and state across components. This single mechanism covers what was two separate things in the other frameworks: reusable logic (React's custom hooks, Vue's composables) and global state (Svelte 4's stores, Vue's Pinia).

The .svelte.js Module

A regular .js file can't use runes — they're only enabled in files with the .svelte.js extension. That naming tells the compiler "process runes in here too." Once you've done that, $state, $derived, and $effect all work exactly as they do in a component.

A Reusable Factory — Like a Composable

A factory function returning reactive state plus its behavior is Svelte's equivalent of a React custom hook or a Vue composable — call it in a component and each call gets its own independent state. The notable detail: to expose the reactive count while keeping it readable from outside, the returned object uses a getter (get count()). That's because a destructured $state value would lose its reactive connection — the getter re-reads the live value each access. (Vue's composables solve the same problem by returning the ref itself.)

Shared Global State — A Single Instance

For genuinely global state, export a $state object at module level — there's only one instance, so every component importing it shares the same reactive data. This is Svelte's whole answer to global state management: no Pinia, no Redux, no Context provider — just an exported reactive object. Because objects are deeply reactive (Chapter 2), mutating cart.items.push(...) updates every component using it. This is dramatically lighter than the equivalent in any of the other three.

Svelte Stores Still Exist (and the contrast)

Svelte 4's stores (writable/readable, accessed in components with a $ prefix like {$count}) still work in Svelte 5 and remain useful — especially for RxJS-style reactive streams. But for most shared state, the rune-based .svelte.js approach above is now the recommended default: it's the same mental model as in-component reactivity, with no separate store API to learn. Recognize writable and the $store syntax in existing code; reach for $state modules in new code.

Coding Challenges

Routing in the Svelte world is provided by SvelteKit, its official meta-framework — the equivalent of Next.js for React or Nuxt for Vue (and parallel to the SSR that Angular ships built-in). The standout feature: routing is file-based. You don't write a route config array (React Router, Vue Router) — instead, the folder structure under src/routes is the route map. This is the same model as Next.js's App Router, which Project 7 of the React course touched on.

Pages Are +page.svelte Files

Each folder under src/routes is a URL segment, and a +page.svelte file inside it is the page rendered for that URL. The root +page.svelte is /, about/+page.svelte is /about, and so on. The + prefix marks SvelteKit's special files (distinguishing them from your own components). No route config to maintain — adding a page is creating a file.

Layouts — Shared UI Across Routes

A +layout.svelte file wraps every page in its folder (and subfolders) — perfect for a shared nav, header, or footer. The current page renders where you call {@render children()} (the snippet mechanism from Chapter 8). This is SvelteKit's equivalent of a layout route with <Outlet> (React Router / Vue Router's <RouterView>), but defined by file convention rather than configuration.

Navigation — Just Anchor Tags

A genuinely nice surprise: SvelteKit navigates with plain <a> tags. There's no <Link> (React Router) or <RouterLink> (Vue) component — SvelteKit intercepts ordinary anchor clicks and turns them into client-side navigation automatically (no full page reload), while still working as a real link if JS is unavailable. The warning every other framework needed ("don't use a plain <a>!") is simply inverted here: plain anchors are the correct way.

Dynamic Routes — [param] Folders

A folder named in square brackets — [id] — is a dynamic segment, matching any value in that URL position (/product/1, /product/42). The param is read inside the page from the page state:

page.params.id reads the [id] segment — the equivalent of React Router's useParams(), Vue Router's route.params, and Angular's ActivatedRoute.paramMap. Wrapping it in $derived keeps it reactive, so navigating from /product/1 to /product/2 updates it. (The $app/state import is SvelteKit-provided.)

Programmatic Navigation

goto(url) navigates from code — after a form submits, a login succeeds, an action completes — the equivalent of React Router's useNavigate(), Vue's router.push(), and Angular's Router.navigate(). Imported from $app/navigation.

Coding Challenges

The final chapter covers how SvelteKit gets data into pages and data back out via forms — the pieces that make it a full-stack framework rather than just a router. This is where SvelteKit's server-rendering story (its big advantage over the plain Vite SPA from Chapter 1) really shows, and where it lines up directly against Next.js and Nuxt.

The load Function — Data Before the Page Renders

A +page.js beside a page exports a load function that runs before the page renders; whatever it returns arrives as the page's data prop. This is a real shift from the Chapter 9 pattern of fetching in onMount — load runs ahead of render (on the server for the first load), so the page arrives with its data already present, no loading flash, and it's SEO-friendly. It's the direct equivalent of Next.js server components / getServerSideProps and Nuxt's useAsyncData.

Dynamic Routes Get Their Param in load

The load function receives params, so a dynamic [id] route (Chapter 11) fetches exactly the right record server-side — params.id here is the same value page.params.id gave you in the component, but available before render so the data ships with the page.

Form Actions — Data Back to the Server

Form actions handle submissions on the server. A +page.server.js exports an actions object, and a standard HTML <form method="POST"> posts to it — no onsubmit handler, no manual fetch, and crucially it works without JavaScript (progressive enhancement). This is SvelteKit's signature data-out pattern, paralleling Next.js Server Actions and Remix's form actions — the framework leaning into web-standard forms rather than client-side-only handlers.

SSR, CSR, and Prerendering

SvelteKit renders on the server by default (SSR) — the first page arrives as real HTML (fast first paint, SEO-friendly), then "hydrates" into an interactive client app. You can tune this per route with page options: export const prerender = true turns a route into a static file at build time (ideal for content that rarely changes — a marketing or docs page), and export const ssr = false makes a route client-only (for something that can't run on the server). This per-route control over SSR / static / client-only is exactly the spectrum Next.js and Nuxt offer.

Deployment — Adapters

SvelteKit deploys via adapters — small plugins that package the build for a target platform. adapter-auto detects common hosts (Vercel, Netlify, Cloudflare); there's adapter-node for a plain Node server and adapter-static for a fully static site. You write the same app and swap the adapter for the destination — the same "deploy anywhere" promise as Nuxt's presets and Next.js's hosting flexibility.

Coding Challenges