Ein Button zählt Klicks. In React und in Svelte sieht der Quelltext dafür ähnlich kurz aus, und im Browser ist kein Unterschied zu sehen. Was nach dem Klick im Hintergrund passiert, ist trotzdem grundverschieden. React führt die Komponente erneut aus, baut eine neue Beschreibung der Oberfläche und vergleicht sie mit der alten. Svelte ändert genau einen Textknoten – weil der Compiler schon beim Build festgelegt hat, welcher Code bei welcher Änderung laufen muss.

Dieser Unterschied ist der Kern dessen, was oft als Compiler-Ansatz bezeichnet wird. Er erklärt, warum Svelte-Anwendungen häufig mit wenig JavaScript auskommen. Er erklärt aber auch, warum die Werbebotschaft vom „Framework, das verschwindet“ heute nur noch halb stimmt und warum React mit dem React Compiler einen Teil des Abstands aufgeholt hat. Dieser Beitrag ordnet das Konzept ein. Wie man Svelte 5 konkret schreibt, steht in unserer Einführung in Svelte 5 für JavaScript-Entwickler.

Das Problem, das jedes Framework lösen muss

Jede interaktive Oberfläche hat Zustand: den Inhalt eines Warenkorbs, den angemeldeten Nutzer, die aktuelle Filtereinstellung. Und jede Oberfläche muss im Browser das DOM aktualisieren, also die Baumstruktur aus Elementen, die der Browser darstellt. Direktes Arbeiten mit dem DOM ist mühsam und fehleranfällig: Wer bei jeder Änderung von Hand die betroffenen Elemente sucht und anpasst, vergisst irgendwann eine Stelle.

Frameworks nehmen Entwickler:innen diese Arbeit ab. Man beschreibt deklarativ, wie die Oberfläche bei einem bestimmten Zustand aussehen soll, und das Framework kümmert sich um die nötigen DOM-Operationen. Die Frage ist nur, wann es herausfindet, welche Operationen nötig sind: zur Laufzeit im Browser oder vorab beim Build.

Der Laufzeit-Ansatz: React und das virtuelle DOM

React beantwortet die Frage zur Laufzeit. Eine Komponente ist eine Funktion, die bei jeder Zustandsänderung erneut aufgerufen wird:

import { useState } from 'react';

export function Zaehler() {
  const [anzahl, setAnzahl] = useState(0);

  return (
    <button onClick={() => setAnzahl(anzahl + 1)}>Geklickt: {anzahl}</button>
  );
}

Der Aufruf liefert kein DOM, sondern ein virtuelles DOM: einen Baum aus einfachen JavaScript-Objekten, der beschreibt, wie die Oberfläche aussehen soll. React vergleicht diesen Baum mit dem vorherigen – das nennt sich Reconciliation – und überträgt nur die Unterschiede ins echte DOM.

Das Verfahren ist robust und flexibel. Eine Komponente kann beliebiges JavaScript enthalten, React muss vorher nichts über sie wissen. Der Preis: Bei jeder Änderung läuft die Komponentenfunktion erneut, und standardmäßig auch die Funktionen aller Kindkomponenten. Für große Bäume ist das spürbar. Deshalb gibt es in React Werkzeuge wie memo, useMemo und useCallback, mit denen man React mitteilt, welche Teile sich nicht geändert haben. Wer diese Werkzeuge falsch oder gar nicht einsetzt, bekommt unnötige Rechenarbeit im Browser.

Außerdem muss die Vergleichslogik selbst im Browser liegen. React und React DOM gehören deshalb zu jedem Bundle, unabhängig davon, wie klein die Anwendung ist.

Was der Svelte-Compiler aus einer Komponente macht

Svelte verlagert einen Teil dieser Arbeit in den Build. Der Zähler sieht in Svelte 5 so aus:

<script>
  let anzahl = $state(0);
</script>

<button onclick={() => anzahl++}>
  Geklickt: {anzahl}
</button>

Beim Build analysiert der Compiler die Datei. Er erkennt, dass anzahl reaktiver Zustand ist, dass der Wert an genau einer Stelle im Markup vorkommt und dass ein Klick ihn verändert. Daraus erzeugt er JavaScript. Die Ausgabe des Svelte-Compilers für diese Komponente im Produktionsmodus, bis auf die Einrückung unverändert übernommen:

import 'svelte/internal/disclose-version';
import * as $ from 'svelte/internal/client';

var root = $.from_html(`<button> </button>`);

export default function Zaehler($$anchor) {
  let anzahl = $.state(0);
  var button = root();
  var text = $.only_child(button);

  $.template_effect(() => $.set_text(text, `Geklickt: ${$.get(anzahl) ?? ''}`));
  $.delegated('click', button, () => $.update(anzahl));
  $.append($$anchor, button);
}

$.delegate(['click']);

Was hier steht, lässt sich ohne Svelte-Kenntnisse nachvollziehen. Das statische HTML liegt als Vorlage vor und wird einmal erzeugt. template_effect verknüpft genau einen Textknoten mit dem Zustand anzahl. Ändert sich der Wert, läuft nur diese eine Zeile erneut. Die Funktion Zaehler selbst wird nach dem ersten Aufruf nie wieder ausgeführt. Es gibt keinen virtuellen Baum und keinen Vergleich. Den Klick-Listener registriert Svelte nicht am Button, sondern einmal zentral für die ganze Anwendung (Event Delegation), was bei langen Listen Speicher spart.

Die Vergleichsarbeit, die React bei jedem Klick erledigt, hat der Compiler also vorab erledigt: Er weiß aus dem Quelltext, welche Stelle von welchem Wert abhängt.

Svelte 5: Compiler plus Signale

Lange galt Svelte als Framework ohne Laufzeit. Für Svelte 3 und 4 stimmte das weitgehend. Der Compiler erzeugte Code, der Änderungen über eine Art Bitmaske markierte, und lieferte nur kleine Hilfsfunktionen mit. Die Reaktivität war allerdings an Zuweisungen in .svelte-Dateien gebunden. Ein push auf ein Array wurde nicht erkannt, und außerhalb von Komponenten brauchte man Stores.

Svelte 5 hat das umgebaut. Im obigen Kompilat steht $.state, $.get und $.update – das sind Signale. Ein Signal ist ein Container für einen Wert, der sich beim Lesen merkt, wer ihn gelesen hat, und genau diese Leser benachrichtigt, wenn sich der Wert ändert. Diese Logik steckt in einer Laufzeitbibliothek, die mit ausgeliefert wird. Sie ist klein, und der Bundler bindet nur ein, was die Anwendung tatsächlich verwendet. Ganz verschwunden ist das Framework damit aber nicht mehr.

Der Gewinn ist Flexibilität. Weil Signale zur Laufzeit Abhängigkeiten verfolgen, funktioniert Reaktivität jetzt auch in verschachtelten Objekten, in Klassen und in gewöhnlichen Modulen. Der Compiler übernimmt die Aufgabe, aus gut lesbarem Quelltext den passenden Signal-Code zu erzeugen. Svelte 5 ist damit eine Kombination: Der Compiler bereitet vor und übersetzt die Runes, die Signale erledigen zur Laufzeit die feingranulare Aktualisierung.

Signale sind kein Svelte-Alleinstellungsmerkmal

Feingranulare Reaktivität mit Signalen hat sich in den vergangenen Jahren in fast allen großen Frameworks durchgesetzt. SolidJS arbeitet seit jeher so und kombiniert Signale mit einem JSX-Compiler, der ebenfalls kein virtuelles DOM erzeugt. Mehr dazu steht in unserem Beitrag zu SolidJS und feingranularer Reaktivität. Angular hat Signale mit Version 16 eingeführt und baut sein Reaktivitätsmodell seitdem darauf um. Vue nutzt seit Version 3 ein Proxy-basiertes System mit ähnlichem Prinzip und entwickelt mit dem Vapor Mode einen Kompilierungsmodus, der ohne virtuelles DOM auskommen soll. Im TC39-Komitee, das den JavaScript-Standard weiterentwickelt, liegt außerdem ein Vorschlag, Signale direkt in die Sprache aufzunehmen.

Was heißt das für die Einordnung von Svelte? Das Konzept ist nicht mehr exotisch. Svelte unterscheidet sich weniger durch Signale an sich als dadurch, wie konsequent der Compiler sie hinter einer schlichten Syntax versteckt. Wer $state(0) schreibt, arbeitet mit einem Signal, sieht im Code aber eine gewöhnliche Variable.

Der React Compiler: das Gegenstück aus der React-Welt

React ist den umgekehrten Weg gegangen. Statt das Rendering-Modell zu ändern, setzt das React-Team einen Compiler davor. Der React Compiler, laut npm im Oktober 2025 in Version 1.0 erschienen, läuft als Babel-Plugin oder über Integrationen in Build-Werkzeugen wie Vite und Next.js. Er analysiert Komponenten und fügt automatisch Memoisierung ein – also genau das, was Entwickler:innen bisher mit useMemo, useCallback und memo von Hand erledigten.

Der Effekt in der Praxis: Komponenten, deren Eingaben sich nicht geändert haben, werden nicht neu ausgeführt, und teure Berechnungen werden zwischengespeichert. Das beseitigt einen großen Teil der unnötigen Arbeit, die das React-Modell verursachen kann, ohne dass sich der Code ändert.

Die beiden Compiler sind trotzdem nicht dasselbe. Der React Compiler optimiert innerhalb des bestehenden Modells. Das virtuelle DOM und die Reconciliation bleiben, ebenso die Laufzeitbibliothek. Der Svelte-Compiler erzeugt dagegen ein anderes Programm, das ohne Vergleich arbeitet. Für viele Anwendungen ist der praktische Unterschied seit dem React Compiler kleiner geworden. Er verschwindet aber nicht, vor allem bei der Menge an JavaScript, die zum Start geladen wird. Wie sich React-Anwendungen darüber hinaus beschleunigen lassen, beschreibt unser Beitrag zur Performance-Optimierung in React.

Bundle-Größe und Performance: was sich seriös sagen lässt

Rund um Svelte kursieren viele Zahlen: Bundle-Größen in Kilobyte, prozentuale Einsparungen, Lighthouse-Werte nach einem Umstieg. Belastbar sind die wenigsten davon, weil sie von Version, Build-Einstellungen und der konkreten Anwendung abhängen. Wir verzichten deshalb bewusst auf solche Angaben. Drei Zusammenhänge lassen sich aber unabhängig von konkreten Zahlen festhalten.

Grundlast gegen Kosten pro Komponente. Ein Laufzeit-Framework hat eine feste Grundlast: Die Bibliothek muss geladen werden, bevor die erste Komponente erscheint. Dafür ist der Code pro Komponente vergleichsweise kompakt. Bei Svelte ist die Grundlast kleiner, dafür erzeugt der Compiler für jede Komponente eigenen Code. Für eine Landingpage mit wenigen interaktiven Elementen ist Svelte deshalb fast immer im Vorteil. Bei sehr großen Anwendungen mit Hunderten Komponenten schrumpft der Abstand, weil dann der Komponentencode überwiegt.

Ladezeit ist nicht gleich Laufzeit. Weniger JavaScript bedeutet schnelleres Laden und weniger Arbeit beim Starten, vor allem auf älteren Smartphones. Wie flüssig eine Anwendung danach reagiert, hängt stärker von der eigenen Programmierung ab: von der Menge der Daten, langen Listen, unnötigen Netzwerkanfragen. Ein schlecht gebautes Svelte-Frontend ist langsamer als ein gut gebautes React-Frontend.

Benchmarks messen Spezialfälle. Vergleichstests wie der verbreitete js-framework-benchmark messen zum Beispiel, wie schnell Tausende Tabellenzeilen erzeugt oder ausgetauscht werden. Svelte, Solid und andere Signal-Frameworks schneiden dort traditionell gut ab. Für ein Formular in einer Fachanwendung sagt das wenig aus.

Unsere Empfehlung: Wer eine Entscheidung auf Performance stützen will, sollte einen typischen Ausschnitt der eigenen Anwendung in beiden Frameworks prototypisch umsetzen und messen – Bundle-Größe mit dem Build-Werkzeug, Ladeverhalten und Reaktionszeit mit Lighthouse und den Core Web Vitals unter realistischen Netzbedingungen.

Was der Compiler-Ansatz kostet

Ein Compiler nimmt Arbeit ab, verlangt aber auch etwas. Vier Punkte sollten Teams kennen, bevor sie sich festlegen:

• Eigenes Dateiformat. .svelte-Dateien sind weder reines HTML noch reines JavaScript. Editoren brauchen eine Erweiterung, Linter und Formatierer ein Plugin, die Typprüfung läuft über svelte-check statt allein über tsc. Die offiziellen Werkzeuge sind ausgereift, aber es ist eine zusätzliche Schicht.
• Sprachsemantik mit Sonderregeln. Runes sehen aus wie Funktionen, sind aber Compiler-Anweisungen. Dass let { name } = kunde die Reaktivität trennt, let { name } = $props() aber nicht, muss man lernen. In React ist dagegen alles gewöhnliches JavaScript, das nach den Hook-Regeln aufgerufen wird.
• Debugging im erzeugten Code. Im Browser läuft nicht der eigene Quelltext, sondern das Kompilat. Source Maps führen bei Fehlermeldungen meist zuverlässig zurück. Wer tiefer in ein Problem einsteigt, landet aber in Svelte-internen Funktionen wie den oben gezeigten.
• Kleineres Ökosystem. Für React gibt es zu fast jedem Bedarf mehrere ausgereifte Bibliotheken, von Datentabellen über Formularlogik bis zu barrierefreien Komponentensammlungen. Für Svelte ist die Auswahl gewachsen, aber kleiner. Gewöhnliche JavaScript-Bibliotheken ohne Oberflächenbezug funktionieren natürlich in beiden Welten.

Überschätzt wird oft das Gegenargument der „Magie“: Der erzeugte Code ist, wie das Beispiel zeigt, gut nachvollziehbar. Unterschätzt wird dagegen der Aufwand, ein Team mit React-Erfahrung umzuschulen und Bibliotheken zu ersetzen.

Wann der Compiler-Ansatz den Ausschlag gibt

Die technische Bilanz ist klar: Svelte erledigt beim Build Arbeit, die React zur Laufzeit erledigt. Das führt zu kleineren Bundles und feingranularen Updates ohne Memoisierungsaufwand. Seit Svelte 5 geschieht das mit einer kleinen Signal-Laufzeit statt ganz ohne. Und seit dem React Compiler ist ein Teil des Vorsprungs bei der Laufzeit-Performance geschrumpft.

Den Ausschlag gibt der Ansatz vor allem dort, wo JavaScript-Menge und Startzeit unmittelbar zählen: öffentliche Websites und Shops mit vielen mobilen Zugriffen, eingebettete Widgets wie Konfiguratoren oder Rechner, Oberflächen auf schwacher Hardware wie Kiosk-Terminals. Für interne Fachanwendungen im Firmennetz, bei denen ein Team bereits produktiv mit React oder Angular arbeitet, ist er selten ein ausreichender Grund für einen Wechsel. Dort wiegen Ökosystem, vorhandenes Wissen und Personalverfügbarkeit schwerer.

Für Neuprojekte lohnt der Blick trotzdem. Svelte mit SvelteKit ist ausgereift, und der kompakte Code spart im Alltag bei Wartung und Code-Reviews Zeit. Wie die Konzepte in einer kleinen Anwendung zusammenspielen, zeigt der Beitrag Svelte in der Praxis. Bei der Auswahl des passenden Frameworks, bei Prototypen zum Vergleich oder bei Schulungen für Ihr Team unterstützen wir Sie im Rahmen unserer Beratung, Coaching und Seminare zu Svelte und SvelteKit.

Häufige Fragen zum Compiler-Ansatz von Svelte

Hat Svelte wirklich keine Laufzeitbibliothek?

Seit Svelte 5 nicht mehr in diesem strengen Sinn. Die Signal-Logik steckt in einer kleinen Laufzeit, die mit ausgeliefert wird. Der Compiler sorgt aber dafür, dass nur die genutzten Teile im Bundle landen, und erzeugt für jede Komponente gezielten Update-Code. Die Formulierung „Framework ohne Runtime“ stammt aus der Zeit von Svelte 3 und 4.

Macht der React Compiler Svelte überflüssig?

Nein, er schließt eine andere Lücke. Der React Compiler nimmt Entwickler:innen die manuelle Memoisierung ab und reduziert unnötige Rendervorgänge. Das virtuelle DOM und die Laufzeitbibliothek bleiben. Bei Startzeit und Bundle-Größe kleiner Anwendungen behält Svelte deshalb in der Regel einen Vorsprung, bei der Reaktionsgeschwindigkeit großer Anwendungen wird der Unterschied kleiner.

Lassen sich Svelte-Komponenten in eine React- oder Angular-Anwendung einbauen?

Ja, über Umwege. Svelte kann Komponenten als Web Components (Custom Elements) kompilieren, die sich in jede Seite einbetten lassen. Für eine schrittweise Migration oder einzelne Widgets ist das praktikabel. Für eine dauerhafte Mischung zweier Frameworks in einer Anwendung empfehlen wir es nicht, weil Build, Styling und Zustandsverwaltung doppelt gepflegt werden müssen.

Ist ein Compiler-Framework schwerer zu debuggen?

Etwas, aber weniger als oft befürchtet. Source Maps verknüpfen Fehlermeldungen und Haltepunkte im Browser mit dem eigenen Quelltext. Für Reaktivitätsfragen gibt es die Rune $inspect, die Änderungen eines Werts während der Entwicklung in der Konsole protokolliert. Für die meisten Fehler muss man das Kompilat nie ansehen.