Vite vs. Webpack: Warum ich heute nur noch auf Vite setze

Wer in den letzten Jahren JavaScript-Projekte gebaut hat, kennt den Schmerz: Ein frisches Webpack-Projekt konfigurieren, Loader für TypeScript, CSS, SVG, Fonts einrichten, HMR zum Laufen kriegen... das kostet Stunden, bevor auch nur eine Zeile Produktivcode geschrieben wurde.

Vite hat 2020 damit aufgeräumt. Heute ist es mein Default für alle neuen Projekte – und ich erkläre warum.

Das fundamentale Problem mit Webpack

Webpack wurde 2012 entwickelt, als Browser noch keine nativen ES Modules kannten. Es bündelt alles in wenige Dateien, die der Browser versteht. Das war revolutionär – und 2024 ist es das Kernproblem.

Wenn du in Webpack eine Datei änderst, muss es potenziell den gesamten Dependency-Graph neu berechnen. Bei großen Projekten dauert ein Hot Module Replacement Update 5-30 Sekunden. Das unterbricht den Flow.

Wie Vite das Problem löst

Vite macht zwei Dinge grundlegend anders:

1. Nativer ESM im Development-Server

In der Entwicklung sendet Vite keine gebündelten Dateien an den Browser. Stattdessen nutzt es native ES Modules, die moderne Browser direkt verstehen. Die Datei, die du bearbeitest, wird direkt als ESM-Modul transformiert und ausgeliefert.

Das Ergebnis: HMR-Updates unter 100 Millisekunden, egal wie groß das Projekt ist. Weil Vite nicht das gesamte Bundle neu erstellen muss – nur die geänderte Datei.

2. esbuild für Pre-Bundling

Dependencies (node_modules) werden einmalig mit esbuild vor-gebündelt – esbuild ist in Go geschrieben und 10-100× schneller als JavaScript-basierte Bundler. Das passiert beim ersten Serverstart.

Direkter Vergleich

Aspekt Webpack Vite
Dev-Server Start 10-60s (großes Projekt) <1s
HMR Update 2-30s <100ms
Konfigurationsaufwand Hoch Minimal
TypeScript Via ts-loader/babel-loader Nativ
CSS/SCSS Loader notwendig Nativ
Production Build Gut optimiert Rollup (exzellent)
Plugin-Ökosystem Riesig (älter) Wächst schnell
Code Splitting Manuel konfigurierbar Automatisch

Vite Zero-Config: Was es mitbringt

Ein neues Vite-Projekt braucht keine Konfiguration für:

  • TypeScript (direktes Ausführen)
  • JSX/TSX (React, Preact, etc.)
  • CSS, SCSS, Less, PostCSS
  • CSS Modules
  • JSON-Imports
  • WebAssembly
  • Web Workers
npm create vite@latest mein-projekt -- --template react-ts
cd mein-projekt && npm install && npm run dev

In unter 30 Sekunden hast du einen funktionierenden Dev-Server mit HMR.

Webpack-Stärken: Wann es noch Sinn macht

Webpack hat nicht ohne Grund das Ökosystem dominiert. Es gibt legitime Gründe, dabei zu bleiben:

1. Legacy-Projekte

Wenn ein Webpack-Projekt seit Jahren läuft und stabil ist, rechtfertigt die pure Performance-Verbesserung selten einen Migration-Aufwand von mehreren Tagen.

2. Hochspezialisierte Builds

Webpack hat das mächtigste Plugin-System. Für sehr spezifische Build-Anforderungen (Custom Module Federation, komplexe Asset-Pipelines, Legacy-Browser-Support bis IE11) gibt es Webpack-Plugins, die Vite nicht bietet.

3. Create React App

CRA basiert auf Webpack. Wenn du CRA nutzt und keinen Grund siehst zu migrieren, brauchst du Vite nicht zwingend. Allerdings ist CRA selbst offiziell "veraltet" – die React-Docs empfehlen heute Next.js oder Vite.

Migration von Webpack zu Vite

Für die meisten React/Vue/Svelte-Projekte läuft die Migration folgendermaßen:

  1. vite.config.ts erstellen
  2. index.html ins Root-Verzeichnis verschieben (kein public/)
  3. process.env.* durch import.meta.env.* ersetzen
  4. Webpack-spezifische Imports anpassen (z.B. require() → import)
  5. Spezifische Webpack-Loader durch Vite-Plugins ersetzen

Bei mittelgroßen Projekten dauert das typischerweise 2-8 Stunden.

Production Build: Vite vs. Webpack

Im Development-Modus ist Vite klar schneller. Im Production Build ist das Bild differenzierter:

Vite nutzt Rollup für Production Builds. Rollup ist hervorragend für Tree Shaking und erzeugt sehr schlanke Bundles. Webpack 5 ist ebenfalls sehr gut optimiert.

In der Praxis: Vite-Production-Bundles sind oft 10-20% kleiner als Webpack-Bundles bei gleichem Input – dank besserem Tree Shaking durch Rollups ESM-nativen Ansatz.

Meine Empfehlung

Für alle neuen Projekte: Vite, ohne Nachzudenken.

Für bestehende Webpack-Projekte: Migration planen, wenn das Team durch langsame Build-Zeiten gebremst wird.

Für hochspezialisierte Enterprise-Builds: Webpack evaluieren, ob die spezifischen Features wirklich nötig sind.

Das JavaScript-Tooling-Ökosystem hat sich verlagert: Vite ist heute der Standard. Next.js, Nuxt, SvelteKit, Qwik, Remix – all diese Frameworks nutzen Vite (oder ihren eigenen Bundler) statt Webpack. Wer heute ein neues Projekt mit Webpack startet, muss gute Gründe haben.