What is Svelte?

Svelte is a frontend framework for building user interfaces. It was created by Rich Harris while at The New York Times, first released in 2016, and is developed full-time at Vercel since 2021. The framework is open-source under the MIT license and is maintained by a small core team plus a broad contributor base.

Svelte is best known for one design choice that puts it apart from React, Vue, and Angular: it is a compiler, not a runtime. Where other frameworks ship a library that interprets your components in the browser, Svelte reads your component files at build time and emits compact, vanilla JavaScript that updates the DOM directly. The framework, in its traditional sense, mostly disappears from what ends up running on the page.

Svelte shifts work that other frameworks do in the browser into a compile step instead.- svelte.dev

The compile-time approach

Most frontend frameworks have a runtime - a JavaScript library that ships to the browser, watches your component state, computes what needs to change, and applies the updates. React uses a virtual DOM and a reconciler. Vue and Angular have their own reactivity systems doing the same work. The runtime is the framework.

Svelte's bet is that this work can happen earlier. At build time, the Svelte compiler reads each .svelte file, understands which pieces of state affect which pieces of the DOM, and emits imperative JavaScript that updates those exact nodes when state changes. There is no virtual DOM, no reconciliation pass, and very little framework runtime left at all.

Two consequences are worth knowing:

  • Smaller bundles. What ships to the browser is closer to hand-written DOM code than a framework. For small to medium apps the difference is noticeable; for very large apps it converges, because most of the bundle is your application code either way.
  • Predictable updates. When state changes, the compiled code touches only the DOM nodes that depend on that state. There is no diff to compute.

The tradeoff is that your code needs a build step. You cannot drop Svelte into a page without a compiler in front of it the way you can with vanilla JavaScript - or, with some effort, with React. In 2026 this is a non-issue, because every modern project has a build step anyway: Svelte's compiler ships as a Vite plugin and runs as part of npm run dev.

The .svelte component file

A Svelte component is a single .svelte file with three optional blocks: a <script> block for logic, markup for the template, and a <style> block for CSS. The markup looks like enhanced HTML; the CSS is scoped to the component by default.

<!-- Counter.svelte -->
<script>
  let count = $state(0);
  let doubled = $derived(count * 2);
</script>

<button onclick={() => count++}>
  Clicked {count} times - that is {doubled} doubled.
</button>

<style>
  button {
    padding: 10px 16px;
    border-radius: 8px;
    background: var(--accent);
    color: white;
  }
</style>

A few details worth catching:

  • The markup is plain HTML with curly-brace expressions ({count}) for interpolation. No JSX, no template directives like v-if.
  • The <style> block is component-scoped automatically. A button selector here will not leak to other components.
  • The script uses Svelte 5's runes ($state, $derived) for reactivity. More on that next.
  • The file is its own component. There is no class wrapper, no export default - the file is the component, and importing it gets you a component you can mount.

Reactivity with runes

Svelte 5, released in October 2024, introduced runes - a set of compiler-recognized primitives that make a component's reactive intent explicit. They look like function calls prefixed with $, but they are syntactic markers the Svelte compiler turns into update code.

  • $state(initial) declares reactive state. Assigning to it triggers updates.
  • $derived(expr) declares a value computed from other reactive state. Recomputes when its dependencies change.
  • $effect(fn) declares a side effect that runs when its reactive dependencies change.
  • $props() declares the props a component receives from its parent.
  • $bindable() marks a prop as two-way bindable from the parent.
<!-- Greeting.svelte -->
<script>
  let { name = "world" } = $props();
  let greeting = $derived(`Hello, ${name}!`);

  $effect(() => {
    document.title = greeting;
  });
</script>

<h1>{greeting}</h1>

Runes replaced a more implicit model from Svelte 3 and 4 in which top-level let declarations were quietly reactive and a $: label marked derived values and effects. The older model was charming for small examples and surprising in larger ones, where it was easy to lose track of what was reactive. Runes trade a tiny amount of syntax for a much clearer reading of "what depends on what" - the same direction Angular signals and React's compiler are moving.

SvelteKit, the meta-framework

Svelte is the component framework. SvelteKit is the meta-framework around it - the official application framework that adds the pieces a Svelte-only project would have to assemble itself.

  • Filesystem routing. Pages live at src/routes/<path>/+page.svelte. A folder is a route; a +page.svelte is the page.
  • Server endpoints. +server.ts files become HTTP endpoints - the SvelteKit answer to a backend route handler.
  • Data loading. Each route can ship a +page.server.ts with a load function that runs on the server, fetches data, and hands it to the page as props.
  • Rendering modes. Server-side rendering, static site generation, and client-side navigation all in one app, configurable per route.
  • Adapters. Deploy targets (Vercel, Netlify, Cloudflare, Node, static) are swappable via a single adapter config. The same SvelteKit app runs on different platforms with no code change.

SvelteKit is built on Vite, which means everything in this article's webdev in 2026 story - esbuild for dev-time transforms, Rolldown for production, TypeScript support out of the box - applies directly to SvelteKit projects.

If you start a new Svelte project today, you almost certainly start it with npx sv create and get SvelteKit. The two are designed to be used together, even though Svelte (the component framework) can be used on its own.

What it supports

The defaults are deliberately sensible. Out of the box, a new SvelteKit project gives you:

  • TypeScript with no extra setup - just pick the TypeScript template when prompted, and .svelte files accept type annotations in their <script lang="ts"> blocks.
  • Scoped CSS per component, plus support for preprocessors (Sass, Less, PostCSS) and CSS frameworks (Tailwind is a one-command add).
  • Built-in transitions and animations with directives like transition:fade and animate:flip - small, opinionated primitives for common motion patterns.
  • Stores - a minimal cross-component state primitive for cases where shared state outside a component tree makes more sense than passing props.
  • SSR, prerendering, and form actions as first-class SvelteKit features, not as something you add later.

The Svelte community is smaller than the React or Angular communities, but the official surface - the language, the compiler, the meta-framework, the docs - is unusually coherent for a project of this size. Most of the documentation comes from one team with one design vocabulary.

Where Svelte fits

Svelte tends to feel like the right call for a few specific shapes of project:

  • Content-heavy sites with interactive pockets. Marketing sites, documentation, blogs - places where SSR and prerendering matter, the JavaScript should be small, and the interactivity is more sprinkles than app. SvelteKit's rendering flexibility is well-suited.
  • Performance-sensitive single-page apps. Where the bundle size and update cost actually show up in metrics, Svelte's compiled output often wins by enough to justify the smaller community.
  • Developers coming from HTML and CSS. The .svelte file model - enhanced HTML, scoped styles, a small script block - is easier to ramp up on than JSX or template directives for designers and HTML-first developers.
  • Teams who like to read the framework's source. Svelte's runtime is small enough that you can read it. Some teams genuinely value being able to see the bottom of the stack.

Where Svelte fits less well is the inverse: large teams with a deep React or Angular hiring pool, ecosystems that depend on a specific React-only library, or projects that need a framework feature that only React or Angular has shipped yet. Svelte's community is healthy but smaller, and "is there a battle-tested library for this exact problem" sometimes answers "not yet."

For the broader picture - where Svelte sits next to Angular, React, and Vue - read Modern web app frameworks. For the toolchain underneath all of them, read What web developers need to know in 2026.

References