Stacks

Vue und Svelte werden fast immer über eine einzige Gegenüberstellung eingeführt: Svelte kompiliert, Vue nutzt ein virtual DOM. Das ist eine handliche Zusammenfassung und sie ist irreführend, denn beide Frameworks stützen sich stark auf einen Compiler. Unterschiedlich ist, was der jeweilige Compiler erzeugt und was zur Laufzeit noch zu tun bleibt.

Svelte beschreibt sich als Framework, das einen Compiler nutzt, um deklarative Komponenten aus HTML, CSS und JavaScript in schlankes, stark optimiertes JavaScript zu verwandeln. Der Build-Schritt steht im Zentrum des Entwurfs: Die Arbeit herauszufinden, was sich ändern soll, wird so weit wie möglich in die Kompilierung verschoben.

Auch Vue kompiliert und sagt das ausdrücklich. Die Dokumentation hält fest, dass das Framework sowohl den Compiler als auch das Runtime kontrolliert, wodurch es Optimierungen zur Kompilierzeit umsetzen kann, die nur ein eng gekoppelter Renderer ausnutzen kann. Vue nennt diesen hybriden Ansatz Compiler-Informed Virtual DOM. Das virtual DOM ist weiterhin da, aber der Compiler sagt dem Runtime, wo es nicht hinschauen muss.

Drei dieser Optimierungen lohnen sich beim Namen zu kennen, denn sie erklären, warum der Vergleich von 'virtual DOM' gegen 'kein virtual DOM' am Punkt vorbeigeht. Static hoisting: Der Renderer erzeugt die vnodes unveränderlicher Teile beim ersten Rendern, legt sie im Cache ab und verwendet dieselben vnodes bei jedem weiteren Re-Render erneut. Nichts wird erneut gediffed, was sich nicht ändern kann.

Patch flags: Vue kodiert die Art der Aktualisierung direkt bei der Erzeugung des vnode, sodass das Runtime bitwise Operationen nutzt, um zu entscheiden, ob eine bestimmte Arbeit überhaupt nötig ist. Es stellt keine breiten Fragen an den Baum, es prüft ein Flag.

Tree flattening: Jeder Block verfolgt die Nachfahren-Knoten, die patch flags tragen, nicht nur die direkten Kinder. Wenn die Komponente neu rendert, durchläuft das Runtime den abgeflachten Baum statt des vollständigen, was laut Dokumentation die Anzahl der bei der Reconciliation durchlaufenen Knoten stark reduziert.

Zusammen gelesen bedeuten diese drei, dass Vues virtual DOM nicht das naive Diff ist, das die verkürzte Gegenüberstellung nahelegt. Der Compiler hat den Suchraum bereits eingegrenzt, bevor das Runtime überhaupt zu suchen beginnt. Das ist ein anderer Entwurf als der von Svelte, aber es ist nicht das Fehlen eines Compilers.

Wo liegt also die eigentliche Wahl? Weniger in der reinen Rendering-Theorie als in dem, was sie umgibt. Vue liefert mehr bereits getroffene Entscheidungen mit, mit offiziellen Routing- und State-Bibliotheken und einer empfohlenen Struktur, was den Weg zur Produktivität in kleineren Teams tendenziell verkürzt. Sveltes Entwurf legt mehr Gewicht darauf, dass der Build-Schritt minimale Ausgabe erzeugt, was reizvoll ist, wenn Payload-Grosse und Startarbeit die Beschrankungen sind, die man wirklich spürt.

Die Reife des Ökosystems ist der andere ehrliche Faktor. Vue ist länger breit im Einsatz, und das zeigt sich an der Menge verfügbarer Bibliotheken, Werkzeuge und Kandidaten am Arbeitsmarkt. Sveltes Ökosystem ist kleiner, was bei einer großen, langlebigen Anwendung mehr ins Gewicht fallt als bei einer eng umrissenen.

Der praktische Rat ist unglamourös: Keine der beiden Entscheidungen wird das sein, was deine Oberfläche schnell oder langsam macht. Komponentenstruktur, Datenabruf, Bildbehandlung und wie viel JavaScript du auslieferst, werden dominieren. Nimm das, womit dein Team sich beim Warten wohlfühlt, und stecke die gesparte Diskussion in das Messen dessen, was tatsächlich geladen wird.