Top 60 Svelte Interview Questions (2026)

Svelte is a UI framework, but it works as a compiler: it turns your components into small, direct-to-the-DOM JavaScript at build time. React and Vue ship a runtime that diffs a virtual DOM in the browser, while Svelte does that work ahead of time.

The practical results: no virtual DOM, smaller starting bundles because there's no framework runtime to download, and reactivity built into the language rather than added through hooks or a reactive library.

A Svelte component is a single .svelte file with three optional parts: a <script> block for logic, plain HTML markup for structure, and a <style> block for CSS that's scoped to the component by default. All three are optional, so a component can be markup only, or script and markup with no styles, whatever the piece needs.

You don't return markup from a function like in React; the markup is the file's body, and the script's top-level variables are available in it.

In Svelte 5, you declare reactive state with the $state rune, and any markup that reads it updates automatically when the value changes. Assigning to a reactive variable is all it takes; there's no setState call and no dependency array to maintain. The compiler figures out which parts of the DOM depend on which values and updates only those.

The compiler tracks which parts of the DOM depend on which values and generates code to update only those parts. So reactivity is fine-grained: changing one value doesn't re-run a whole component.

Runes are function-like symbols that tell the Svelte compiler how to treat a value: $state for reactive state, $derived for computed values, $effect for side effects, and $props for component props. They a dollar sign and are compiler keywords, not real functions you import comes first.

Svelte 5 introduced them to make reactivity explicit and consistent everywhere, replacing the older let-plus-$:-label approach that only worked at a component's top level.

$state holds a value you set directly, like a counter or a form field. $derived computes a value from other reactive values and recomputes automatically whenever any of them change, and you never assign to it directly. Think of $state as the source of truth and $derived as a formula that stays in sync with it.

Use $derived for anything you'd otherwise recalculate by hand: a total, a filtered list, a formatted string. It keeps derived data in sync without an effect.

The parent passes props as attributes on the component tag, like count={42}. The child reads them by destructuring the $props rune, and can set defaults right there in the destructuring, so a missing prop falls back to a sensible value instead of undefined. You can also collect leftover props with a rest pattern.

In older Svelte you declared each prop with export let. Svelte 5 replaced that with $props, which gives you all props in one object and supports defaults and rest props cleanly.

In Svelte 5 you attach a handler as a normal attribute, like onclick={handler} or oninput={handleInput}. The value is a function that runs when the event fires, and you can pass either a named function or an inline arrow. Earlier Svelte used the on:click directive syntax, which you'll still see across older code and tutorials, so it's worth recognizing both forms.

Event objects arrive as the handler's argument, exactly like plain DOM, so e.target.value and e.preventDefault() work as expected.

Svelte uses logic blocks in the markup rather than JavaScript expressions embedded in JSX. {#if condition} renders its body when the condition is truthy, with optional {:else if other} and {:else} branches, all closed by {/if}. Because it's a compiler feature, only the matching branch's DOM is created, and switching branches removes the old one and mounts the new one.

It reads like plain templating, which keeps conditional markup easy to scan.

The {#each} block loops over an iterable: {#each items as item, i} renders its body for each element and gives you the index, and you can destructure the item inline. Adding a key at the end, {#each items as item (item.id)}, tells Svelte how to match each item to its DOM node across updates, which matters as soon as the list changes.

Without a key, reordering or removing items can update the wrong nodes and lose component state, so key any list that isn't static.

Styles in a component's <style> block apply only to that component, not the whole page. Svelte does this at compile time by adding a generated hash class (like svelte-abc123) to the affected elements and appending that class to your selectors, so a p rule here won't touch paragraphs in another component. You write plain, simple selectors and scoping is automatic.

For styles you deliberately want global, wrap the selector in :global(), for example :global(body).

bind: creates a two-way binding between a variable and a form element or component prop. bind:value on an input keeps the variable and the field in sync in both directions, so typing updates the variable and changing the variable updates the field, and you skip writing a manual oninput handler. It's the shortcut for the controlled-input pattern you'd write by hand in React.

It works for checkboxes (bind:checked), select elements, and even element references (bind:this) to get the raw DOM node.

The class: directive toggles a class based on a condition: class:active={isActive} adds the active class when isActive is truthy and removes it when it's not. It's cleaner than building a class string with template literals or ternaries, and you can stack several on one element. Svelte reevaluates each toggle whenever its condition changes.

There's a shorthand too: class:active applies the active class when a variable named active is truthy.

onMount registers a callback that runs once, after the component is first rendered into the DOM. It's the place for setup that needs the DOM to actually exist: measuring an element's size, starting an interval or subscription, initializing a chart library, or fetching data on the client. If the callback returns a function, Svelte runs it as cleanup when the component is destroyed.

If the callback returns a function, Svelte runs it on component destroy for cleanup. onMount doesn't run during server-side rendering, which matters in SvelteKit.

Wrap the expression in single curly braces: {count}, {user.name}, {price * qty}. Any JavaScript expression works, and the result updates automatically when its reactive inputs change. The same braces set attribute values too, like src={imageUrl} or disabled={isLoading}, so you don't concatenate strings by hand. Text in braces is escaped, which keeps it safe by default.

To render raw HTML instead of escaped text, use {@html string}, but only with trusted content because it skips escaping.

Yes, $derived is Svelte's computed value. It recalculates when its dependencies change and caches the result until they do, so reading it repeatedly doesn't rerun the calculation. That's the same idea as Vue's computed properties: derived data that stays in sync automatically, without you writing a watcher or calling a recompute function.

Before runes, the equivalent was a reactive statement with the $: label. Both give you derived data that stays in sync without a manual watcher.

Svelte is the component framework; SvelteKit is the official application framework built on top of it. SvelteKit adds file-based routing, data loading, server-side rendering, API endpoints, and a build setup, so you can ship a full app rather than wiring those pieces yourself.

The relationship mirrors React and Next.js: you can use Svelte components alone, but real applications usually reach for SvelteKit.

Scaffold a new project with the official sv create command, which walks you through options like TypeScript, ESLint, and a testing setup. Then change into the folder, install dependencies with npm install, and start the dev server with npm run dev. Vite powers the dev server, so it starts fast and reflects saved changes almost instantly.

That dev server gives hot module replacement, so component edits show up without a full page reload or losing state.

In Svelte 5, a component receives whatever markup the parent nests inside its tags through the children snippet prop, and renders it wherever you write {@render children()}. So a Card component can wrap arbitrary content the caller provides, like a heading and a paragraph, and place it inside its own layout. The parent doesn't need any special syntax, it just nests markup between the tags.

Before Svelte 5 this was done with <slot> elements. Snippets replaced slots with a more flexible model that can also take arguments.

By default Svelte escapes text in curly braces, so {value} always renders as plain text and can't inject markup. The {@html value} tag is the exception: it renders a string as raw HTML, which you need when the content genuinely contains markup, like output from a Markdown renderer or a rich-text field.

The risk is cross-site scripting. Passing untrusted input to {@html} lets an attacker inject scripts, so sanitize any user-supplied HTML first and only use the tag on content you trust.

When an attribute name matches the variable you're passing, Svelte lets you drop the value: {src} is shorthand for src={src}, and it works for props on components too. For spreading, {...props} passes every key of an object as separate attributes, which is handy for wrapper components that forward props.

These small conveniences cut noise in markup, and forwarding props with the spread is a common pattern for building reusable input and button components.

$effect runs a side effect after the DOM updates, and it re-runs whenever any reactive value it read last time changes. Use it for work that reaches outside Svelte's own world: logging, manually touching the DOM, driving a third-party library, or syncing state to something like localStorage. Svelte tracks the effect's dependencies automatically from what it reads.

Avoid it for computing values; that's what $derived is for. Overusing $effect to set other state creates hard-to-follow update chains and is a common Svelte 5 antipattern.

A store holds a value shared across components. writable(initial) gives a store you can update with set and update; readable(initial, start) gives one consumers can only read, with the value produced by a start function. Components read a store's value with the $ prefix, like $count.

The $ auto-subscribes in markup and unsubscribes on destroy, so you rarely call subscribe by hand. Any object with a correct subscribe method counts as a store, which is why the contract, not the built-ins, is the real answer.

A derived store computes its value from one or more other stores and recomputes automatically whenever any source changes. You pass the source store, or an array of stores, plus a function that maps their current values to the derived value. Components read it with the $ prefix like any store, and it stays in sync without manual subscriptions.

It's the store-level equivalent of $derived: use it when the computed value needs to live outside a single component and be shared.

Use $state for reactive state that lives inside a component or in a module you import. Use stores when you need the subscribe contract, for example integrating with code that expects a store, or patterns built around readable and derived stores.

Svelte 5 lets $state work in plain .svelte.js modules for shared state, so many cases that used to need a store now use runes. Stores still matter for interop and for the RxJS-style subscribe interface.

onMount runs after the first render, onDestroy runs before the component is removed, and tick returns a promise that resolves once pending state changes have applied to the DOM. beforeUpdate and afterUpdate exist in older Svelte but are discouraged in Svelte 5 in favor of $effect.

onMount and onDestroy are the two you use constantly: set up subscriptions or timers in onMount, tear them down in onDestroy (or return the cleanup from onMount).

State changes in Svelte are batched and applied to the DOM asynchronously, so right after you assign a value the DOM hasn't updated yet. tick() returns a promise that resolves once those pending updates have flushed, so writing await tick() lets you read or measure the updated DOM at exactly the right moment. It's the bridge between changing state and reading its rendered result.

The common case: change a value, await tick(), then measure or scroll an element that depends on the new DOM.

The parent passes a callback function as a prop, like onsave, and the child calls it when something happens, passing along any data. This replaces createEventDispatcher from older Svelte, which is now discouraged. Because the callback is an ordinary function prop, it flows down like any other prop and the child stays unaware of who's listening.

Callback props are plain functions, so you get type checking and can pass any arguments, which is simpler than dispatching custom events and listening with on:.

setContext(key, value) stores a value that any descendant component can read with getContext(key), without threading it through every level as props. It's set during a component's initialization, so you call it at the top of the script, and only descendants of that component can read it. This solves prop-drilling for values a whole subtree needs but intermediate components don't care about.

Use it for things a whole subtree needs, like a theme, a form controller, or a shared client. Context isn't reactive by itself; put a store or a $state object in it if consumers need updates.

SvelteKit uses file-based routing under src/routes, so the folder The technical sequence is the route map. A folder becomes a URL segment, and a +page.svelte file inside it is the page rendered at that path. Dynamic segments use square brackets, like [slug], and the matched value arrives through the route's params object in your load function and page.

Special files pair with pages: +layout.svelte wraps child routes, +page.js or +page.server.js load data, and +server.js defines API endpoints. The folder The technical sequence is the route map.

A load function fetches the data a page or layout needs before it renders. It lives in +page.js (runs on server and client) or +page.server.js (server only, for secrets and database access), and returns an object the page reads through its data prop.

SvelteKit runs load on the server for the first request (SSR) and on the client for later navigations, so the same code powers both without you handling the difference.

By default SvelteKit renders the first page on the server (SSR): it runs your load functions, produces HTML the browser can show immediately, then hydrates that HTML on the client so it becomes interactive. After that first load, navigations between pages happen on the client without full page reloads, which keeps the app feeling fast while the initial response stays SEO-friendly.

You can change this per route: prerender for static pages built at build time, or ssr = false to render only on the client. Choosing the right mode per route is a real design decision.

Svelte ships transition directives you apply directly to elements: transition:fade for both directions, or in:fly and out:slide to animate entry and exit separately, all from svelte/transition. They run automatically when an element enters or leaves the DOM through an {#if} or {#each} block, and you can pass options like duration or delay. No animation library is needed for the common cases.

The animate: directive handles reordering within an each block (like a smooth list sort), and you can write custom transitions as functions that return CSS over time.

An action is a function you attach to an element with use:name. Svelte calls it with the actual DOM node when the element mounts, letting you run imperative setup that needs a real element: wiring up a tooltip library, adding click-outside detection, or attaching a drag handler. It keeps that DOM code out of the component body and reusable across elements.

The action can return an object with update (called when its parameters change) and destroy (called on unmount for cleanup). Actions are Svelte's clean escape hatch to the raw DOM.

Form actions handle POST submissions on the server without you writing a separate API route. You export named actions from +page.server.js, and a form posts to them with method="POST" and an action attribute. They run server-side, validate, and return data or errors.

With progressive enhancement via use:enhance, the form works without JavaScript and gets a smooth client experience when JS is present. It's SvelteKit's answer to form handling.

In Svelte 5, $state deeply proxies objects and arrays, so array methods like push do trigger updates. The classic 'push doesn't work' problem is a Svelte 3 and 4 issue: reactivity there triggered on assignment, so you had to reassign (items = [...items, x]) or do items.push(x); items = items.

So the honest answer depends on version. In Svelte 5, mutation works because state is a proxy; in older Svelte, reassign to trigger the update.

Declare the prop with $bindable() inside the $props destructuring, giving it an optional default, and then the parent can use bind: on it. Without $bindable, props flow one way, parent to child, and the child can't push changes back. With it, changes the child makes to that prop flow back up to the parent's bound variable.

This lets a parent both pass a value in and receive changes out through the same prop, which is how you build controlled inputs as reusable components.

{#key expression} destroys and recreates everything inside it whenever the expression changes. That forces a full remount rather than an update, which resets the block's component state and replays any enter transitions. It's the tool for 'start fresh when this value changes' rather than 'update in place', which is Svelte's normal behavior.

Use it when you want a component to fully reinitialize on some value changing, for example re-running an entry animation when a tab switches, or resetting a form when the selected record changes.

{#await promise} renders different markup for the three states of a promise, right in the template. The first branch shows while it's pending, the {:then value} branch shows the resolved result, and the {:catch error} branch shows if it rejects. Svelte re-renders as the promise settles, so you get loading, success, and error handling in one block with no extra state variables.

It saves you from tracking loading and error flags by hand for simple async displays.

A <script module> block (formerly written <script context="module">) runs once when the file is first imported, not once per component instance like the regular <script>. So variables and functions declared there are shared across every instance of the component, which is different from ordinary state that each instance gets its own copy of.

Use it for constants, helper functions, or shared state that shouldn't be duplicated per instance. Exports from a module script become named exports of the component file.

Svelte provides special pseudo-elements for things you can't target with normal markup. svelte:head injects tags into the document head, like a page title or meta tags. svelte:window and svelte:body let you attach events and bindings to window or body from inside a component, for example bind:scrollY or an onkeydown handler on the window.

There's also svelte:element for rendering a tag whose name is decided at runtime, and svelte:boundary for catching errors in a subtree. They're the escape hatches for cases the standard template can't express.

The compiler turns each component into a JavaScript module with imperative code that creates DOM nodes and updates exactly the ones tied to changed state. There's no virtual DOM and no diffing; the update instructions are baked in at build time.

That matters for two reasons: bundles carry component logic instead of a general runtime, so the baseline is smaller, and updates are surgical rather than re-rendering and reconciling. The cost moves from runtime to build time.

Svelte 5 rebuilt reactivity on signals. $state creates a reactive source; $derived and $effect create reactions that read those sources. When a reaction runs, Svelte records which signals it read, building a dependency graph, so changing a signal only reruns the reactions that actually depend on it.

This is fine-grained: the framework doesn't re-run a component, it updates the specific derived values, effects, and DOM bindings connected to the changed signal. It's the same family of ideas as SolidJS signals, applied through Svelte's compiler.

In Svelte's favor: smaller bundles by default, less boilerplate, scoped styles built in, and reactivity that reads naturally. Against it: a smaller hiring pool, fewer third-party component libraries, less battle-tested tooling for very large teams, and fewer answers when you hit an unusual edge.

The honest senior take weighs team and ecosystem, not just the framework. Svelte shines for lean teams and performance-sensitive apps; React's gravity (talent, libraries, patterns) is the reason large orgs often still pick it.

Keep local state in $state, lift shared state into .svelte.js modules that export reactive $state objects or stores, and reserve context for subtree-scoped state like a theme or a per-route controller. Avoid a single global god-store; co-locate state with the feature that owns it.

For server data in SvelteKit, load functions plus the data prop are the primary state channel, so a lot of what would be client state in a SPA lives in the load layer instead. That split, server data through load, UI state through runes or stores, keeps large apps manageable.

The big ones: using $effect to derive state (creating cascading updates that should be $derived), reading state inside an effect that then writes it back (infinite loops), and forgetting cleanup for subscriptions or timers, which leaks. Effects also over-track: any reactive read becomes a dependency, so an effect can rerun more than you expect.

Avoid them by pushing computation into $derived, keeping effects for genuine side effects (DOM, network, external libraries), returning a cleanup function, and scoping what the effect reads. Reach for untrack when you must read a value without depending on it.

The server renders your page to HTML and sends it, so the browser shows content immediately. Then the client-side Svelte code attaches to that existing DOM rather than recreating it, wiring up event handlers and reactivity. That's hydration: the page is visible before it's interactive, then becomes interactive without a re-render.

It breaks when server and client render different output: reading window or document at the top level, using Math.random or Date.now during render, or gating markup on something only known on the client. The fix is to defer client-only work to onMount or guard it with browser from $app/environment.

Load functions declare dependencies implicitly: using fetch tracks that URL, and depends('key') registers a custom dependency. Calling invalidate(url) or invalidate('key') reruns only the load functions that depend on it, and invalidateAll reruns everything. Accessing url.searchParams or params ties a load to those, so the right reruns happen on navigation.

This is what makes SvelteKit data feel live without manual refetching: mutate on the server through a form action, then invalidate the affected dependency and the page's data refreshes from its load function.

Measure first: the browser performance panel for runtime cost, bundle analysis for download size, and Lighthouse or web-vitals for real metrics. Svelte's fine-grained updates mean runtime rendering is rarely the bottleneck; the usual culprits are large dependencies, unkeyed each blocks doing extra DOM work, heavy effects, and shipping too much to the client.

Fixes in order: key your each blocks, move computation to $derived so it's cached, lazy-load heavy components and routes, and in SvelteKit choose prerendering or SSR per route to cut client work. Only then micro-optimize.

Component tests use Vitest with the Svelte testing library to render a component, interact with it, and assert on the DOM, which matches how users behave rather than testing internals. Load functions and form actions are plain functions you can unit test directly by passing a mock event. End-to-end flows use Playwright against a running SvelteKit build.

The layered answer, unit-test load logic, component-test UI behavior, and end-to-end the critical paths, indicates production experience. Vitest and Playwright are the tools the official setup scaffolds.

A snippet is a reusable chunk of markup you define with {#snippet name(args)} and render with {@render name(args)}. Passed into a component as props, they cover what slots used to do, including named slots and slot props, but as first-class values you can pass around and call with arguments.

The default children snippet handles the common 'render whatever the parent nested here' case. Snippets are more flexible than slots because they're just values: a component can accept several, choose which to render, and pass data into them.

The core shift is reactivity. A plain let plus a $: statement becomes $state and $derived, export let props become a $props destructuring, and reactive statements that ran side effects become $effect. On top of that, createEventDispatcher gives way to callback function props, and slots give way to snippets rendered with {@render}. Most template syntax stays the same, so the churn is concentrated in the script.

Svelte 5 keeps a lot backward compatible, so migration can be incremental. The judgment part is knowing what stays (component structure, most template syntax) versus what's genuinely new (runes, snippets, the reactivity engine underneath).

The store contract is one method: subscribe(callback) that immediately calls the callback with the current value, calls it again on every change, and returns an unsubscribe function. Anything meeting that is a valid store and works with the $ auto-subscription. Writable stores add set and update.

You write custom stores to encapsulate logic, for example a store that also exposes domain methods, by wrapping writable and returning a curated set of methods plus subscribe.

SvelteKit uses adapters: a build plugin that packages your app for a target. adapter-node builds a Node server, adapter-static prerenders the whole site to files, and platform adapters (for serverless and edge hosts) output the format that platform expects. adapter-auto picks a common one during CI.

The design keeps your app code platform-agnostic; you change the adapter, not your routes, to move from a Node server to static hosting to an edge function. Knowing prerendering constraints (no per-request server code) is part of choosing correctly.

hooks.server.js exports functions that run on the server for every request. The handle hook wraps request handling: it's where you read cookies, authenticate, put values on event.locals for load functions to read, and modify responses. handleError customizes error handling, and handleFetch rewrites server-side fetch calls.

handle is the choke point for cross-cutting server concerns: auth, logging, headers, and request-scoped context. It's the SvelteKit equivalent of middleware.

Svelte auto-escapes text interpolation, so {userInput} is safe. The XSS risk is {@html value}: it injects raw HTML unescaped, so never pass untrusted content to it without sanitizing. On the server side, load and form actions must validate input and avoid leaking secrets, keeping sensitive work in +page.server.js and hooks.

Other real ones: CSRF protection on form actions (SvelteKit checks origin on POST), not exposing env variables prefixed for public use by mistake, and setting security headers through the handle hook.

Use +page.server.js (a server load) when the work must stay on the server: database queries, secret API keys, private data, or heavy computation. Its return value is serialized to the client, so it can't return non-serializable things like functions. Use +page.js (a universal load) when the fetch can safely run in the browser too, which enables client-side navigation without a server round trip.

The rule of thumb: secrets and direct data access go server-side; public API calls that should also run on client navigation go universal. You can combine them, with the universal load receiving the server load's data.

Yes. Adding <svelte:options customElement="my-widget" /> to a component tells the compiler to output a native custom element instead of a regular Svelte component. You register it once, then use <my-widget> in any framework, a plain HTML page, or a CMS, because it's a standard web component. This is how teams ship a Svelte widget into a codebase that isn't Svelte.

The caveats: custom-element mode changes some behavior (styles are encapsulated in shadow DOM, props map to attributes and are strings unless typed, and slot and context semantics differ), and you carry a bit of runtime you otherwise wouldn't. It's a targeted tool for interop, not the default output.

In load functions and actions, throw the error helper (error(404, 'Not found')) for expected HTTP errors; SvelteKit renders the nearest +error.svelte page with the status and message. Unexpected exceptions become 500s and go through handleError, where you log and shape a safe message. redirect(303, '/login') works the same way for navigation.

The architecture gives you route-scoped error pages (an +error.svelte per level) plus one central place (handleError) for logging and reporting, so you separate user-facing error UI from operational error handling.

In Svelte 5 you can use runes outside components, in a file named with the .svelte.js (or .svelte.ts) extension. Export a $state object or a function that returns reactive values from that module, and any component importing it gets shared reactivity without a store. The extension is what tells the compiler to process runes in a plain module.

One rule to know: you can't export a reassignable $state variable directly, because importers would get a snapshot. Export an object whose properties you mutate, or a getter, so the reactivity survives the import.

When the team's existing skills, hiring plans, or required libraries center on another framework, the switching cost usually outweighs Svelte's technical wins. Projects that depend on a specific mature React or Angular library with no Svelte equivalent are a concrete case. Very large organizations sometimes value React's deep talent pool and established patterns over a smaller-bundle framework.

The mature answer treats framework choice as a team-and-ecosystem decision, not a benchmark. Svelte earns its place on performance-sensitive apps and lean teams; it's a harder sell where an org's whole platform, tooling, and hiring already assume something else.