What Is SvelteKit and What Can You Build with It?
Updated
SvelteKit is an application framework built on top of Svelte, a compiler-based UI framework. Where Svelte handles components and reactivity, SvelteKit adds the surrounding application layer: file-based routing, server-side rendering (SSR), data loading, and a build system that can target both server and static output. You would choose it when you want a full web application structure rather than a component library alone. A concrete example is MarkD, a live Markdown editor described as "built with SvelteKit from scratch."
SvelteKit vs. plain Svelte
The distinction matters because the two are often mentioned together.
| Dimension | Svelte (the framework) | SvelteKit (the application framework) |
|---|---|---|
| Scope | Components, reactivity, compiled output | Full app: routing, rendering, data, build |
| Routing | Not included | File-based routes |
| Rendering | Client-side by default | SSR, client-side, or prerendered output |
| Data loading | Handled by your own code | Built-in load functions per route |
| Typical use | Widgets, embedded components | Multi-page apps, content sites, editors |
If you only need interactive components inside an existing page, plain Svelte is enough. If you need pages, URLs, server rendering, or a deployable app, SvelteKit is the layer that provides them.
Core capabilities
File-based routing
Routes are defined by the file structure of your project. A page file maps to a URL, and nested directories map to nested paths. This removes the need to hand-wire a router and keeps navigation structure visible in the filesystem.
Rendering modes
SvelteKit supports server-side rendering, client-side rendering, and prerendering to static HTML. The choice can be made per route, so a marketing page can be static while an interactive editor runs on the client.
Data loading
Each route can define a load function that fetches or computes data before the page renders. This separates data concerns from presentation and works in both server and client contexts.
Build and deployment
The build step produces output for a chosen adapter, which determines whether the app runs on a Node server, a static host, or another target. This is what makes a single codebase deployable in different environments.
A real example: MarkD
MarkD is an "advanced, opinionated live Markdown editor built with SvelteKit from scratch." Its interface shows the kind of client-side interactivity SvelteKit apps commonly host:
- A live character, word, and reading-length counter, visible in the page excerpt as "Characters: 0 • Words: 0 • Length: 0 minutes"
- A Write/Preview toggle for switching between editing and rendered output
- Scroll sync between the editing field and the preview
- A keyboard interaction: "Press ESC then TAB to move the focus off the field"
These are reactive UI behaviors — state changes in the editor immediately update counters and preview. SvelteKit provides the application shell around them: the page route, the build, and the rendering strategy, while Svelte's reactivity drives the live updates. The site's own keywords list it as free and open-source; no pricing or login details are stated on the page, so treat access terms as unconfirmed beyond that description.
When to choose SvelteKit
Choose it when:
- You are building a multi-page application with real URLs and navigation.
- You want server-side rendering or prerendering for performance or SEO.
- You want routing and data loading handled by the framework rather than assembled from separate libraries.
- You are comfortable with Svelte's component syntax and want to scale it to a full app.
Consider alternatives when you only need a few interactive components on an otherwise static page, or when your team is already standardized on another framework's ecosystem.
What to know before starting
- Prerequisites: familiarity with HTML, CSS, and JavaScript, plus basic Svelte component syntax (props, state, markup expressions).
- Mental model shift: routes are files, and data loading is a per-route concern rather than a global store pattern.
- Adapter choice: decide early whether you need a server runtime or static output, since the adapter shapes your deployment.
- Verification: after scaffolding a project, run the development server and confirm that a route renders, that a load function returns expected data, and that the production build completes for your target adapter.
A practical first task, mirroring MarkD's design, is a single-page editor with a textarea, a live word count, and a preview pane — enough to exercise routing, reactivity, and a build without adding complexity.