Vite für React: Warum Create React App tot ist

1. Das Problem mit Create React App

Create React App wurde 2016 von Facebook als Zero-Config-Lösung für neue React-Projekte eingeführt. Zum damaligen Zeitpunkt war das revolutionär: Webpack-Konfiguration, Babel-Setup und ESLint-Integration waren komplex und zeitaufwendig. CRA bündelte alles in einem einzigen react-scripts-Paket und ermöglichte einen sofortigen Start. Das Problem: CRA wurde zum Opfer seines eigenen Erfolgs. Die Wartungslast wurde zu groß, Webpack als Kern blieb langsam, und das Team konnte mit dem Tempo des Ökosystems nicht mithalten.

Seit 2023 ist Create React App offiziell deprecated – die offizielle React-Dokumentation empfiehlt es nicht mehr und verweist stattdessen auf Next.js, Remix und Vite. Die Gründe sind konkret: CRA-Projekte starten in mittleren Codebasen in 15–60 Sekunden. HMR-Zyklen dauern mehrere Sekunden. Die interne Webpack-Konfiguration ist durch react-scripts verschlossen – Anpassungen erfordern Eject, das die Zero-Config-Garantie bricht. Abhängigkeitssicherheitslücken in veralteten transitiven Paketen häufen sich. Für jede neue React-Applikation ohne Framework-Anforderungen ist Vite heute der richtige Ausgangspunkt.

2. Warum Vite? Das Kern-Design

Vite (Französisch für "schnell") wurde von Evan You – dem Schöpfer von Vue.js – entwickelt und basiert auf einem fundamental anderen Design als Webpack. Im Entwicklungs-Modus bündelt Vite keine Dateien – stattdessen nutzt es native ES Module direkt im Browser. Der Browser fordert Module bei Bedarf an, und Vite transformiert sie on-demand. Das bedeutet: Startzeit ist proportional zur Anzahl der Module, die beim initialen Laden tatsächlich benötigt werden – nicht zur Gesamtgröße der Applikation. In der Praxis startet ein Vite-Dev-Server unabhängig von der Projektgröße in unter einer Sekunde.

Hot Module Replacement ist in Vite präzise und schnell: Wenn eine Datei geändert wird, sendet Vite nur das geänderte Modul an den Browser – kein Re-Bundling, keine vollständige Neukompilierung. Das ergibt typische HMR-Zyklen von unter 100 Millisekunden. Für den Production Build verwendet Vite Rollup – einen Battle-tested Bundler, der Tree-Shaking und Code-Splitting hervorragend beherrscht. Das ist eine kluge Trennung: Entwicklung optimiert für Geschwindigkeit, Produktion optimiert für Bundle-Größe und Kompatibilität.

# Create a new React + Vite project (npm, yarn, or pnpm)
npm create vite@latest my-react-app -- --template react-ts

# Alternative: with yarn
yarn create vite my-react-app --template react-ts

# Available templates:
# react         — React + JavaScript
# react-ts      — React + TypeScript
# react-swc     — React + JavaScript + SWC (faster transform)
# react-swc-ts  — React + TypeScript + SWC (recommended 2026)

cd my-react-app
npm install
npm run dev   # starts in < 300ms, HMR ready

# Project structure created:
# ├── index.html          ← entry point (NOT /public — this is intentional)
# ├── vite.config.ts      ← Vite configuration
# ├── tsconfig.json       ← TypeScript config
# ├── tsconfig.node.json  ← separate config for vite.config.ts itself
# ├── public/             ← static assets (copied as-is)
# └── src/
#     ├── main.tsx        ← React tree root
#     ├── App.tsx         ← root component
#     └── vite-env.d.ts   ← Vite type declarations (ImportMeta etc.)

3. Vite-React-Projekt erstellen

Der Einstieg in Vite mit React ist minimaler als mit CRA. Das Scaffolding via npm create vite@latest erzeugt eine schlanke Projektstruktur ohne versteckte Konfigurationsschichten. Ein wichtiger Unterschied zu CRA: Die index.html liegt im Projektwurzelverzeichnis, nicht in /public. Das ist kein Bug, sondern Design: Vite behandelt index.html als Einstiegspunkt des Dependency-Graphen und kann damit statische Assets direkt in die HTML-Datei einbinden.

Die Wahl des Transformers ist relevant für Performance: Standardmäßig nutzt Vite Babel für JSX-Transformation. Die Alternative ist SWC (Speedy Web Compiler) – ein in Rust geschriebener Transformer, der 20–70x schneller als Babel ist. Das Template react-swc-ts ist für 2026 die empfohlene Startkonfiguration: TypeScript-Unterstützung ohne separate ts-jest- oder ts-loader-Konfiguration, und SWC als schnellstmöglicher Transformer. Der Unterschied im täglichen Betrieb: Spürbar schnellere HMR-Zyklen bei komplexen Komponenten.

4. vite.config.ts richtig konfigurieren

Die vite.config.ts ist der zentrale Konfigurationspunkt und deutlich zugänglicher als eine ausgespielte Webpack-Config. Das React-Plugin (@vitejs/plugin-react oder @vitejs/plugin-react-swc) aktiviert JSX-Transformation und React Fast Refresh. Darüber hinaus sind die häufigsten Konfigurationspunkte: resolve.alias für Pfad-Aliase, server.port für den Dev-Server-Port, server.proxy für API-Proxying während der Entwicklung, und build.outDir für das Build-Ausgabeverzeichnis.

Ein großer Vorteil gegenüber CRA: Diese Konfiguration ist immer zugänglich und muss nie durch Eject freigelegt werden. Vite-Plugins sind normale npm-Pakete, die in plugins eingetragen werden. Das Plugin-Ökosystem ist gewachsen: Plugins für SVG als React-Komponenten, für automatisches Importieren, für Mock-Server, für Bundle-Analyse und für Tauri-Desktop-Apps sind alle ohne Weiteres verfügbar. Die Konfiguration bleibt dabei übersichtlich – wenige Dutzend Zeilen decken die meisten Projektanforderungen ab.

// vite.config.ts — complete practical configuration
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react-swc'; // SWC for fast transforms
import { resolve } from 'path';

export default defineConfig({
  plugins: [react()],

  resolve: {
    alias: {
      // Path aliases — mirror in tsconfig.json paths
      '@': resolve(__dirname, 'src'),
      '@components': resolve(__dirname, 'src/components'),
      '@hooks': resolve(__dirname, 'src/hooks'),
      '@utils': resolve(__dirname, 'src/utils'),
    },
  },

  server: {
    port: 3000,
    open: true, // open browser on start
    proxy: {
      // Proxy API calls to backend during development
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true,
        rewrite: path => path.replace(/^\/api/, ''),
      },
    },
  },

  build: {
    outDir: 'dist',
    sourcemap: true, // enable for production debugging
    rollupOptions: {
      output: {
        // Manual chunk splitting — keeps vendor separate from app code
        manualChunks: {
          vendor: ['react', 'react-dom'],
          router: ['react-router-dom'],
        },
      },
    },
  },

  // Global test configuration (Vitest)
  test: {
    environment: 'jsdom',
    globals: true,
    setupFiles: './src/test/setup.ts',
  },
});

5. Von CRA zu Vite migrieren

Die Migration von CRA zu Vite ist für die meisten Projekte in ein bis zwei Stunden erledigt. Die Hauptschritte: react-scripts aus den Dependencies entfernen, Vite und das React-Plugin installieren, index.html aus /public in das Projektwurzelverzeichnis verschieben und das %PUBLIC_URL%-Platzhalter-Pattern durch Vites Asset-Handling ersetzen, eine vite.config.ts erstellen und die npm-Scripts in package.json anpassen (vite statt react-scripts start).

Der häufigste Stolperstein bei der Migration sind Umgebungsvariablen. CRA nutzt das Präfix REACT_APP_ für öffentliche Variablen. Vite nutzt VITE_. Alle process.env.REACT_APP_*-Referenzen müssen auf import.meta.env.VITE_* umgestellt werden. Ein zweiter häufiger Stolperstein: CRA erlaubt require() für statische Assets, Vite nicht. Alle Asset-Imports müssen auf ESM-Imports (import logo from './logo.png') umgestellt werden. Jest-Tests, die auf react-scripts test basieren, können zu Vitest migriert werden – beide nutzen ähnliche APIs, die Migration ist minimal.

6. TypeScript und Pfad-Aliase

Vite unterstützt TypeScript ohne zusätzliche Konfiguration out-of-the-box – es verwendet TypeScript nur zur Type-Checking, transformiert die Dateien aber mit Babel oder SWC (je nach Plugin-Wahl). Das bedeutet: TypeScript-Fehler blockieren den Dev-Server nicht. Das ist eine bewusste Design-Entscheidung: Vite optimiert für Geschwindigkeit, und TypeScript-Typprüfung ist teuer. Für CI und Production-Builds sollte tsc --noEmit separat ausgeführt werden.

Pfad-Aliase müssen an zwei Stellen konfiguriert werden: in vite.config.ts unter resolve.alias und in tsconfig.json unter compilerOptions.paths. Beide Konfigurationen müssen übereinstimmen – Vite für die tatsächliche Modulauflösung im Dev/Build, TypeScript für die IDE-Unterstützung und Typprüfung. Die Bibliothek vite-tsconfig-paths kann beide synchronisieren, indem sie die tsconfig.json-Paths automatisch in Vite-Aliase übersetzt – dann muss nur noch tsconfig.json gepflegt werden.

7. Umgebungsvariablen in Vite

Vites Umgebungsvariablen-System ist strukturierter als CRAs Ansatz. Dateien werden in dieser Reihenfolge geladen: .env, .env.local, .env.[mode], .env.[mode].local. Der Modus wird beim Start via --mode Flag gesetzt oder ist standardmäßig development (Dev-Server) oder production (Build). Variablen mit VITE_-Präfix werden im Client-Bundle exponiert und sind via import.meta.env.VITE_VARIABLENNAME zugreifbar. Variablen ohne Präfix bleiben server-seitig – sie sind im Client nicht sichtbar.

import.meta.env enthält zusätzlich einige eingebaute Variablen: MODE (der aktuelle Modus), BASE_URL (die konfigurierte Base-URL), DEV und PROD (booleans für den aktuellen Kontext). Für TypeScript-Unterstützung der eigenen Variablen kann eine src/vite-env.d.ts-Datei erweitert werden, die das ImportMetaEnv-Interface erweitert – damit erhält man Autovervollständigung und Typprüfung für alle eigenen VITE_-Variablen.

8. Production Build und Optimierungen

Der Vite-Production-Build verwendet Rollup und ist in den meisten Projekten ohne weitere Konfiguration optimal. Code-Splitting passiert automatisch: Jeder dynamische Import (const Comp = await import('./Comp')) wird zu einem eigenen Chunk. Statische Imports werden gebündelt und Tree-Shaken. CSS wird extrahiert und minimiert. Assets unterhalb von 4 KB werden als Base64 in den Bundle inlined – dieser Schwellenwert ist via build.assetsInlineLimit konfigurierbar.

Für große Applikationen ist manuelles Chunk-Splitting über build.rollupOptions.output.manualChunks empfehlenswert. React und React-DOM in einen eigenen Vendor-Chunk auslagern – dieser wird separat gecacht, da er sich seltener ändert als der Applikationscode. Mit der Rollup-Visualizer-Plugin können Bundle-Zusammensetzung und Chunk-Größen analysiert werden. Für Brotli-Kompression im Deployment ist das vite-plugin-compression-Plugin minimal zu konfigurieren und erzeugt automatisch .gz- und .br-Varianten aller statischen Assets.

10. Zusammenfassung

Create React App hatte seine Zeit – und hat sehr viele React-Entwickler in die Sprache und das Ökosystem eingeführt. Aber als Deprecated-Projekt ohne aktive Wartung ist es keine tragfähige Basis mehr für neue Projekte oder bestehende Codebasen, die weiterentwickelt werden sollen. Vite ist der moderne Nachfolger für alle Szenarien, die kein vollständiges Framework wie Next.js erfordern: Client-seitige SPAs, Prototypen, interne Tools, Libraries. Die Entwicklererfahrung ist in jeder Dimension besser – schnellerer Start, schnelleres HMR, transparente Konfiguration ohne Eject.

Die Migration bestehender CRA-Projekte ist mit klarem Migrationsplan und dem Verständnis der Unterschiede bei Umgebungsvariablen, Asset-Handling und TypeScript-Setup in wenigen Stunden durchführbar. Für neue Projekte gilt ab 2026: npm create vite@latest -- --template react-swc-ts ist der empfohlene Startbefehl. SWC als Transformer, TypeScript und React Fast Refresh sind sofort bereit, und die Konfigurationsfreiheit von Vite wächst mit dem Projekt – ohne jemals ejecten zu müssen.

11. FAQ: Vite für React