Was ist Svelte?

Kurz gesagt: Was ist Svelte?

Svelte ist eine Sprache und ein Compiler zur Erstellung von Benutzeroberflächen. Du schreibst Komponenten in .svelte-Dateien, die HTML, CSS und JavaScript an einem Ort bündeln. Der Svelte-Compiler übersetzt sie zur Build-Zeit in normales JavaScript – ohne ein virtuelles DOM, ohne große Runtime im Bundle.

Eine minimale Svelte-Komponente sieht so aus:

<script>
    let name = 'Welt';
</script>

<h1>Hallo, {name}!</h1>

<style>
    h1 {
        color: teal;
    }
</style>

Drei Bereiche in einer Datei: Logik (<script>), Markup (HTML mit Svelte-Syntax) und Styles (<style>, automatisch scoped). Mehr braucht Svelte nicht.

Compiler statt Runtime

Der zentrale Unterschied zu React, Vue oder Angular ist der Zeitpunkt, zu dem die Arbeit erledigt wird.

• React / Vue / Angular: Sie liefern eine Runtime ans Browser-Bundle aus. Die Runtime baut zur Laufzeit ein virtuelles DOM auf, vergleicht alte und neue Bäume und aktualisiert das reale DOM.
• Svelte: Der Compiler weiß zur Build-Zeit, welche Werte reaktiv sind und welche DOM-Knoten beim Wechsel aktualisiert werden müssen. Er erzeugt direkt hochspezialisierten Code, der genau diese Stellen anfasst.

Das hat mehrere Konsequenzen:

• Kleinere Bundles, weil weniger Framework-Code mitkommt.
• Schnellere Updates in vielen Szenarien, weil keine Diff-Berechnung über einen virtuellen Baum nötig ist.
• Weniger Konzepte zur Laufzeit – kein useState, kein ref, kein reactive(...) als API-Design-Frage.

Der Preis: Du bist auf den Compiler angewiesen. Im Browser ohne Build-Schritt läuft .svelte-Code nicht.

Die drei Bestandteile einer .svelte-Datei

Jede .svelte-Datei darf bis zu drei Top-Level-Bereiche enthalten:

<script>
    let { title, body } = $props();
</script>

<article class="card">
    <h2>{title}</h2>
    <p>{body}</p>
</article>

<style>
    .card {
        padding: 1rem;
        border: 1px solid #ddd;
        border-radius: 8px;
    }
</style>

• <script> – die Logik der Komponente: Variablen, Funktionen, Imports, Runes.
• Markup – HTML mit Svelte-Erweiterungen: {...} für Werte, {#if}, {#each}, Bindings, Events.
• <style> – CSS, das per Default scoped ist: Styles wirken nur innerhalb dieser Komponente, ohne Namens-Konflikte.

Alle drei Bereiche sind optional. Eine reine Layout-Komponente kann ohne <script> auskommen, ein reines Logik-Modul ohne Markup.

Svelte 5: Runes als reaktives Modell

Bis Svelte 4 war Reaktivität implizit: Eine let-Variable war automatisch reaktiv, abgeleitete Werte gingen über das $:-Label, Stores hatten ein eigenes Subscribe-Modell. Das war kompakt, aber an einigen Stellen unscharf — vor allem außerhalb von .svelte-Dateien.

Svelte 5 (Oktober 2024) führt Runes ein: explizite Funktionen, die mit $ beginnen und Reaktivität klar markieren. Sie sind sowohl in .svelte- als auch in .svelte.js/.svelte.ts-Dateien nutzbar.

<script>
    let count = $state(0);
    let doubled = $derived(count * 2);

    $effect(() => {
        console.log('count ist jetzt', count);
    });
</script>

<button onclick={() => count++}>
    +1 (count: {count}, doubled: {doubled})
</button>

Die wichtigsten Runes:

• $state(value) – reaktive Variable. Updates werden automatisch verfolgt.
• $derived(expr) – aus anderen reaktiven Werten abgeleitet (Computed).
• $effect(() => ...) – Side Effect, läuft nach Render und bei Änderungen seiner Abhängigkeiten.
• $props() – destrukturiert Komponenten-Props.
• $bindable() – markiert eine Prop als zwei-weg-bindbar.

Vergleich mit Svelte 4:

<script>
    let count = 0;
    $: doubled = count * 2;
    $: console.log('count ist jetzt', count);
</script>

Beide Varianten produzieren das gleiche Verhalten. Runes sind expliziter, lassen sich aber außerhalb von Komponenten wiederverwenden — z. B. in .svelte.ts-Dateien für eigene reaktive Helfer.

Vertiefung im Artikel Einführung in Runes und im Migrations-Artikel Svelte 5 vs. Svelte 4.

Svelte ohne und mit SvelteKit

Svelte selbst ist nur die UI-Schicht. Für eine vollständige Web-Anwendung – mit Routing, Server-Side Rendering, API-Routen und Build-Pipeline – kommt SvelteKit ins Spiel.

• Svelte alleine (über Vite) reicht für eine reine Single-Page-App, eine eingebettete Komponente oder eine Insel in einem Astro-Projekt.
• SvelteKit ist das offizielle Framework auf Svelte-Basis. Es bringt Filesystem-Routing, SSR/Prerendering, Form Actions, Adapter für Node, Vercel, Cloudflare und mehr.

Für neue Web-Projekte empfiehlt das Svelte-Team SvelteKit. Mehr dazu im Artikel SvelteKit – Was ist das?.

Stärken von Svelte

• Sehr wenig Boilerplate. Eine reaktive Variable ist eine let-Variable mit $state(...).
• Kleine Bundles. Hello-World liegt typischerweise im Bereich weniger Kilobyte JS.
• Performance. Compile-Time-Optimierung erspart viel Arbeit zur Laufzeit.
• CSS scoped per Default. Keine BEM-Konventionen oder CSS-in-JS nötig.
• Eingebaute Transitions und Animations über transition:, animate: und svelte/motion.
• Pragmatische Kombination von Markup, Logik und Styling pro Komponente.

Wo liegen die Grenzen?

• Kleinere Community als bei React. Weniger Drittanbieter-Komponenten, weniger Job-Anzeigen.
• Compiler-Magic. Wer hinter die Kulissen schauen will, muss den generierten Code lesen.
• Migration zwischen Major-Versionen war historisch nicht trivial. Der Wechsel von Svelte 4 zu 5 betrifft das Reactivity-Modell direkt.
• Tooling-Integration ist gut, aber bei Spezialfällen (komplexe Editoren, exotische Build-Pipelines) bist du schneller alleine als im React-Ökosystem.

Häufige Missverständnisse

„Svelte ist so klein, weil es weniger kann.” Falsch. Der Compiler-Ansatz erlaubt es, Funktionalität zu liefern, ohne große Runtime mitzuschicken. Funktional ist Svelte mit React und Vue vergleichbar — nicht „abgespeckt”.

„Ohne virtuelles DOM kann es keine Performance-Optimierung geben.” Auch falsch. Svelte optimiert beim Compile direkt: Es weiß bereits, welche DOM-Knoten von welcher Variable abhängen.

„Svelte 5 hat das Framework über den Haufen geworfen.” Stimmt nicht. Svelte 5 ist abwärtskompatibel zur Svelte-4-Syntax, nur das Reactivity-Modell wird neu (Runes). Bestehende Komponenten laufen weiter.

„Stores sind in Svelte 5 tot.” Auch nicht richtig. Stores funktionieren weiter und sind in vielen Fällen sinnvoll. Für komplexe shared state ist $state oft eleganter, aber Stores haben weiterhin ihren Platz.

Weiterführende Ressourcen

Externe Quellen

• Svelte – Offizielle Dokumentation
• Svelte 5 Migration Guide
• SvelteKit – Offizielle Dokumentation

Verwandte Artikel

• Svelte vs. React, Vue und Angular
• Svelte 5 vs. Svelte 4
• Setup mit SvelteKit
• Erste Komponente