What is SvelteKit? — SvelteKit Tutorial

Svelte compiles your components into small, fast vanilla JavaScript — but a component on its own doesn't know how to become a website. Something has to decide which component renders for which URL, fetch the data it needs before it renders, render it on the server for the first request, and bundle everything for production. That "something" is SvelteKit.

If you already know Svelte's component model — $state, props, events — this course doesn't repeat that. It focuses on everything SvelteKit adds around your components: routing, data loading, server rendering, and forms.

A framework, not just a compiler

Svelte is a compiler: it turns .svelte files into JavaScript. SvelteKit is a full application framework built on top of it, comparable to what Next.js is to React. It gives you:

File-based routing — the folder structure under src/routes/ is your app's URL structure.
Server-side rendering (SSR) — pages render to HTML on the server first, then "hydrate" into an interactive app in the browser.
Data loading — load functions fetch data before a page renders, so components don't render in a loading state by default.
Form handling — server-side form actions that work even before JavaScript loads.
A build system — powered by Vite, with adapters that package your app for different hosts.

Why not just Svelte alone?

You can ship a Svelte app without SvelteKit — mount a root component onto a <div> and let it render entirely in the browser, like a classic single-page app. That works for small widgets, but it means:

// A plain Svelte app: everything happens client-side
import { mount } from 'svelte';
import App from './App.svelte';

mount(App, { target: document.getElementById('app') });

The browser downloads an empty HTML shell, then JavaScript, then finally renders anything — slower first paint, worse SEO.
You'd hand-roll routing, code-splitting, and data fetching yourself.
There's no server to hide API keys or run database queries safely.

What a SvelteKit project looks like

my-app/
├── src/
│   ├── routes/          # file-based routes live here
│   │   ├── +page.svelte # the homepage
│   │   └── about/
│   │       └── +page.svelte
│   ├── lib/              # shared code, imported via "$lib"
│   └── app.html          # the HTML shell SvelteKit fills in
├── static/               # files served as-is (favicon, robots.txt)
└── svelte.config.js

Every file prefixed with + — +page.svelte, +layout.svelte, +page.server.js — has special meaning to SvelteKit's router. Plain files and folders (like src/lib/) are just your own code, organized however you like.

Where this course is headed

The rest of this course walks through those +-prefixed files one at a time: how routing maps folders to URLs, how load functions fetch data, how layouts share UI across pages, how form actions handle submissions, and how to deploy the result. By the end, you'll understand not just Svelte components, but the machinery that turns them into a real, production-ready web application.

A framework, not just a compiler

Svelte is a compiler: it turns .svelte files into JavaScript. SvelteKit is a full application framework built on top of it, comparable to what Next.js is to React. It gives you:

File-based routing — the folder structure under src/routes/ is your app's URL structure.

Server-side rendering (SSR) — pages render to HTML on the server first, then "hydrate" into an interactive app in the browser.

Data loading — load functions fetch data before a page renders, so components don't render in a loading state by default.

Form handling — server-side form actions that work even before JavaScript loads.

A build system — powered by Vite, with adapters that package your app for different hosts.

Why not just Svelte alone?

// A plain Svelte app: everything happens client-side
import { mount } from 'svelte';
import App from './App.svelte';

mount(App, { target: document.getElementById('app') });

The browser downloads an empty HTML shell, then JavaScript, then finally renders anything — slower first paint, worse SEO.

You'd hand-roll routing, code-splitting, and data fetching yourself.

There's no server to hide API keys or run database queries safely.

What a SvelteKit project looks like

my-app/ ├── src/ │ ├── routes/ # file-based routes live here │ │ ├── +page.svelte # the homepage │ │ └── about/ │ │ └── +page.svelte │ ├── lib/ # shared code, imported via "$lib" │ └── app.html # the HTML shell SvelteKit fills in ├── static/ # files served as-is (favicon, robots.txt) └── svelte.config.js

Where this course is headed