Svelte is a free, open-source framework for building user interfaces on the web with a different premise from most of its peers: instead of shipping a framework runtime that interprets your components in the browser, Svelte compiles them ahead of time into small, direct JavaScript that updates the DOM itself. You write components in .svelte files — HTML markup, scoped CSS and JavaScript in a single file — and the compiler turns that into optimised browser code. The project is MIT licensed, developed in the open at github.com/sveltejs/svelte, and has been in active development since 2016.

Since Svelte 5 the framework is built around runes: a small set of compiler keywords such as $state, $derived and $effect that make reactivity part of the language rather than a library you call. The current release line is Svelte 5 (5.57 at the time of writing), with the companion application framework SvelteKit on its own release track.

How the Compiler Changes the Equation

Most component frameworks work by diffing a description of the interface against the previous one and then patching the document. That is flexible, but it means every page carries a runtime that has to interpret components, track dependencies and reconcile trees at the moment the user interacts. Svelte moves that work to build time. The compiler analyses each component, sees which values drive which parts of the markup, and emits code that writes directly to the nodes it needs to update.

The practical consequences are concrete. There is no virtual DOM to diff, so there is no diffing cost at runtime. There is no framework runtime in the bundle at all — a compiled Svelte component is ordinary JavaScript, which also means a component can be mounted inside any page, including one that is not itself a Svelte application. And because the compiler knows the whole component graph, it can strip unused code, hoist constants and inline small expressions.

Runes and Reactivity

Runes are prefixed with $ and look like function calls, but the compiler treats them as keywords: they need no import, they cannot be assigned to a variable or passed around, and they are only valid in the positions the compiler expects. That design keeps the model explicit — nothing is reactive by accident.

• $state — declares reactive state. Objects and arrays become deeply reactive, so mutating a property or pushing to a list triggers an update; $state.raw opts out of that proxying for large values that are only ever reassigned, such as API responses.
• $derived — declares a value computed from other reactive values. The compiler memoises it and recomputes only when its inputs change, which is the recommended way to derive data instead of reaching for an effect.
• $effect — runs side effects after the DOM has been updated, and re-runs when the values it reads change. It does not run during server-side rendering, and it can return a cleanup function.
• $props, $bindable, $inspect, $host — declare component inputs, mark a prop as two-way bindable, inspect reactive values while debugging, and reach the host element when compiling to a custom element.

Runes coexist with normal JavaScript: a plain variable that no template expression depends on stays a plain variable, so the reactive surface of a component is exactly what the author declared it to be.

Key Features

• No framework runtime — components compile to direct DOM operations, so the bundle contains your code rather than Svelte’s.
• Scoped CSS by default — styles written inside a component apply only to that component’s markup, with support for global styles, custom properties and nested <style> blocks.
• Built-in transitions and animation — the transition:, in:, out: and animate: directives ship in the framework, covering fades, slides, crossfades, keyed-list reordering and spring and tweened motion without extra dependencies.
• Expressive template syntax — {#if}, {#each} with keyed blocks, {#await} for promises, and {#snippet} with {@render} for reusable markup fragments that replace slots.
• Async components — components and snippets can await promises directly in their markup, which removes a large amount of loading-state plumbing.
• Error boundaries — the <svelte:boundary> element catches errors thrown by descendants and renders a fallback, instead of taking down the whole page.
• Attachments and actions — the {@attach} syntax and use: directive attach reusable behaviour and event wiring to elements.
• TypeScript and custom elements — first-class TypeScript in components, and a compile target that emits standards-based custom elements for use outside Svelte.

Components, Snippets and Styling

A component is one file with three optional parts: a <script> block for logic, the markup itself, and a <style> block whose selectors are scoped to that component. Special elements cover the cases where components need the document around them: <svelte:window> and <svelte:body> for global event listeners, <svelte:head> for title and meta tags, <svelte:element> when the tag name is dynamic, and <svelte:options> for compile-time settings.

Snippets, introduced with Svelte 5, replace slots as the way to pass markup into a component or reuse it within one. A snippet is declared with {#snippet name()} and rendered with {@render name()}, which keeps composition explicit and works the same in a component, in a loop or at the top level of a block.

SvelteKit and the Toolchain

Svelte on its own is a UI layer: it compiles components and mounts them. Applications that need routing, server-side rendering, data loading, form actions and a production adapter usually use SvelteKit, the companion framework maintained by the same team. SvelteKit 3 shipped in October 2026 and handles file-based routing, prerendering, streaming and deployment adapters for Node servers, static hosting and edge platforms.

The toolchain around the framework is deliberately small. Projects are created with the Svelte CLI (npx sv create) or the Vite scaffold, and the build itself is Vite. Editor support comes from the official language server and extensions for VS Code and other editors, which understand .svelte files, run type checks and offer refactors. A debugging devtools panel and a browser-based playground round out the usual workflow.

Getting Started

The quickest start is the official scaffold, which asks which template, type checking and add-ons you want:

npx sv create my-app
cd my-app
npm install
npm run dev

For a minimal single-page setup the Vite template works just as well: npm create vite@latest my-app -- --template svelte. Either route needs a current Long Term Support Node.js release — the current Vite toolchain requires Node 20.19 or newer, or 22.12 and above. Everything else, including the compiler, arrives through npm.

What a Build Produces

The shape of the output is the argument for Svelte. A small release-board demo built for this entry with Svelte 5.57.3 and Vite 7.3.8, after installing dependencies from scratch, transformed 110 modules and emitted 0.47 kB of HTML, 7.6 kB of CSS and 37.9 kB of JavaScript — 14.7 kB of that JavaScript once gzipped — with no framework runtime anywhere in the bundle. The build completed in a few seconds, and the whole page was served as static files.

For larger applications the numbers grow with your own code rather than with a framework baseline, and code splitting keeps the initial download proportional to the route. The flip side is that the build step is mandatory: Svelte is not a script you can drop into an HTML page from a CDN and use directly. Anything shipped to a browser has to pass through the compiler, which is why projects reach for Vite or SvelteKit rather than a single <script> tag.

Where Svelte Fits

Svelte suits teams that want a component model without a runtime tax: content-heavy sites that care about JavaScript weight, dashboards and internal tools, embedded widgets, and projects that would rather write CSS in the component than in a utility framework. It is also a comfortable landing place for developers coming from plain HTML, CSS and JavaScript, because the file format is close to what they already write.

It is not the obvious choice everywhere. The ecosystem of third-party component libraries and ready-made integrations is smaller than React’s, so a team may end up building controls that would otherwise be a dependency. Hiring is narrower. And code written for Svelte 3 or 4 needs migration work to adopt Svelte 5’s runes — the framework keeps a legacy mode and a migration guide, but the move is real work on a large codebase. Projects that need to drop a framework into an existing page without a build pipeline are better served by a library that runs directly in the browser.

Project and Community

Svelte is MIT licensed and developed openly by the Svelte team together with a large contributor base; the main repository has gathered more than 88,000 stars and the project ships frequent patch and minor releases rather than one large annual release. Documentation lives at svelte.dev, alongside an interactive tutorial and a playground that compiles components in the browser. The team publishes a monthly “What’s new in Svelte” post covering framework, SvelteKit and tooling changes, and the wider community gathers around Svelte Society and the project’s Discord.

Related entries in the directory include TypeScript, the typed JavaScript superset most Svelte projects use, and other frameworks in this category such as Spring Boot and Laravel for comparison.