Vite 8 und das Ökosystem drumherum: Was sich gerade bewegt

Vite 8 ist da — und wie bei jedem Major-Release stellt sich die Frage: Was ändert sich wirklich? Aber die interessantere Frage ist eine andere: Was passiert gleichzeitig im Ökosystem drumherum?

Denn Vite existiert nicht isoliert. Es ist Teil eines Stacks, der sich gerade an mehreren Stellen gleichzeitig verschiebt — TypeScript, Runtimes, State Management. Dieser Artikel schaut auf die Updates, die für Vite-Projekte im Frühjahr 2026 tatsächlich relevant sind.

Vite 8: Was sich wirklich ändert

Rolldown: der strategische Wechsel

Das zentrale Update in Vite 8 ist kein einzelnes Feature, sondern ein Infrastrukturwechsel. Bisher nutzte Vite intern zwei verschiedene Tools:

• Dev-Server: esbuild – schnell, aber mit begrenztem Plugin-Support
• Production Build: Rollup – flexibel, aber langsamer

Dieser Split hatte Konsequenzen: Plugin-Autoren mussten beide Pipelines berücksichtigen, und gelegentlich verhielt sich der Production Build anders als der Dev-Server. Rolldown löst das.

Rolldown ist Rust-basiert – ähnlich wie es esbuild vorgemacht hat – ersetzt langfristig Rollup und vereinheitlicht Dev- und Build-Pfad unter einem Tool. Die Auswirkungen:

• weniger Edge Cases zwischen Dev und Build
• Plugins müssen nicht mehr beide Pipelines unterstützen
• bessere Tree-Shaking-Konsistenz zwischen Entwicklung und Production
• 30–60 Prozent kürzere Build-Zeiten (je nach Projektgröße)

Das ist architektonisch relevant – nicht nur weil es schneller ist, sondern weil es das Verhalten vorhersehbarer macht.

Plugin-Architektur: parallele Verarbeitung

Die Plugin-API wurde überarbeitet, um parallele Verarbeitung besser zu unterstützen. Konkret bedeutet das:

• Plugin-Hooks laufen parallel, wenn zwischen ihnen keine expliziten Abhängigkeiten bestehen
• Vite erkennt Plugin-Dependencies jetzt explizit – weniger implizite Reihenfolge-Annahmen
• Transform-Hooks haben weniger Race Conditions, weil die Abhängigkeitsstruktur sauber deklariert ist

Der Nutzen ist besonders spürbar in großen Projekten mit vielen Plugins – Tailwind, MDX, i18n, Auth, Analytics addieren sich schnell. Bisher war jeder Transform sequentiell; in Vite 8 laufen unabhängige Plugins parallel. Das Ergebnis: weniger flaky Builds, schnellere Dev-Server-Starts.

Für die meisten Projekte bedeutet das: Update machen, schnellere Builds genießen, nichts migrieren. Breaking Changes betreffen hauptsächlich Plugin-Autoren, nicht Endnutzer.

# Update
npm install vite@8 --save-dev

# Prüfen, ob Plugins kompatibel sind
npx vite --force

Wer eigene Vite-Plugins pflegt, sollte die neue parallel-Option in der Plugin-API prüfen. Die Migration ist in den meisten Fällen ein Einzeiler.

Dev-Server-Verbesserungen

Ein oft unterschätzter Teil des Updates betrifft den Dev-Server direkt:

• Stabilere Module Graph Invalidations – weniger unnötige Full Reloads, mehr echtes HMR
• Präzisere Abhängigkeitsverfolgung – nur tatsächlich betroffene Module werden neu gebaut
• Bessere Performance bei großen Monorepos – besonders ab ~1000 Modulen wird der Unterschied merklich

Gerade bei 1000+ Modulen merkt man den Unterschied stärker als beim Production Build. Ein Full Reload, der früher 800ms dauerte, kann auf 200ms fallen – nicht weil einzelne Operationen schneller sind, sondern weil weniger davon ausgeführt werden.

TypeScript 5.8: Endlich saubere ESM-Imports

TypeScript 5.8 ist das Update, auf das Vite-Nutzer gewartet haben — auch wenn es auf den ersten Blick unspektakulär wirkt.

Explizites Resource-Typing

Neue Typen für Streams, WebAPIs und andere Ressourcen, die bisher als any oder mit manuellen Typings abgebildet wurden:

// Vorher: manuelles Typing oder any
const stream: any = new ReadableStream({ ... });

// TypeScript 5.8: Native Typen für Web-APIs
const stream: ReadableStream<Uint8Array> = new ReadableStream({
  start(controller) {
    controller.enqueue(new Uint8Array([1, 2, 3]));
    controller.close();
  }
});

Das betrifft vor allem SSR-Code, Edge-Functions und Service Worker — überall dort, wo Web-APIs direkt genutzt werden.

Bessere Vite-Integration

Die eigentliche Verbesserung für Vite-Projekte liegt in der tsconfig.json:

{
  "compilerOptions": {
    "moduleResolution": "bundler",
    "verbatimModuleSyntax": true
  }
}

moduleResolution: "bundler" ist nicht neu, aber TypeScript 5.8 macht es zum empfohlenen Standard für Bundler-Projekte. Die Kombination mit verbatimModuleSyntax eliminiert die meisten Import-Probleme, die Vite-Nutzer bisher hatten:

• Keine falschen CommonJS-Auflösungen mehr
• Type-only Imports werden sauber erkannt und entfernt
• Dev-Server-Type-Checking wird spürbar schneller

verbatimModuleSyntax ist dabei mehr als ein Cleanup-Flag. Es verhindert, dass TypeScript Imports eigenständig umformt – was für ESM-Konsistenz, Tree-Shaking und Edge-Runtimes entscheidend ist. TypeScript hört auf, beim Import-Stil „intelligent” zu sein. Das klingt nach einem Verlust, ist aber ein Gewinn: der Bundler entscheidet, was mit Imports passiert – nicht der Compiler.

Migration

npm install typescript@5.8 --save-dev

In der tsconfig.json prüfen, ob moduleResolution auf "bundler" steht. Falls ja: nichts weiter tun. Falls "node" oder "node16": umstellen und Imports prüfen — in den meisten Fällen funktioniert es ohne Änderungen.

Bun 2.0: Die Alternative wird ernst

Bun 2.0 ist kein Vite-Ersatz. Aber es wird zunehmend zu einer ernstzunehmenden Alternative für Teile des Vite-Workflows.

Was Bun 2.0 bringt

• Native TypeScript-Ausführung ohne Transpilation — bun run server.ts funktioniert direkt
• Spürbar schnellere Dev-Server-Starts im Vergleich zu Node.js – stark I/O-abhängig, je nach Projekt unterschiedlich
• WebSocket-optimierter Dev-Server für schnelleres HMR
• bun vite-Kompatibilität — Vite-Projekte laufen unter Bun ohne Konfigurationsänderung

Wo Bun Vite ergänzt

# Statt: node + vite dev
bun vite dev

# SSR-Server mit Bun statt Node
bun run src/server.ts

Der größte Gewinn liegt im SSR- und Edge-Bereich. Bun startet schneller, verbraucht weniger Speicher und ist bei I/O-lastigen Workloads messbar performanter.

Wo Bun wirklich gewinnt

• SSR mit vielen kleinen Requests – Bun startet Prozesse schneller und verbraucht weniger Speicher
• Edge-like Workloads – schnelle Kaltstart-Zeiten, geringer Overhead
• Streaming – Bun basiert nativ auf der Fetch API, Streaming ist kein Sonderfall

Wo Bun (noch) nicht reicht

• Große Legacy npm Projekte: Die meisten Pakete funktionieren, aber native Node-Module (Sharp, Canvas, SQLite-Bindings) machen gelegentlich Probleme.
• Native bindings-heavy Stacks: Wer viel mit C++-Bindings arbeitet, trifft öfter auf Inkompatibilitäten.
• Debugging: Node.js-Debugging-Tools (Chrome DevTools, VS Code Debugger) funktionieren mit Bun, aber die Integration ist weniger ausgereift.

Empfehlung

Bun 2.0 als Dev-Runtime ausprobieren — bun vite dev statt npm run dev. Falls es funktioniert, bleibt es. Falls nicht, kostet der Versuch 5 Minuten.

Für Produktion: abwägen. Bei reinen Frontend-Builds (kein SSR) ist der Unterschied irrelevant — Vite baut ohnehin mit Rollup/esbuild. Bei SSR-Workloads kann Bun einen echten Unterschied machen.

State Management: Zustand 5 und Jotai 3

Zwei Updates, die für sich genommen klein sind, aber zusammen ein Muster zeigen: State Management wird schlanker, schneller und framework-agnostischer.

Zustand 5

Zustand war schon immer minimal. Version 5 bleibt das — mit zwei relevanten Verbesserungen:

import { create } from 'zustand';
import { devtools, persist } from 'zustand/middleware';

const useStore = create(
  devtools(
    persist(
      (set) => ({
        count: 0,
        increment: () => set((state) => ({ count: state.count + 1 })),
      }),
      { name: 'counter-storage' }
    ),
    { name: 'CounterStore' }  // Persistente DevTools-Benennung (neu in v5)
  )
);

• Persistente DevTools-Integration: Store-Namen bleiben über HMR-Zyklen stabil. Klingt trivial, war in der Praxis ein häufiges Ärgernis — nach jedem Hot Reload waren die DevTools-Labels weg.
• Verbesserte Middleware-Typisierung: TypeScript-Inferenz für verschachtelte Middleware funktioniert jetzt korrekt, ohne manuelle Typ-Annotationen.

Jotai 3

Jotai geht den atomaren Weg — jeder Zustandswert ist ein eigenständiges Atom. Version 3 optimiert das für serverseitige Szenarien:

import { atom, useAtomValue } from 'jotai';

// Server-kompatibles Atom mit initialem Wert vom Server
const userAtom = atom<User | null>(null);

// Hydration-sicherer Hook
const user = useAtomValue(userAtom);

• SSR-Kompatibilität: Atoms können serverseitig initialisiert werden, ohne Hydration-Mismatches
• Kleinere Bundle-Größe: Core ist nochmals geschrumpft
• Provider-optional: Jotai 3 funktioniert ohne Provider-Wrapper — weniger Boilerplate

Zustand oder Jotai?

Kriterium	Zustand 5	Jotai 3
Modell	Ein Store, viele Slices	Viele unabhängige Atoms
Boilerplate	Minimal	Noch minimaler
DevTools	Exzellent (v5)	Gut
SSR	Funktioniert	Optimiert (v3)
Lernkurve	Niedrig	Niedrig
Bundle-Größe	~1 KB	~2 KB

Beide funktionieren hervorragend mit Vite — schnelles HMR, kein Setup-Overhead. Die Wahl ist Geschmackssache: Zustand für zentralisierten State, Jotai für granularen, atomaren State.

Der eigentliche Trend: Weg von globalem State

Zustand und Jotai sind nicht nur „Alternativen zu Redux” – sie spiegeln einen grundlegenderen Wandel wider. Modernes SSR und Island-Architekturen brauchen weniger globalen State und mehr:

• server-driven state – Daten kommen vom Server, nicht aus einem Store
• URL state – Filterung, Paginierung, Suchparameter leben in der URL
• component-local state – was lokal bleiben kann, bleibt lokal

Zustand und Jotai passen zu diesem Muster besser als Redux: klein genug, um sie pro Island zu instantiieren, ohne einen globalen Provider für die gesamte App zu brauchen.

Zustand und Jotai in Astro

Beide Libraries haben einen framework-agnostischen Core. In Astro lassen sie sich direkt als Vanilla-Stores nutzen — kein React, kein Preact, nur ein <script>-Tag oder eine Svelte-Island.

Zustand als Vanilla-Store:

// src/stores/cart.ts
import { createStore } from 'zustand/vanilla';

export const cartStore = createStore((set) => ({
  items: [],
  addItem: (item) => set((s) => ({ items: [...s.items, item] })),
}));

---
// src/pages/shop.astro
---
<button id="cart-btn">Warenkorb (0)</button>

<script>
  import { cartStore } from '../stores/cart';

  const btn = document.getElementById('cart-btn');
  cartStore.subscribe((state) => {
    btn.textContent = `Warenkorb (${state.items.length})`;
  });
</script>

Kein Framework, kein Hydration-Problem. Der Store lebt im Client, das HTML kommt vom Server.

Jotai als Vanilla-Store:

// src/stores/user.ts
import { atom, createStore } from 'jotai/vanilla';

export const userAtom = atom<string | null>(null);
export const userStore = createStore();

---
// src/pages/dashboard.astro
const user = await getUser(Astro.cookies);
---
<p id="greeting">Hallo, <span id="user-name"></span></p>

<script define:vars={{ userName: user.name }}>
  import { userAtom, userStore } from '../stores/user';

  userStore.set(userAtom, userName);
  document.getElementById('user-name').textContent =
    userStore.get(userAtom);
</script>

Der Server ermittelt den User, übergibt den Namen per define:vars an das Client-Script, Jotai übernimmt den State. Für komplexere Interaktivität funktioniert dasselbe Pattern in einer Svelte-Island — Zustand und Jotai sind framework-agnostisch genug, um sich in jedes Setup einzufügen.

Am Rande: React 20

Der Vollständigkeit halber: React 20 bringt Server Components als stabiles Feature, optimiertes Concurrent Rendering und bessere Hydration. Die Integration mit Vite 8 ist sauberer als je zuvor — Hydration-Mismatches sind minimiert, die Build-Zeiten profitieren von der neuen Plugin-Architektur.

React ist allerdings nicht mein Schwerpunkt. Ich arbeite primär mit Astro und Svelte. Wer React mit Vite nutzt, findet die Details in den offiziellen React-20-Release-Notes und im Vite-Migrationsleitfaden.

Was ich beobachte: Die Verbesserungen bei Hydration und Server Components machen React-Projekte mit Vite spürbar schneller. Messbare Verbesserungen bei Hydration-Zeiten und TTFB sind dokumentiert – wie groß der Unterschied ist, hängt stark von Server Components Nutzung und Streaming-Setup ab.

Was du konkret tun solltest

Wenn du heute ein Vite-Projekt hast

Vite 8 und TypeScript 5.8 zusammen updaten – die Kombination macht am meisten Sinn:

npm install vite@8 typescript@5.8 --save-dev

In der tsconfig.json zwei Settings prüfen:

{
  "compilerOptions": {
    "moduleResolution": "bundler",
    "verbatimModuleSyntax": true
  }
}

In den meisten Projekten geht das ohne weitere Anpassungen. Falls Import-Fehler auftauchen: es sind fast immer explizite type-Keywords, die gefehlt haben.

Wenn du Performance-Probleme hast

Bun als Dev-Runtime testen – der Einstieg kostet wenig:

bun vite dev

Build-Zeiten separat messen, nicht nur Dev-Start. Bei reinen Frontend-Builds ist der Unterschied gering; bei SSR oder I/O-lastigen Workloads kann er signifikant sein.

Wenn du neu startest

• Zustand oder Jotai statt Redux – kein Overhead, kein Boilerplate
• SSR früh mitdenken: component-local state und URL state reichen weiter als man denkt
• Globalen Store nur dann, wenn der State wirklich global sein muss

Was das zusammen bedeutet

Die interessante Beobachtung ist nicht das einzelne Update, sondern das Muster dahinter: Konvergenz.

• Bundler werden eins: Rolldown vereint Dev und Build unter einem Tool
• TypeScript passt sich Bundlern an: verbatimModuleSyntax und moduleResolution: "bundler" machen TypeScript vorhersehbar statt eigenständig
• Runtimes werden austauschbar: Node.js und Bun können in vielen Projekten gewechselt werden, ohne den Stack anzupassen
• State wird optional: Zustand und Jotai funktionieren ohne globale Provider – State ist da, wo er gebraucht wird

Build-Tools werden unsichtbar. Vite 8 ist schneller, aber die meisten Nutzer werden den Unterschied nur an kürzeren Build-Zeiten bemerken. Die Plugin-Architektur ist besser, aber das betrifft Plugin-Autoren, nicht Endnutzer.

TypeScript wird zum Standard. TypeScript 5.8 mit moduleResolution: "bundler" eliminiert die letzten Reibungspunkte zwischen TypeScript und Bundlern. Die Frage “TypeScript oder JavaScript?” stellt sich 2026 kaum noch.

Runtimes konkurrieren. Bun 2.0 zeigt, dass Node.js nicht mehr alternativlos ist. Noch nicht als vollständiger Ersatz, aber als performante Alternative für spezifische Workloads.

State Management ist gelöst. Zustand und Jotai sind so ausgereift, dass die Wahl zwischen ihnen keine Architektur-Entscheidung mehr ist, sondern eine Präferenz. Redux ist nicht falsch — aber für neue Projekte mit Vite gibt es schlankere Optionen.

Unterm Strich

Das Ökosystem um Vite herum wird erwachsen. Nicht im Sinne von “es war unreif”, sondern im Sinne von: Die Tools hören auf, sich gegenseitig im Weg zu stehen. TypeScript versteht Bundler besser. Bun versteht Vite besser. State-Libraries verstehen SSR besser.

Für die tägliche Arbeit heißt das: weniger Konfiguration, weniger Workarounds, weniger „das funktioniert nicht zusammen”. Und mehr Zeit für den Code, der tatsächlich zählt.

Der Stack wird nicht komplexer – er wird kompatibler.