Wenn Sie die letzten Jahre damit verbracht haben, zwischen Meta-Frameworks hin- und herzuwechseln, wird sich SvelteKit 2 wie eine seltsame Mischung aus Erleichterung und Misstrauen anfühlen. Erleichterung, weil es Komplexität tatsächlich reduziert, anstatt sie zu erhöhen. Misstrauen, weil man ständig darauf wartet, dass der nächste Fehler auftaucht. Doch das passiert nie wirklich. Zusammen mit Svelte 5 ist dieser Stack einer der produktivsten Wege, um im Jahr 2026 eine Full-Stack-Anwendung zu veröffentlichen, und die Zahlen belegen die hervorragende Developer Experience. Die Bundles sind etwa 35 % kleiner als die von Svelte 4. Routing, Server-Funktionen und Authentifizierungsmuster sind allesamt First-Class-Citizens und keine Plugins, die man nur provisorisch zusammenklebt.

Die Runes machen Reaktivität explizit

Der größte mentale Umbruch kommt durch die Runes von Svelte 5. Frühere Svelte-Versionen nutzten das $:-Label und viel Compiler-Magie, um Abhängigkeiten zu verfolgen. Das funktionierte zwar, aber wenn etwas kaputtging, debuggte man unsichtbare Verbindungen. Runes ersetzen diese Magie durch explizite Funktionen. Sie sagen dem Compiler genau, was er verfolgen soll, und er hört zu.

Hier ist das, was Sie wissen müssen.

  • $state verwaltet reaktive Variablen. Umschließen Sie jeden Wert mit $state(), und der Compiler weiß, dass er ihn beobachten muss.
  • $derived berechnet Werte aus anderem State. Benötigen Sie eine gefilterte Liste oder eine formatierte Summe? Nutzen Sie $derived. Der entscheidende Unterschied zu $effect ist, dass $derived für Werte und nicht für Aktionen gedacht ist.
  • $effect führt Side-Effects aus. Denken Sie an Aktualisierungen des Dokumenttitels, manuelle DOM-Messungen oder Timer, die ein Cleanup benötigen. Er wird ausgeführt, nachdem das DOM committet wurde – ähnlich wie ein Lifecycle-Hook, aber an spezifische reaktive Abhängigkeiten gebunden.
  • $props ersetzt das alte export let-Muster für die Datenübergabe in Komponenten. Es ist klarer und harmoniert besser mit TypeScript.

Dieses Modell zahlt sich in der Praxis aus. Da der Compiler nur das verfolgt, was Sie markieren, bleibt toter Code auch tot. Sie müssen sich nicht mehr fragen, warum eine Variable ein Update ausgelöst hat, sondern können Ihren eigenen expliziten Anweisungen vertrauen.

Routing über Ordner, nicht über Konfiguration

SvelteKit nutzt Ihr Dateisystem für das Routing. Es gibt keine separate Router-Datei, die gepflegt werden muss. Legen Sie eine +page.svelte-Datei in ein Verzeichnis, und dieses Verzeichnis wird zu einer Live-Route.

Gemeinsame UI-Elemente umschließen diese Routen über +layout.svelte. Platzieren Sie eine im Root-Verzeichnis, und jede untergeordnete Route erbt sie. Platzieren Sie eine tiefer im Baum, und nur dieser Abschnitt erhält den Wrapper.

Die Server-Logik lebt in +page.server.ts. Diese wird ausgeführt, bevor Ihre Seite gerendert wird, sodass Sie dort Datenbanken abfragen, Cookies validieren oder nicht authentifizierte Benutzer abweisen können. Die Typen fließen automatisch von Ihrer load-Funktion in Ihre Page-Komponente, was bedeutet, dass Ihre Daten typisiert sind, ohne dass Sie manuell Interfaces schreiben müssen.

Rohe API-Endpunkte gehören in +server.ts-Dateien. Diese exportieren Standard-HTTP-Handler – GET, POST, PUT, DELETE –, sodass der Aufbau eines REST-Backends neben Ihren Seiten ganz natürlich wirkt.

Eine unterschätzte Funktion: Group Routes. Indem Sie einen Ordnernamen in Klammern setzen, wie (auth), erstellen Sie ein gemeinsames Layout, ohne ein Segment zur URL hinzuzufügen. Dies ist perfekt für Login- und Signup-Seiten, die das gleiche reduzierte UI-Gerüst benötigen, aber unter /login und /signup erreichbar sein sollen, nicht unter /auth/login.

Daten, Sicherheit und Progressive Enhancement

Moderne Frameworks reden gerne über Full-Stack, aber viele lassen Sie im Unklaren darüber, wo Sie Auth-Checks oder Formularlogik platzieren sollen. SvelteKit bietet Ihnen klare Hooks.

Nutzen Sie +page.server.ts für das Datenabrufen. Die load-Funktion dort läuft ausschließlich auf dem Server, sodass Ihre Datenbank-Zugangsdaten niemals an den Browser gelangen. SvelteKit generiert Typen aus den Rückgabewerten Ihrer load-Funktion, sodass Ihr Frontend konsistent bleibt.

Nutzen Sie hooks.server.ts, um die gesamte Anwendung abzusichern. Dies wird bei jeder Anfrage ausgeführt, was es zum richtigen Ort macht, um Sessions zu verifizieren, das Ablaufdatum von JWTs zu prüfen oder den Benutzerkontext an eingehende Events anzuhängen.

Für Mutationen verwenden Sie Form Actions. Anstatt einen separaten API-Endpunkt anzubinden und JSON zu verarbeiten, definieren Sie eine Action innerhalb von +page.server.ts. Das Schöne daran ist das Progressive Enhancement. Wenn JavaScript nicht geladen werden kann – oder wenn ein Benutzer es deaktiviert hat – wird das Formular dennoch an die Server-Action gesendet und die Seite mit dem Ergebnis neu gerendert. Wenn JavaScript vorhanden ist, verbessert SvelteKit das Erlebnis, ohne dass ein vollständiger Reload nötig ist. Sie erhalten Resilienz und Eleganz aus demselben Code.

Eine Regel, die man im Hinterkopf behalten sollte: Führen Sie Berechnungen in $derived durch, nicht in $effect. Die Verwendung von $effect zur Berechnung von Werten kann Update-Schleifen auslösen, die schwer nachvollziehbar sind. Behalten Sie $effect für echte Side-Effects vor und überlassen Sie $derived Ihren berechneten State.

SvelteKit versus Next.js

Beide Frameworks können produktionsreife Anwendungen ausliefern, aber die Kompromisse sind real.

Bei der Bundle-Größe punktet SvelteKit. Da Svelte Komponenten in Vanilla-JavaScript kompiliert und den Virtual DOM vollständig umgeht, bleibt der Runtime-Footprint gering. Next.js schleppt die Reconciliation-Engine von React mit sich herum.

Auch die Reaktivität unterscheidet sich. SvelteKit löst Runes zur Kompilierzeit auf. Der Browser erhält einfache Updates. Next.js verlässt sich auf die Runtime-Hooks und die Reconciliation von React, was bedeutet, dass mehr Arbeit auf dem Client geleistet werden muss.

Das Onboarding ist mit SvelteKit leichter. Das mentale Modell ist weniger komplex. Man muss nicht mit useEffect-Dependency-Arrays oder Memoization-Rätseln jonglieren, um Re-Renders zu vermeiden. Auch die TypeScript-Integration verdient eine Erwähnung. Während beide Frameworks