- Die bisherige Doppelstruktur aus esbuild + Rollup wurde auf den Rust-basierten Bundler Rolldown vereinheitlicht und erreicht damit eine bis zu 10- bis 30-fach schnellere Build-Performance
- Ein neues Plugin-Register wurde veröffentlicht, in dem sich Vite-, Rolldown- und Rollup-Plugins suchen und verwalten lassen
- Entwicklungsfunktionen wie Vite Devtools, TypeScript-Pfadauflösung, Wasm SSR und Console Forwarding wurden hinzugefügt
- Dieses Release ist die größte strukturelle Veränderung im Vite-Ökosystem und bildet die Grundlage für die weitere Entwicklung einer integrierten Toolchain
Vite 8 auf Basis von Rolldown
- Vite 8 vereinheitlicht die bisherige Doppel-Bundler-Struktur aus esbuild (für die Entwicklung) und Rollup (für die Produktion) zu einem einzelnen Bundler Rolldown
- Rolldown ist ein leistungsstarker, in Rust geschriebener Bundler, der dieselbe Plugin-API wie Rollup unterstützt
- Die meisten bestehenden Vite-Plugins funktionieren ohne separate Anpassungen
- Die Performance ist gegenüber Rollup 10- bis 30-mal schneller und unterstützt fortgeschrittene Funktionen wie modulbasiertes Caching, flexible Chunk-Aufteilung und Module Federation
Der Weg zur Einführung von Rolldown
- Zunächst wurde mit dem Paket
rolldown-vite eine technische Vorschau bereitgestellt, um Community-Feedback zu sammeln
- Kompatibilitätsprobleme wurden durch Tests mit verschiedenen realen Codebasen behoben
- Es wurde ein dediziertes CI-Testsystem für wichtige Plugins und Frameworks aufgebaut
- Im Dezember 2025 wurde die Vite 8 Beta veröffentlicht und Rolldown vollständig integriert
- Während der Beta-Phase entwickelte sich Rolldown zur Release-Candidate-Phase weiter und wurde stabilisiert
Beispiele für tatsächliche Performance-Verbesserungen
- Mehrere Unternehmen berichten von verkürzten Build-Zeiten
- Linear: 46 Sekunden → 6 Sekunden
- Ramp: 57 % kürzer
- Mercedes-Benz.io: bis zu 38 % kürzer
- Beehiiv: 64 % kürzer
- Je größer das Projekt, desto deutlicher der Effekt; zudem sind kontinuierliche Verbesserungen an Rolldown angekündigt
Integrierte Toolchain und Technologie-Stack
- Vite 8 entwickelt sich zu einer End-to-End-Toolchain, in der Vite (Build-Tool), Rolldown (Bundler) und Oxc (Compiler) eng zusammenarbeiten
- Konsistenz über den gesamten Prozess von Parsing, Transformation und Optimierung hinweg
- Tree-Shaking-Optimierung mithilfe der semantischen Analyse von Oxc möglich
- Eine Struktur, mit der sich neue JS-Spezifikationen schnell einführen lassen
Zusätzliche Funktionen
- Vite Devtools: Der Projektstatus kann auf dem Entwicklungsserver visuell analysiert werden
- Integrierte Unterstützung für automatische TypeScript-Pfadauflösung (Alias) und emitDecoratorMetadata
- Wasm SSR: Unterstützung für
.wasm?init-Importe in Server-Side-Rendering-Umgebungen
- Browser Console Forwarding: Browser-Fehler werden an das Terminal weitergeleitet, was die Debugging-Effizienz erhöht
- @vitejs/plugin-react v6: Babel entfernt, Oxc-basiertes React Refresh angewendet, geringerer Installationsumfang
Zukünftige Entwicklungsrichtung
- Full Bundle Mode (experimentell): Führt Bundling auch während der Entwicklung durch und erreicht damit einen 3-fach schnelleren Serverstart, 40 % schnelleres Reloading und 10-mal weniger Netzwerkanfragen
- Raw-AST-Übertragung und native MagicString-Transformation verringern die Performance-Lücke zwischen Rust und JS
- Die Zusammenarbeit im Ökosystem zur Stabilisierung der Environment API läuft weiter
Veränderung des Installationsumfangs
- Vite 8 ist gegenüber Vite 7 um etwa 15 MB größer
- lightningcss (ca. 10 MB): bietet standardmäßig CSS-Minifizierung
- Rolldown-Binärdatei (ca. 5 MB): Größenzuwachs zur Geschwindigkeitsoptimierung
- Die Größenoptimierung soll in künftigen Releases fortgesetzt werden
Migrationsleitfaden
- Die meisten Projekte können ohne Konfigurationsänderungen aktualisiert werden
- Bestehende Einstellungen für
esbuild und rollupOptions werden automatisch umgewandelt
- Für große Projekte wird eine Migration in zwei Schritten empfohlen
- Zunächst von Vite 7 auf
rolldown-vite wechseln, danach auf Vite 8 aktualisieren
- Detaillierte Verfahren finden sich im offiziellen Migration Guide und Changelog
Dank an Rollup und esbuild
- Rollup lieferte die Grundlage für das Plugin-Ökosystem von Vite, und Rolldown übernimmt dessen API
- esbuild war eine Schlüsseltechnologie für die schnelle Entwicklererfahrung und wurde zum Auslöser für die Weiterentwicklung von Rust- und Go-basiertem Tooling
- Die Beiträge beider Projekte sind tief in der DNA von Vite verankert
Community und Zusammenarbeit
- Die Entwicklung von Vite 8 wurde durch die Zusammenarbeit von sapphi-red und dem Vite-Team, dem Rolldown-Team sowie zahlreichen Community-Mitwirkenden ermöglicht
- VoidZero, Bolt und NuxtLabs waren als wichtige Partner beteiligt
5 Kommentare
Hacker-News-Kommentare
Man wird erneut daran erinnert, wie viele Rechenressourcen die Branche mit ineffizienten Tools verschwendet hat, die man ohne jedes Hinterfragen genutzt hat, nach dem Motto „Builds dauern eben lange“.
Wir haben unsere Zeitpläne an diese langsamen Builds angepasst, Wartezeiten zum Running Gag gemacht und sogar Cache-Layer aufgebaut.
Großen Respekt an die Vite-Maintainer.
Die meiste Produktionssoftware ist um ein Vielfaches langsamer als nötig.
Dass Electron-Apps mehrere GB RAM verbrauchen und trotzdem träger wirken als Software von vor 40 Jahren, ist der beste Beweis dafür.
Vor 14 Jahren wurde mir klar, wie viel Zeit beim Warten auf Builds verloren geht, und ich hatte besonders im Java-Ökosystem das Gefühl, dass das Problem dort gravierend ist.
Früher hatte ich ein Ruby-Projekt, bei dem Integrationstests jedes Mal 10 Minuten brauchten, weil die DB neu erstellt wurde.
Kotlin/Spring Boot kompiliert ebenfalls langsam, und auch der Rust-Compiler ist nicht gerade schnell.
Aber Tests können wir kontrollieren. Unit-Tests sollten in Millisekunden fertig sein, und Integrationstests lassen sich durch Parallelisierung und zufällige Testdaten stark verbessern.
Auf meinem MacBook Pro lasse ich Hunderte von Spring-Integrationstests inklusive Redis, DB und Elasticsearch in unter 40 Sekunden laufen.
Wenn man so ein Setup einmal hat, entsteht eine schnelle Feedback-Schleife, und die Freude an der Entwicklung kommt zurück.
Mein Beitrag zu Vite 8 war die Wasm-SSR-Unterstützung.
Ich habe
.wasm?init-Imports so erweitert, dass sie auch in SSR-Umgebungen funktionieren.Der Prozess war langsam, aber ich war beeindruckt, wie sorgfältig das Team geholfen und sogar Dokumentation ergänzt hat.
Man merkt, dass das Vite-Team nicht nur Tools baut, sondern auch Contributor-Onboarding und Zusammenarbeit ernst nimmt.
Es freut mich wirklich, in der Electron-Ära solche Performance-Verbesserungen zu sehen.
Ein Projekt, das ich seit Langem pflege und das noch vor React Hooks begonnen hat, brauchte früher mit webpack-basierten react-scripts 2 Minuten pro Build.
Heute ist es mit Vite 8 in 1 Sekunde fertig. Das zeigt, wie viele Ressourcen wir verschwendet haben.
Der Browser sollte es direkt ausführen können, und auch TypeScript wurde so entworfen, dass es nach dem Entfernen der Typen sofort lauffähig ist.
Schon die Existenz solcher Build-Tools wirkt wie eine Fehlentwicklung.
In unserem Team ist die Build-Zeit nach der Einführung von Vite 8 von 4 Minuten auf 30 Sekunden gesunken.
Es war fast ein Drop-in-Replacement, vielen Dank an das Vite-Team.
Ich habe es schon benutzt, bevor es in Vite integriert wurde, und es ist wirklich großartig.
Man hört doch oft, dass es schneller als Next ist — das muss also ein enormes Projekt sein.
Danke an das Vite-Team dafür, eine Open-Source-Bundling-Lösung gebaut zu haben, die nicht an ein bestimmtes Framework gebunden ist.
(leichtes Hüsteln beim Erwähnen von Turbopack)
Tolle Neuigkeiten. Aber ich glaube nicht, dass Next.js von solchen Community-Erfolgen profitieren wird.
Schuld ist das NIH-Syndrom bei Vercel.
Turbopack wurde in Next 13 als Alpha gestartet und erst in Next 16 zum Standard gemacht.
2022 waren sogar die Benchmark-Vergleiche mit Vite verzerrt.
Caching-Probleme, langsame Performance, Sicherheitslücken bei RSC, der verwirrende App Router und die umständliche Nutzung außerhalb von Vercel-Hosting.
Sich für Next.js zu entscheiden, ist ein Risiko.
Relevante Links: Vergleichsdiskussion, Caching-Historie, Performance-Analyse, Security-CVE, OpenNext
Schon dass die offizielle Dokumentation Next als Standard erwähnt, wirkt seltsam.
Ich verstehe nicht, warum man React nicht als SPA verwenden sollte.
Zum Beispiel: Sitecore Cloud, Sanity, Contentful usw.
Mit Vite+, Void Cloud und Void Framework
scheint jetzt der Showdown zwischen Vercel und Void zu beginnen.
Besonders die PRC-Demo ist spannend — sie zeigt End-to-End-Typsicherheit von der DB bis zur UI.
Wir untersuchen derzeit RPC-Designs mit Telefunc (als tRPC-Alternative) und hoffen auf Zusammenarbeit mit dem Void-Team.
Relevante Links: PRC-Demo-Video, Telefunc, Vike
Void Cloud scheint auf Cloudflare Workers aufzubauen, und im Moment gibt es noch wenig Informationen dazu.
Trotzdem ist es sehr ermutigend, dass Vite+ als MIT-Open-Source veröffentlicht werden soll.
Wenn Bun sich zu sehr auf die Unterstützung von Anthropic konzentriert und OSS vernachlässigt, könnte es seinen Wettbewerbsvorteil verlieren.
Siehe auch: Void Cloud
Auch wenn das JS-Ökosystem chaotisch ist, liefert Vite konstant eine hervorragende DX und Produktionsqualität.
Mit dem integrierten Rolldown-Bundler wird es eine noch schnellere und flexiblere Grundlage.
Als jemand, der seit 1998 Webentwicklung macht, bin ich wirklich ein Fan.
Weil mir langfristige Wartbarkeit wichtig ist, nutze ich esbuild direkt.
Ich habe keine Lust, ständig Dinge zu reparieren, wenn Wrapper wie Vite wegen interner Änderungen kaputtgehen.
Die Typvalidierung lief über Zod, und nur die Postgres-Typen wurden per Codegen erzeugt.
Als Nächstes hätte ich vermutlich Kysely verwendet.
Die eingebaute Unterstützung für tsconfig paths ist wirklich eine großartige QoL-Verbesserung.
So lässt sich doppelte Konfiguration reduzieren.
Je nach Projekt kann das sogar einfacher sein.
Eigentlich war JS ursprünglich eine Sprache, die keinen Build-Prozess brauchte; der Browser sollte es direkt ausführen können, und auch TypeScript wurde so konzipiert, dass es nach dem Entfernen der Typen sofort ausgeführt werden kann. Schon die Existenz solcher Build-Tools wirkt wie eine Entwicklung in die falsche Richtung -> wie könnte man das wieder normalisieren?
Da es nicht mehr nur im Browser läuft, sondern direkt auf dem Server, scheint das wohl eine unvermeidliche Entwicklung zu sein.
Ich denke, das ist ein natürliches Phänomen, das mit der zunehmenden Komplexität von Web-Apps entstanden ist.
Müsste man dann nicht Browser-JS entsorgen, so wie man damals Flash entsorgt hat? Allerdings sieht es nicht danach aus, dass JS bald verschwindet.