Was ist SvelteKit?

Svelte ist nicht SvelteKit

Diese zwei Wörter werden ständig verwechselt. Der Unterschied ist aber wichtig, sonst suchst du in der falschen Doku.

Svelte ist die Programmiersprache, in der du UI-Komponenten schreibst. Eine .svelte-Datei ist eine Komponente — ein Button, eine Karte, ein Eingabefeld. Svelte sagt dir, wie du eine Komponente baust. Mehr nicht.

SvelteKit ist eine Sammlung aus Werkzeugen, die aus Svelte-Komponenten eine echte Webseite macht. Es kümmert sich um Fragen wie:

• „Welche URL zeigt welche Seite?”
• „Wie lade ich Daten aus einer Datenbank?”
• „Wie sende ich ein Formular an den Server?”
• „Wie deploye ich die fertige App auf einen Hoster?”

Eine Analogie: Svelte ist der Hammer, mit dem du Wände baust. SvelteKit ist der Bauplan für ein ganzes Haus — Statik, Anschlüsse, Eingangstür inklusive. Du brauchst beide.

Wer aus der React-Welt kommt: Svelte entspricht React, SvelteKit entspricht Next.js. Wer aus Vue kommt: Svelte = Vue, SvelteKit = Nuxt.

Was bringt SvelteKit konkret mit?

Sechs Bereiche, die ohne SvelteKit Eigenarbeit wären:

Daneben gibt es kleinere Werkzeuge — Hook-Funktionen für Auth-Middleware, ein Image-Component, ein Routing-Helfer für Programmatische Navigation. Aber die sechs oben sind die eigentlichen Argumente für SvelteKit.

Was lässt SvelteKit dir frei?

Genauso wichtig wie die Liste der Features ist die Liste der Dinge, die SvelteKit nicht vorschreibt:

• Datenbank-Auswahl — du verbindest dich, womit du willst (Postgres, SQLite, ORM oder kein ORM).
• Auth-Library — keine eingebaute Lösung. Es gibt ergänzende Pakete wie Lucia oder Auth.js, aber die Wahl liegt bei dir.
• CSS-Lösung — Sveltes Scoped Styles, Tailwind, eigene Stylesheets. SvelteKit hat keine Präferenz.
• State-Management auf App-Ebene — $state in .svelte.ts-Modulen, klassische Stores, oder eine Library deiner Wahl.
• UI-Library — Material, daisyUI, Skeleton, eigene Komponenten. SvelteKit liefert keine vorgefertigten Komponenten.

Das ist anders als bei stärker meinungs-orientierten Frameworks (Angular, Nuxt mit Module-System). SvelteKit gibt dir eine App-Architektur, lässt aber die meisten Tooling-Entscheidungen offen.

Wie deine Seite zum Browser kommt — drei Wege

Eine Webseite muss irgendwie ins Browser-Fenster gelangen. Es gibt drei klassische Strategien dafür, und SvelteKit beherrscht alle drei. Hier die Unterschiede in Alltagssprache.

Variante 1: Der Server bereitet das HTML jedes Mal vor (SSR)

Der Browser fragt: „Gib mir die Seite /blog/anna.” Der Server schaut in der Datenbank nach, baut die Seite fertig zusammen und schickt das fertige HTML zurück. Der Browser bekommt sofort sichtbare Inhalte — keine Wartezeit, keine leere Seite.

Das nennt man Server-Side Rendering (SSR). Es ist der Default in SvelteKit, weil es zwei wichtige Vorteile hat:

• Suchmaschinen können sofort lesen, was auf der Seite steht. Wichtig für Marketing- und Inhalts-Seiten.
• Der Nutzer sieht den Inhalt sofort, auch bevor JavaScript geladen ist.

Nach dem ersten Anzeigen aktiviert ein kleines Stück JavaScript die Interaktivität (Klicks, Animationen, Reaktivität). Diesen Vorgang nennt man Hydration — der Browser „belebt” das fertige HTML.

Variante 2: Der Browser baut die Seite selbst (CSR)

Hier macht der Server praktisch nichts. Er schickt eine leere HTML-Hülle plus eine JavaScript-Datei. Erst der Browser führt das JavaScript aus und baut daraus die UI auf.

Das ist Client-Side Rendering (CSR) und das klassische Verhalten einer Single-Page-Application. Vorteile: Sehr einfacher Server, weniger CPU-Last beim Hoster. Nachteile: Der Nutzer sieht für einen Moment eine leere Seite, Suchmaschinen sehen nur das leere Skelett.

In SvelteKit kannst du CSR pro Seite einschalten — sinnvoll etwa im eingeloggten Bereich, wo SEO sowieso keine Rolle spielt.

Variante 3: Die Seite ist schon vor dem Deployment fertig (SSG)

Wenn deine Inhalte sich nur selten ändern (Marketing-Seite, Blog, Doku), kannst du sie schon beim Build in fertige HTML-Dateien verwandeln. Beim Hosten werden diese Dateien einfach so ausgeliefert — kein Server muss bei jedem Request rechnen.

Das nennt sich Static Site Generation (SSG) oder auch Prerendering. Es ist die schnellste und günstigste Variante: Eine statische Datei kann ein CDN ausliefern, ohne überhaupt einen Server zu brauchen.

Das Schöne: Du musst dich nicht für eine Variante entscheiden

In SvelteKit kannst du pro Seite festlegen, welche Strategie zum Einsatz kommt:

• / und /about als prerendered (statisch, ändern sich kaum).
• /blog/[slug] mit SSR (frisch aus der Datenbank, mit SEO).
• /dashboard als CSR (eingeloggter Bereich, kein SEO nötig).

Alles aus einem einzigen Code-Stand, ein einziger Build. Dieses Mischen ist eine der größten Stärken von SvelteKit.

Wann reicht reines Svelte?

Es gibt Fälle, in denen SvelteKit Overkill ist. Reines Svelte (mit Vite als Build-Tool) reicht aus, wenn:

• Du eine eingebettete Komponente baust, die in eine fremde Seite geladen wird.
• Du eine interne SPA baust, die hinter einem Login läuft und kein SEO braucht.
• Du eine kleine Demo oder ein Plugin baust, das keinen eigenen Server-Teil hat.
• Du eine Komponenten-Library publizierst, die später in andere Apps importiert wird.

In allen anderen Fällen — vor allem für öffentliche Web-Anwendungen mit eigenem Server-Teil — ist SvelteKit der richtige Einstieg. Du sparst dir Routing-Library, SSR-Setup, eigene API-Endpoint-Architektur und Build-Konfiguration.

Adapter: Wie kommt der Code aufs Hosting?

Ein Detail, das SvelteKit besonders machte: Der gleiche Code läuft auf sehr unterschiedlichen Hosting-Umgebungen, weil SvelteKit selbst hosting-agnostisch ist. Was den Output an die jeweilige Umgebung anpasst, ist der Adapter.

Ein Adapter wird in svelte.config.js eingestellt — und wechselt sich beim Hosting-Wechsel im Idealfall mit zwei Code-Zeilen. Der eigentliche App-Code bleibt unverändert.

Ein Mini-Eindruck: Wie eine SvelteKit-Route aussieht

Damit klarer wird, wie SvelteKit-Code in der Praxis aussieht — eine Beispielroute, die einen User aus einer Datenbank lädt und anzeigt:

import { error } from '@sveltejs/kit';
import { db } from '$lib/server/db';

export async function load({ params }) {
    const user = await db.user.findUnique({ where: { id: params.id } });
    if (!user) error(404, 'User nicht gefunden');
    return { user };
}

<script>
    let { data } = $props();
</script>

<h1>{data.user.name}</h1>
<p>{data.user.email}</p>

Was hier passiert:

• Der Pfad users/[id] wird zur URL /users/<id>. [id] ist ein dynamisches Segment.
• +page.server.ts läuft nur auf dem Server — sicher für Datenbank-Zugriff, Secrets, etc.
• Die load-Funktion liefert data, das automatisch an +page.svelte übergeben wird.
• Wenn der User nicht existiert, wirft error(404, ...) — SvelteKit zeigt eine 404-Seite.
• Im Markup ist data typisiert verfügbar.

Aus einer einzigen Datei (oder hier: zwei kleinen Dateien) entsteht eine vollwertige, gerenderte Seite mit Server-Render, Datenladen und Fehlerbehandlung.

Wer steht hinter SvelteKit?

SvelteKit wird vom Svelte-Team entwickelt — den gleichen Leuten, die auch Svelte selbst pflegen. Vercel hat die Hauptentwickler in Vollzeit angestellt, was dem Projekt eine sehr stabile Entwicklungsbasis gibt. Trotz Vercel-Sponsoring läuft SvelteKit auf jedem Hoster, nicht nur auf Vercel — der Adapter-Mechanismus macht das möglich.

Das Release-Modell ist konservativ: Major-Versionen erscheinen selten, mit klar dokumentierten Migrations-Pfaden. Der Wechsel von SvelteKit 1 auf 2 brauchte ein paar Anpassungen, war aber überschaubar.

FAQ — die häufigsten Einsteiger-Fragen

Ist SvelteKit Svelte 5? Nein, das sind zwei verschiedene Dinge. Svelte 5 ist die Sprach-Version (also wie deine Komponenten geschrieben werden — mit Runes wie $state). SvelteKit ist das Framework (also Routing, Server-Logik, Build). Die heutige Standard-Kombination ist SvelteKit 2 mit Svelte 5. Es gibt aber auch alten Code mit SvelteKit 1 plus Svelte 4.

Brauche ich SvelteKit, wenn ich nur eine kleine App baue? Nicht zwingend. Wenn du nur eine einzelne Seite ohne Routing oder Server-Anteil baust, reicht reines Svelte mit Vite. Sobald du aber mehrere URLs, ein Login oder Daten aus einer Datenbank willst, ist SvelteKit der einfachere Weg.

Muss ich auf Vercel hosten? Nein. SvelteKit wurde zwar von Vercel mitfinanziert, läuft aber auf jedem Hoster: dem eigenen Node-Server, Cloudflare, Netlify, einem statischen CDN. Was den Build an die jeweilige Umgebung anpasst, ist der Adapter — siehe Abschnitt vorher.

Brauche ich Server-Side-Rendering, wenn meine App ein Login hat? Nicht unbedingt. Der eingeloggte Bereich kann auch im Client-Side-Rendering laufen — SEO ist dort sowieso egal, weil Suchmaschinen den Bereich nicht sehen sollen. Du kannst SSR pro Route ausschalten.

Kann ich SvelteKit mit einer separaten Backend-API kombinieren? Ja, das ist sogar üblich. Du kannst SvelteKit als reines Frontend gegen eine bestehende REST- oder GraphQL-API laufen lassen. Alternativ schreibst du die API direkt in SvelteKit als +server.ts-Dateien. Beide Wege sind valide — die Wahl hängt davon ab, ob du das Backend separat halten willst (wegen Sprache, Team-Aufteilung, Deployment).

Muss ich TypeScript verwenden? Nein. SvelteKit funktioniert auch mit reinem JavaScript. TypeScript ist aber sehr empfehlenswert, weil viele SvelteKit-Features (Type-Inference von load-Funktionen, automatische Route-Types) damit deutlich angenehmer werden.

Was passiert mit JavaScript-deaktivierten Browsern? Da SvelteKit standardmäßig SSR macht, sehen auch Nutzer ohne JavaScript die fertigen Seiten. Form-Submits funktionieren über klassische HTML-Forms (Form Actions), Klicks auf Links navigieren wie gewohnt. Das ist ein angenehmer Nebeneffekt der Architektur — du musst nichts extra dafür tun.

Kann ich mehrere SvelteKit-Apps in einer Domain mischen? Theoretisch ja, praktisch unüblich. Wenn dein Projekt so groß ist, dass es in mehrere Bereiche zerfallen soll, sind Layout-Gruppen ((name)-Ordner) oder Subdomains die saubereren Lösungen.

Weiterführende Ressourcen

Externe Quellen

• SvelteKit – Documentation
• SvelteKit – Project Structure
• Svelte vs. SvelteKit – Stack Overflow Diskussion

Verwandte Artikel

• Setup mit SvelteKit
• Projektstruktur
• Filesystem-Routing
• SvelteKit Routing & Loading