What is Svelte? A guide to the compiler-first JavaScript framework

Most JavaScript frameworks ship a runtime to the browser. React sends its reconciler, Vue sends its reactivity engine, and both have to load before your components can do anything. Svelte handles that work at compile time. Its compiler reads your .svelte files and writes the DOM updates directly into the build output, so what ships to the browser is mostly your app code, not the framework.

This guide covers how the Svelte compiler works, what runes changed in Svelte 5, how Svelte compares with other frameworks, and how to deploy a SvelteKit app on Vercel.

Link to headingWhat is Svelte?

Svelte is a compiler-first JavaScript framework for building user interfaces on the web. It compiles .svelte component files into vanilla JavaScript at build time, so the framework itself largely disappears before the browser loads a page.

Its creator, Rich Harris, leads development from Vercel. In the 2024 Stack Overflow Developer Survey, 72.8% of developers who used Svelte said they want to continue working with it.[1] The framework covers components, reactivity, scoped styles, and transitions, while SvelteKit extends it into a full application framework with routing and server-side rendering.

Link to headingHow Svelte works

Svelte's core idea is to move framework work out of the browser and into the build step. The compiler reads component templates, determines where state can change, and writes the exact DOM operations that will run at runtime. Three architectural choices shape how that plays out in practice.

Link to headingCompile-time versus runtime frameworks

React and Vue ship a runtime library to the browser. That runtime tracks state, computes what changed, and applies updates on every render cycle. Svelte runs the same analysis at build time instead, so the browser receives targeted update code rather than a general-purpose reactivity engine.

The visible effect is a smaller JavaScript payload and fewer abstractions between component code and the DOM. You still write components in a declarative style, but the output is imperative JavaScript generated by the compiler for that specific component.

Link to headingNo virtual DOM

Svelte skips the virtual DOM that most component frameworks use to decide what to update. In a virtual-DOM model, the framework keeps an in-memory copy of the rendered UI and diffs two versions on every state change before touching the real DOM. Harris argued against that pattern in pure overhead, where he walked through the hidden costs of diffing work that happens before any actual DOM update.

Svelte takes a different path. Because the compiler already knows which values can change and which DOM nodes depend on them, it generates targeted update instructions for each reactive variable. State changes skip diffing and go straight to the affected nodes, which means the browser spends its time on real work rather than bookkeeping.

Link to headingSignals-based reactivity through runes

Svelte 5, released on October 22, 2024, replaced the implicit reactivity of earlier versions with explicit runes. A rune looks like a function call but behaves as a compiler instruction, which makes the reactivity graph visible in the source code instead of hidden inside let bindings and $: labels.

The core runes are $state, $derived, $effect, and $props, with $bindable, $inspect, and $host covering more specific cases. Declaring let count = $state(0) creates a reactive number you can read and write like any variable, and when it changes, only the effects and derived values that depend on it re-run.

Link to headingKey features of Svelte

Svelte ships a small set of primitives that cover most of what teams build in day-to-day UI work. Each one leans on the compiler to keep runtime behavior predictable and bundles lean.

The features that define the framework include:

• Single-file components: Each .svelte file contains an optional <script> block for logic, HTML markup for the template, and a <style> block for styles, so logic, structure, and presentation live together in one place without extra tooling.

• Scoped CSS by default: Styles declared inside a component apply only to that component through generated class names, with a :global() modifier for rules that need wider reach. That keeps component styles isolated without the runtime cost of a CSS-in-JS layer.

• Runes for reactivity: The $state, $derived, and $effect runes make reactive dependencies explicit and easier to reason about. They also work in plain .svelte.js and .svelte.ts modules, so reactive logic can live outside component files when it makes sense.

• Stores for shared state: Writable and readable stores from the original API still work in Svelte 5. Codebases built before runes can adopt the new syntax gradually, one component at a time, without a full rewrite.

• Built-in transitions and animations: The transition: and animate: directives handle enter, exit, and list-reorder animations through a compiler-level API, without pulling in a separate animation library.

• Compiled output: The compiler emits imperative update code for each component, so applications ship without the general runtime layer that runtime-first frameworks bundle alongside application logic.

Taken together, these primitives explain why a .svelte file reads like plain HTML with a light layer of logic on top. The compiler absorbs the complexity, so the component file stays close to what the DOM will render.

Link to headingSvelte versus SvelteKit

Svelte is the component framework. SvelteKit is the full application framework built on top of it, adding file-based routing, server-side rendering, data loading, and deployment adapters. The relationship mirrors React and Next.js, or Vue and Nuxt.

A SvelteKit project lives under src/routes/, where each directory maps to a URL path and each +page.svelte file becomes a page. Routes can export data-loading functions, form actions, and rendering configuration, and the framework stitches those pieces together at build time. Adapters then translate the build output for the target platform, whether that is a Node.js server, a static host, or a serverless runtime. Running npx sv create my-app scaffolds a SvelteKit project with sensible defaults, and the same project can grow from a single static page into a full server-rendered application without switching frameworks.

Link to headingHow Svelte compares with other frameworks

Framework decisions come down to ecosystem depth, team background, and the rendering model each framework favors. The comparisons below focus on those architectural dimensions, not marketing differences.

Here is how Svelte lines up against the three alternatives teams evaluate most often:

• Svelte vs. React: React ships a runtime that reconciles a virtual DOM on each render, while Svelte compiles that work away at build time. React's ecosystem is deeper for third-party component libraries, authentication flows, and UI kits. Svelte ships less framework code to the browser and reports higher sustained developer satisfaction on the annual Stack Overflow survey, which is why some teams prefer it for UI-heavy products.

• Svelte vs. Vue: Both use single-file components and feel similar to write on the surface. Vue's reactivity runs in the browser through a proxy-based system, while Svelte's runs through the compiler. Vue has the larger package ecosystem and broader hiring pool, while Svelte keeps less framework logic in the shipped bundle and produces a smaller runtime footprint.

• Svelte vs. Angular: Angular covers a larger surface area with dependency injection, RxJS, and opinionated tooling designed for long-lived enterprise codebases. Svelte asks for less boilerplate and fits smaller teams and greenfield projects that prefer fewer framework conventions. The two frameworks target different points on the spectrum from explicit structure to minimal scaffolding.

Each framework has a place, and the right choice depends on the team writing the code. Svelte tends to come up first when bundle size, UI performance, or developer ergonomics carry more weight than ecosystem breadth, while React and Angular come up first when ecosystem size or structural opinions matter more.

Link to headingWhen Svelte is the right fit

Svelte earns its place when shipped code needs to stay close to the product you wrote. The compiler-first model keeps runtime overhead low and closes the gap between component source and browser behavior across the lifetime of a project.

The clearest fits for Svelte include:

• Performance-sensitive interfaces: Marketing pages, dashboards, and consumer apps where initial load and interaction latency drive engagement benefit from a smaller JavaScript footprint and fewer runtime abstractions.

• Small-to-medium product teams: Low boilerplate and single-file components reduce coordination overhead across engineers and designers shipping the same product. Fewer framework conventions also mean fewer decisions to litigate in code review.

• Content-heavy sites with selective interactivity: SvelteKit's per-route rendering modes let one codebase mix static generation, server rendering, and client-side pages, which matches how real content sites are built.

• Greenfield projects: Starting without legacy constraints means teams can adopt runes, scoped styles, and adapter-based deployment from day one, without a migration layer to maintain.

Team context still shapes the decision. Existing React or Angular codebases, specialized third-party component libraries, and hiring conditions all weigh in when committing to a framework for the next three years. Evaluating Svelte against those constraints up front is cheaper than discovering them after the first production release.

Link to headingGet started with Svelte

The fastest way to build a new app with Svelte is to start with SvelteKit (Svelte’s official app framework). It gives you routing, server-side rendering, and adapters for deployment, and you can still use it to ship purely client-side pages when you want. A working SvelteKit project takes a single command. The scaffolding CLI creates the directory layout, installs dependencies, and launches the dev server on localhost:5173.

Link to headingScaffolding a new project

Create a new SvelteKit app with the official CLI:

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

The CLI prompts for a template, TypeScript or JavaScript, and optional integrations like ESLint, Prettier, Playwright, and Tailwind CSS. Each choice wires up the project so the first npm run dev serves a working application at http://localhost:5173 with hot module replacement enabled.

Link to headingUnderstanding the project layout

A SvelteKit project separates application code, routes, and static assets at the directory level. The src/routes/ directory defines URL paths, where +page.svelte renders a page, +page.server.js runs server-only data loading, and +server.js exposes API endpoints. The src/lib/ directory holds shared components and utilities, with $lib as an import alias. The static/ directory serves files as-is from the project root, and svelte.config.js at the root configures the adapter that ships the build output to the target platform.

Link to headingWriting your first component

A .svelte file combines state, markup, and styles in one place. Here is a minimal counter:

<script>
  let count = $state(0);
</script>

<button onclick={() => count++}>
  Clicked {count} times
</button>

<style>
  button {
    font-size: 2em;
  }
</style>

The $state rune makes count reactive, the inline handler updates it on each click, and the style block scopes the font size to this button only. Saving the file triggers hot module replacement, and the counter updates in the browser without a full page reload.

Link to headingDeploy your Svelte app on Vercel

SvelteKit on Vercel gives Svelte projects a zero-config deployment path. New projects use adapter-auto, which detects Vercel during the build and swaps in the Vercel adapter automatically, while projects that need version pinning can install @sveltejs/adapter-vercel directly.

Once the project connects to GitHub, GitLab, or Bitbucket, Vercel handles the full deployment workflow:

• Git-based deployments: Every push produces a production build, and every pull request opens a

  preview deployment with its own URL, so reviewers see the exact change before it merges.

• Per-route rendering: Each SvelteKit page can run as static HTML, as a server-rendered response on

  Vercel Functions, or as Incremental Static Regeneration output that revalidates on a schedule, all within the same project.

• Active CPU execution: Server-rendered routes run on Fluid compute, which keeps warm instances in place, charges only for active CPU time, and handles concurrent requests on a single instance, so I/O-bound routes use fewer resources.

• Observability and domains: Adding Web Analytics through @vercel/analytics/sveltekit captures real traffic data, and production apps receive automatic HTTPS with custom domains attached in the project settings.

Route-level configuration lives in an exported config object on each +page.server.js or +server.js, which means teams can tune runtime, regions, and revalidation per endpoint rather than project-wide. That granularity matches how SvelteKit already thinks about rendering, so infrastructure decisions stay alongside application code.

Link to headingShip your next web app with Svelte

Svelte gives teams a framework that mostly compiles away before production. The build emits targeted JavaScript, runes make reactivity explicit, and SvelteKit extends the model into a full application framework with routing, data loading, and deployment adapters. That combination lets a single project grow from a static marketing page into a server-rendered product without switching frameworks.

On Vercel, SvelteKit projects get framework detection, preview deployments, Fluid compute, and ISR with no extra configuration. If you want a starting point you can deploy quickly, browse the SvelteKit templates to see working examples across marketing sites, commerce, and authentication — and then deploy a template directly from the gallery.

Link to headingFrequently asked questions about Svelte

Link to headingIs Svelte frontend or backend?

Svelte is a frontend component framework that compiles UI components into JavaScript for the browser. SvelteKit extends it into a full-stack framework with server-rendered routes, API endpoints defined in +server.js files, and data loading through load functions that can run on the server or the client. Both deploy together on Vercel with no separate backend setup, and server code runs on Vercel Functions alongside the static and ISR assets.

Link to headingIs Svelte good for large-scale applications?

Svelte scales well when teams adopt SvelteKit for routing, data loading, and deployment. Per-route rendering modes let one codebase serve static marketing pages, server-rendered dashboards, and ISR-cached content from the same project, so different parts of an application can use the rendering strategy that fits each surface. Vercel's Fluid compute and Incremental Static Regeneration handle the production execution side, which keeps engineering focus on application code rather than deployment plumbing.

Link to headingWho uses Svelte in production?

Svelte is used in production by many organizations, and the official Svelte website maintains a non-exhaustive “used by” list. If you need a concrete starting point rather than examples of who uses it, the SvelteKit templates gallery on Vercel is a faster way to see real, deployable apps.

Link to headingIs Svelte free and open source?

Yes. Svelte, SvelteKit, and their official deployment adapters are MIT-licensed and hosted on GitHub under the sveltejs organization. Contributions run through public issue trackers and release notes, and the framework accepts community pull requests for both core and ecosystem packages. The @sveltejs/adapter-vercel package provides the official integration for deploying SvelteKit projects on Vercel.