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](https://vercel.com/i/what-is-sveltekit) app on Vercel.

## [Copy link to heading](#what-is-svelte)What 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](/blog/vercel-welcomes-rich-harris-creator-of-svelte), 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\]](https://survey.stackoverflow.co/2024/) The framework covers components, reactivity, scoped styles, and transitions, while SvelteKit extends it into a full application framework with routing and server-side rendering.

## [Copy link to heading](#how-svelte-works)How 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.

### [Copy link to heading](#compile-time-versus-runtime-frameworks)Compile-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.

### [Copy link to heading](#no-virtual-dom)No 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](https://svelte.dev/blog/virtual-dom-is-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.

### [Copy link to heading](#signals-based-reactivity-through-runes)Signals-based reactivity through runes

[Svelte 5](https://svelte.dev/blog/svelte-5-is-alive), 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.

## [Copy link to heading](#key-features-of-svelte)Key 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.

## [Copy link to heading](#svelte-versus-sveltekit)Svelte versus SvelteKit

Svelte is the component framework. [SvelteKit](https://vercel.com/i/what-is-sveltekit) is the [full application framework](https://vercel.com/i/full-stack-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](https://vercel.com/i/what-is-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.

## [Copy link to heading](#how-svelte-compares-with-other-frameworks)How 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.

## [Copy link to heading](#when-svelte-is-the-right-fit)When 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.

## [Copy link to heading](#get-started-with-svelte)Get 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`.

### [Copy link to heading](#scaffolding-a-new-project)Scaffolding 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.

### [Copy link to heading](#understanding-the-project-layout)Understanding 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.

### [Copy link to heading](#writing-your-first-component)Writing 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.

## [Copy link to heading](#deploy-your-svelte-app-on-vercel)Deploy your Svelte app on Vercel

[SvelteKit on Vercel](https://vercel.com/docs/frameworks/full-stack/sveltekit) 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](https://vercel.com/docs/deployments/environments) 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](https://vercel.com/docs/functions), or as [Incremental Static Regeneration](https://vercel.com/docs/incremental-static-regeneration) output that revalidates on a schedule, all within the same project.

- **Active CPU execution:** Server-rendered routes run on [Fluid compute](https://vercel.com/docs/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](https://vercel.com/docs/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.

## [Copy link to heading](#ship-your-next-web-app-with-svelte)Ship 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](https://vercel.com/templates/svelte) to see working examples across marketing sites, commerce, and authentication — and then deploy a template directly from the gallery.

## [Copy link to heading](#frequently-asked-questions-about-svelte)Frequently asked questions about Svelte

### [Copy link to heading](#is-svelte-frontend-or-backend)Is 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.

### [Copy link to heading](#is-svelte-good-for-large-scale-applications)Is 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](https://vercel.com/docs/fluid-compute) and Incremental Static Regeneration handle the production execution side, which keeps engineering focus on application code rather than deployment plumbing.

### [Copy link to heading](#who-uses-svelte-in-production)Who 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](https://vercel.com/templates/svelte) gallery on Vercel is a faster way to see real, deployable apps.

### [Copy link to heading](#is-svelte-free-and-open-source)Is 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.