Vue 3.6: Mit Vapor Mode zum Schnellsten Vue jemals

Vues neuestes Minor-Release ist in die Release-Candidate-Phase eingetreten, aber es steckt weit mehr dahinter, als der kleine Versionssprung vermuten lässt. Das Team rund um Evan You, den ursprünglichen Erfinder von Vue, arbeitet seit Jahren an diesem Release. Hier erfährst du, was es bringt und warum es wichtig ist.

Die Version soll die RC-Phase in den nächsten Monaten verlassen, im Herbst oder Winter. Der Migrationsprozess soll so einfach wie möglich sein, und neue Features sind ein Opt-in-Upgrade. Ihre Nutzung ist eine Konfigurationsoption, die sich pro Komponente oder app-weit einzeln umschalten lässt. Das bedeutet, dass dein gesamter Code gleich bleibt. Vue 3.6 bringt große Überarbeitungen sowohl am Reactivity-System als auch am Compiler-Mechanismus, einschließlich des Renderings mit seinem neuesten System namens "Vapor Mode". Das verspricht deutliche Performance-Verbesserungen bei der Reactivity und eine kleinere Bundle-Size.

Hinweis: Mit Version 3.6 kommen außerdem interne Type-Verbesserungen und Änderungen am Suspense-Feature, die dieser Blog nicht behandelt.

Bevor du in die neuesten Änderungen eintauchst, solltest du verstehen, wie Vues Rendering-Mechanismus bisher funktioniert hat. Insbesondere, wie das VDOM funktioniert, warum viele Frameworks es übernommen haben, und warum sie seitdem wieder davon abgerückt sind.

Das Web kämpft seit jeher mit einer Frage: Wie aktualisierst du effizient die gerenderten Elemente im DOM-Baum (Document Object Model), also der Sicht des Browsers auf deine Seite, wenn sich der State ändert?

Im Laufe der Zeit haben mehrere Frontend-Frameworks das VDOM ("Virtual DOM") übernommen, das den DOM als JavaScript-Objektbaum aus "VNodes" abbildet. Bei einer Änderung wird ein neuer virtueller Baum auf Basis des ursprünglichen erstellt. Das System "läuft" über beide Bäume und vergleicht sie dabei ("Diffing"). Die Änderungen werden anschließend mit dem echten DOM synchronisiert. Apps mit vielen reaktiven Komponenten trifft das am stärksten, da dieser Prozess eine Kopie aller Elemente im Speicher hält. Vue 3 hat diese Kosten bei kleinen State-Änderungen reduziert, während viele andere Frameworks weiterhin den gesamten Baum vergleichen.

Vues Rendering-System hat in der Vergangenheit mehrere Überarbeitungen durchlaufen, und Vapor ist eine weitere grundlegende Überarbeitung des Kerns. ¹

Version 1.0 arbeitete mit direkter DOM-Manipulation.

Version 2.0 führte das reine Virtual DOM ein, wie oben beschrieben. Da es einiges an Memory-Overhead und Kosten durch das "Diffing" erzeugte, wurde klar, dass dies bei der Performance nicht die beste Lösung war.

Version 3.0 nutzte weiterhin das VDOM, verbesserte es aber durch Compiler-gesteuerte statische Analyse. Diese Version verwendete "Patch Flags" als Hinweise für die Runtime, welche Elemente aktualisiert werden müssen, vergleichbar mit einer Abkürzung. Aber auch diese Version war in ihrem Optimierungspotenzial begrenzt, da sie weiterhin viel Speicher benötigte.

Vapor Mode läuft auf Single File Components ("SFC") mit <script setup>, niemals auf der Options API. Die Composition API ist deshalb der Teil von Vue, den es sich zuerst zu lernen lohnt. Dieses Wissen lässt sich dann auf das Folgende übertragen. Falls du gerade erst anfängst, lies zuerst unseren Beginner's Guide to Reusability. Er zeigt, wie du Logik in Composables und Komponenten aufteilst - die Grundlage, auf der Vapor Mode aufbaut. Komm zurück, sobald das sitzt, und erfahre mehr über die Zukunft von Vue.

Bevor du dich in die Details von Vapor Mode vertiefst, solltest du dir die Änderungen des Vue-Teams am Kern des Reactivity-Systems ansehen. Version 3.6 bringt eine weitere grundlegende Änderung: die Einführung und Verbesserung von sogenannten "Signals".

Wenn sich ein State ändert, wäre der naivste Ansatz, über alle nachgelagerten Kinder zu iterieren und alle Callsites entsprechend zu aktualisieren. Die Idee "Berechne alles neu, sobald sich irgendetwas geändert haben könnte" ist dabei aber verschwenderisch.

Mit Signals verdrahten sich Abhängigkeiten von selbst, sodass nur die betroffenen Stellen laufen und sich aktualisieren. Signals sind im Grunde Werte mit einem Getter und Setter, die Funktionen und Computeds benachrichtigen, wenn sich ihr Wert ändert. Bei dieser Benachrichtigung aktualisieren sich die Callsites, wodurch sich Systeme dynamisch und responsiv anfühlen.

Es gibt mehrere Konzepte von Signals:

Push-based: "Ich habe mich geändert! Alle aktualisieren!"

Pull-based: "Ich habe mich geändert. Aber ich sage es niemandem, bis jemand tatsächlich nach meinem neuen Wert fragt."

Push-Pull an einem Beispiel erklärt:

• Bei einer Änderung pusht das Signal ein "dirty"-Flag an seine Subscriber. "Du bist verändert - schau später nach."
• Später, wenn etwas das Update braucht (z. B. ein Redraw des Bildschirms), pullt es den echten Wert und berechnet neu.

Das vermeidet Fälle, in denen ein Push passiert, der noch gar nicht gebraucht wurde, oder ein Pull von Dingen, die sich gar nicht geändert haben.

In diesem Fall gilt double als "Dependency" von count. Mit count.value "subscribed" sich das Computed double bei count. count führt eine Liste seiner Subscriber, die es bei einer Änderung benachrichtigt.

Mit Version 3.4 hat @johnsoncodehk maßgeblich zu Optimierungen in Vues Reactivity-System beigetragen. Mit Vue 3.5 ist das Team auf ein Pull-based Modell umgestiegen, ähnlich zur Implementierung von Preact, und hat daraus alien-signals ausgegliedert, um einen Push-Pull-Hybrid-Ansatz weiter auszuarbeiten. Dessen Kern wurde jetzt zurück in Vue 3.6 portiert.

Die meisten Frontend-Frameworks (React ausgenommen) sind zu dem Konsens gekommen, dass Signals das ideale Paradigma sind. Signals wurden inzwischen bei TC39 zur Standardisierung vorgeschlagen. Wenn überhaupt, wird eine browsernative Implementierung leider erst in einigen Jahren erwartet. Signals werden oft als "Fine-Grained Reactivity" bezeichnet. Evan You nannte SolidJS und dessen Erschaffer Ryan Carniato als Inspiration für diesen Schritt. Sowohl Solid als auch Svelte setzen ausschließlich auf Signals, und auch Vues Reactivity-System setzt jetzt vollständig darauf.

Mit der ersten Integration des neuen Reactivity-Konzepts zeigten Benchmarks eine Reduzierung des Speicherverbrauchs um 14% sowie deutliche Geschwindigkeitsgewinne. Mehrere Updates später zählt es zu den schnellsten Reactivity-Implementierungen überhaupt. Vue 3.6 liefert alien-signals unter der Haube als neuen Standard aus, ganz ohne notwendige Konfiguration.

Worum geht es denn jetzt hier? Vapor Mode baut auf diesem neuen Reactivity-System auf. Sogenannte "Vapor-Komponenten" überspringen das VDOM komplett und eliminieren damit die Kosten für VNode-Erstellung und Tree-Walking-Diffing. Vapor kompiliert Templates direkt zu optimierten, imperativen DOM-Operationen - ganz ohne Virtual DOM. Das bedeutet, es kennt bereits zur Compile-Zeit alle reaktiven Stellen und optimiert dafür. In einer reinen Vapor-App fliegt die VDOM-Runtime dann komplett aus dem Bundle. Das bedeutet, dass man Vapor-Mode durchweg nutzen muss, um von dessen kleineren Builds zu profitieren. Besonders großen positiven Einfluss hat das auf datenintensive reaktive Apps, Low-End-Geräte und mobile Geräte.

In einem kurzen eigenen Test mit "rc.9" kam die Hello-World-App auf folgende Größen:

Das ist in beiden Fällen eine Reduktion um 46%. Der Großteil davon kommt vom Wegfall der VDOM-Runtime, die bei so einem kleinen Bundle einen großen Anteil ausmacht. In einer größeren App macht diese Runtime einen kleineren Anteil am Gesamtpaket aus, weshalb der prozentuale Gewinn dort geringer ausfallen dürfte. Das Versprechen, dass Vapor kleiner ist, hält dennoch.

Fun Fact: Vapor Mode wurde bereits im Januar 2023 erwähnt², brauchte aber von da an noch fast 4 weitere Jahre bis zur Fertigstellung, während in einem separaten Repo daran gearbeitet wurde.³

Grundsätzlich erzeugt derselbe Source Code unter Vapor Mode ein anderes Ergebnis. Die API und dein Framework-Wissen bleiben gleich, während die Ergebnisse schneller und effizienter werden. Das Vue-Team stellt Vapor auf eine Stufe mit SolidJS und Svelte 5, die in mehreren Benchmarks als die schnellsten gelten. Als Beispiel: Der teaminterne Benchmark zum Mounten von 100.000 Komponenten brauchte etwa 100ms.¹

Der öffentliche js-framework-benchmark bestätigt das. Gefiltert auf die großen Frameworks liegt Vapor insgesamt vorn, dicht gefolgt von Solid und Svelte. Dieselbe Vue-Version ohne Vapor landet eine Stufe darunter - die React-Varianten liegen noch weiter zurück.

Dieses Feature ist zu 100% Opt-in und unterstützt eine Teilmenge der bestehenden Vue-APIs mit größtenteils identischem Verhalten. Ausnahmen sind Features, die auf VNodes oder den public Instance-Proxy einer Komponente angewiesen sind. Es ist möglich, nur ausgewählte Komponenten umzustellen und beide Modi gleichzeitig zu nutzen - das kann aber die Bundle-Size erhöhen.

Vapor Mode ist mit dem RC feature-complete, mit ein paar rauen Kanten im Interop zwischen beiden Rendering-Modi. Die einfache Integration mit minimaler Konfiguration macht es schwer, darauf zu verzichten. Das Update auf Version 3.6 bringt keine Breaking Changes, und du kannst zunächst einzelne Komponenten umstellen. Beachte, dass die Options API nicht unterstützt wird. Vapor funktioniert auf SFCs (Single File Components) mit <script setup> und auf reinen Template-SFCs ganz ohne Script-Block.

Vapor für einzelne Komponenten zu aktivieren ist einfach. Füge vapor zu deinem Script-Block hinzu: <script setup vapor> oder in der Kurzform <script vapor>. Derselbe Marker funktioniert auch am Template, was die gesamte SFC in Vapor Mode kompiliert - die Option für Komponenten ohne Script-Block:

Reine Vapor-Anwendungen, die ausschließlich aus Vapor-Komponenten bestehen, können createVaporApp() nutzen.

Eine app-globale Konfiguration inkludiert die VDOM-Runtime dann gar nicht erst im Bundle.

Wer Vapor-Komponenten in einer mit createApp() erstellten VDOM-App-Instanz nutzen möchte, muss das vaporInteropPlugin installieren:

Eine Vapor-App kann anders herum über das Plugin auch VDOM-basierte Komponenten einbinden, dadurch landet aber die VDOM-Runtime im Bundle. Komponenten, die als Render-Funktionen oder in JSX geschrieben sind, bleiben VDOM-Komponenten und brauchen daher ebenfalls das Plugin, selbst innerhalb einer Vapor-App. Das Plugin erlaubt außerdem das Verschachteln von Vapor- und Nicht-Vapor-Komponenten ineinander, wovon die Release Notes aber abraten.

Beide Arten von Komponenten können nebeneinander im selben Template stehen:

Wie erwähnt unterstützt Vapor Mode keine Komponenten in Options-API-Syntax. Suspense funktioniert mit Vapor-Komponenten, auch über die Interop-Grenze hinweg, und jede RC bisher brachte dafür Fixes mit. Suspense selbst gilt in Vue weiterhin als experimentell, dieser Vorbehalt betrifft also nicht nur Vapor. Die größere offene Frage sind Third-Party-Libraries, die ein Update brauchen, um kompatibel zu bleiben.

Drei Details verhalten sich anders:⁴

• Event-Delegation ist Opt-in. Delegation auf Dokumentebene läuft jetzt pro Listener über den Vapor-exklusiven .delegate-Modifier: <button @click.delegate="onClick" />. Die Option compilerOptions.eventDelegation wurde in rc.2 entfernt.
• Ein Slot-Aufruf rendert ihn direkt. slots.default() ist in Vapor keine reine Inspektions-API. Es erzeugt DOM-Nodes, registriert Effects und beansprucht während der Hydration das SSR-Markup - du kannst es also nicht aufrufen, nur um zu entscheiden, ob ein Fallback angezeigt wird.
• Custom Directives nutzen eine andere Signatur. Eine Vapor-Directive ist eine einfache Funktion, deren value ein über watchEffect() ausgelesener Getter ist, mit einer optional zurückgegebenen Cleanup-Funktion. Directives, die du ausliefertst, brauchen eine Vapor-Version.

Bevor du Vapor Mode einsetzt, prüfe immer die Integration und Unterstützung durch deine Tools, dein Framework, deine Plugins und deine Codebase. Folge diesen Faustregeln:

• 🟢 Nutze createVaporApp, um neue Apps mit Vapor Mode zu bauen, und profitiere von der einfachen Konfiguration und den Performance-Gewinnen.
• 🟢 Die Migration einzelner, einfacher Seiten und Komponenten bringt wahrscheinlich keinen riesigen Performance-Gewinn, ist aber ein typischer Quick-Win, um den Migrationsprozess zu starten.
• 🟢 Mach anschließend mit performance-kritischen Modulen weiter.
• 🟡 Sei vorsichtig bei Abhängigkeiten von Third-Party-Libraries und -Tools - prüfe das vorher.
• 🟡 Vapor Mode in Nuxt- / SSR-Apps gilt noch als "Baustelle" (unter Vorbehalt) - Hydration ist implementiert und funktioniert, aber jeder bisherige Release Candidate brachte dafür Fixes mit.
• 🔴 Inkompatibilität: Wenn deine App stark auf der Options API basiert, priorisiere zuerst die Migration zur Composition API. Für die Release-Candidate "rc.1" listet das Changelog Einschränkungen: app.config.globalProperties wird nicht unterstützt, getCurrentInstance() gibt null zurück, ebenso wie bei den @vue:xxx-Element-Lifecycle-Hooks, v-memo und Eigenschaften auf Component-Template-Refs.⁴

Vue war schon immer das Framework, das man wegen des Toolings, der Docs, der DX und der Community wählt. Die Geschwindigkeit war okay, aber wer den schnellsten Renderer wollte, schaute sich woanders um. Version 3.6 löst diesen Kompromiss - deshalb ist es ein neuer Meilenstein in Vues Geschichte.

Diese Geschwindigkeit ist kein reines Entwickler-Detail. Ein kleineres Bundle und ein schnellerer First Paint entscheiden, ob ein Besucher deine Seite noch sieht oder schon abspringt, bevor sie rendert, und die Ladezeit fließt direkt in Core Web Vitals und Suchranking ein. Auf einem Mittelklasse-Smartphone mit mobilen Daten liefert eine reine Vapor-App weniger Kilobyte aus und parst weniger JavaScript, bevor die Seite auf den ersten Tap reagiert.

Die andere Hälfte des Meilensteins ist, wie wenig er von dir verlangt. React ändert ständig, wie idiomatisches React aussieht: erst Classes, dann Hooks, dann Concurrent Rendering, jetzt Server Components und ein Compiler. Jeder dieser Schritte hat die Community neu geschult und das Ökosystem neu aufgeteilt. Vue hat sein Modell einmal geändert, mit Vue 3, und ist seitdem dabei geblieben. 3.6 setzt das fort: gleiche API, gleiches Wissen, keine Breaking Changes - und das schnellste Rendering, das Vue je hatte, versteckt sich hinter einem Opt-in-Flag.

Diese Kombination ist selten. Ein Performance-Sprung dieser Größe kommt normalerweise als neues Framework oder als Major-Version, die dein Wissen entwertet. Hier kommt er als Minor-Release, den du Komponente für Komponente übernehmen kannst.