Dieser Artikel zeigt, was sich im Tagesgeschäft der Entwicklung von ilert-ui am schnellsten anfühlte – einer großen React- und TypeScript-App mit vielen lazy Routes. Wir sind zunächst von Create React App (CRA) auf moderne Tooling-Stacks umgestiegen, haben Vite für die lokale Entwicklung erprobt und sind letztlich bei webpack-dev-server + React Fast Refresh gelandet.
Scope: Nur lokale Entwicklung. Unsere Production-Builds bleiben auf Webpack. Zum Kontext: Das React-Team hat CRA am 14. Februar 2025 offiziell abgekündigt und empfiehlt die Migration zu einem Framework oder einem modernen Build-Tool wie Vite , Parcel oder RSBuild .
Qualitative Field Notes aus ilert-ui : Wir haben keine formalen Benchmarks durchgeführt; es geht um unsere Alltagserfahrungen in einer großen, per Route gesplitteten App.
Mini‑Glossar Hier sind die hilfreichen Begriffe, denen Sie in diesem Artikel begegnen werden.
ESM : Das native JavaScript-Modulsystem, das Browser verstehen.HMR : Tauscht geänderten Code in einer laufenden App aus, ohne einen vollständigen Reload.React Fast Refresh : Reacts HMR-Erlebnis, das Komponenten-State nach Möglichkeit erhält.Lazy Route / Code-Splitting : Lädt den Code einer Route erst, wenn die Route besucht wird.Vendor Chunk : Ein Bundle gemeinsamer Third-Party-Abhängigkeiten, das über Routen hinweg gecacht wird.Eager Pre-Bundling : Bündelt gemeinsame Abhängigkeiten vorab, um viele kleine Requests später zu vermeiden.Dependency Optimizer (Vite) : Pre-bundelt Bare Imports; kann erneut laufen, wenn zur Laufzeit neue Abhängigkeiten entdeckt werden.Type-aware ESLint : ESLint, das TypeScript-Typinformationen nutzt – genauer, aber schwergewichtiger.Warum wir CRA verlassen haben Problemstellung: ilert-ui ist den Bequemlichkeits-Defaults von CRA entwachsen, während die App reifte.
Das hat uns von CRA weggetrieben:
Customization-Reibung: Fortgeschrittene Webpack-Tweaks (Custom Loader, striktere Split-Chunks-Strategie, Babel-Einstellungen für react-refreshGroße Abhängigkeitsfläche: react-scripts
Ziel für den nächsten Schritt
React + TS beibehalten. Time-to-Interactiv e nach Serverstart verbessern.State bei Edits erhalten (Fast-Refresh-Verhalten) und HMR reaktionsschnell halten. Vorhersagbare First-Visit-Latenz beim Navigieren über viele lazy Routes behalten. Warum Vite wie die bessere Lösung aussah Während der Entwicklung dient Vite Ihren Source Code als natives ESM und pre-bundelt Bare Imports aus node_modulesesbuild . Das liefert üblicherweise sehr schnelle Cold Starts und responsives HMR.
Was wir sofort geliebt haben
Cold Starts: Spürbar schneller als unsere CRA-Baseline.Minimale Konfiguration, saubere DX: Sinnvolle Defaults und gut lesbare Fehler.Großartiges HMR in bereits besuchten Bereichen: Edits innerhalb schon besuchter Routen fühlten sich exzellent an.
Wo das Modell an unserer Größe rieb
In Codebasen mit vielen lazy Routes können Erstbesuche Schübe von ESM-Requests auslösen, und wenn zur Laufzeit neue Abhängigkeiten entdeckt werden, läuft der Dependency-Optimizer erneut, was die Seite neu lädt. Das ist erwartetes Verhalten, machte die Cross-Route-Erkundung für uns aber uneinheitlich.
Qualitative Field Notes aus ilert-ui Methodik: qualitative Beobachtungen aus der täglichen Entwicklung in ilert-ui.
Die Form unseres Repos
Dutzende lazy Routes, mehrere schwere Bereiche, die viele Module hereinziehen. Hunderte geteilte Dateien und tiefe Store-Imports über Features hinweg.
Was wir bemerkten
Erstbesuch schwerer Routen: Das Öffnen einer abhängigkeit strächtigen Route löste oft viele ESM-Requests und manchmal einen erneuten Dep-Optimizer-Lauf aus. Cross-Route-Erkundung über unberührte Routen fühlte sich langsamer an als in unserem Webpack-Setup, das gemeinsame Vendors frühzeitig pre-bundelt.Typed-ESLint-Overhead: Type-aware ESLint (mit parserOptions.projectprojectService
TL;DR für unsere Codebase: Vite war fantastisch, sobald eine Route in der Session einmal berührt war, aber die Erstbesuche über viele lazy Routes hinweg waren weniger vorhersehbar.
Warum wir auf webpack-dev-server + React Fast Refresh gewechselt haben Was wir betreiben
webpack-dev-server mit HMR. React Fast Refresh via @pmmmwh/react-refresh-webpack-pluginreact-refresh Webpack SplitChunks für gemeinsame Vendor-Bundles; Filesystem-Caching; Source Maps; Error Overlays; ESLint out-of-process.
Warum es sich für unser Team end-to-end schneller anfühlte
Eager Vendor Pre-Bundling: Wir pre-bundeln Vendor-Chunks explizit (React, MUI, MobX, Charts, Editor, Kalender etc.). Der allererste Load ist etwas schwerer, aber Erstbesuche anderer Routen sind schneller, weil gemeinsame Abhängigkeiten bereits gecacht sind. SplitChunks macht das vorhersagbar.Ergonomie von React Fast Refresh: Solide State-Erhaltung bei Edits, verlässliche Fehlererholung und Overlays, die wir mögen.Nicht blockierendes Linting: Typed ESLint läuft außerhalb des Dev-Server-Prozesses, sodass HMR selbst während großer Type-Checks responsiv bleibt.Belege – die Stellschrauben, an denen wir gedreht haben // webpack.config.js
module.exports = {
optimization: {
minimize: false ,
runtimeChunk: "single" ,
splitChunks: {
chunks: "all" ,
cacheGroups: {
"react-vendor" : {
test: /[\/\]node_modules[\/\](react|react-dom|react-router-dom)[\/\]/,
name: "react-vendor" ,
chunks: "all" ,
priority: 30 ,
},
"mui-vendor" : {
test: /[\/\]node_modules[\/\](@mui\/material|@mui\/icons-material|@mui\/lab|@mui\/x-date-pickers)[\/\]/,
name: "mui-vendor" ,
chunks: "all" ,
priority: 25 ,
},
"mobx-vendor" : {
test: /[\/\]node_modules[\/\](mobx|mobx-react|mobx-utils)[\/\]/,
name: "mobx-vendor" ,
chunks: "all" ,
priority: 24 ,
},
"utils-vendor" : {
test: /[\/\]node_modules[\/\](axios|moment|lodash\.debounce|lodash\.isequal)[\/\]/,
name: "utils-vendor" ,
chunks: "all" ,
priority: 23 ,
},
"ui-vendor" : {
test: /[\/\]node_modules[\/\](@loadable\/component|react-transition-group|react-window)[\/\]/,
name: "ui-vendor" ,
chunks: "all" ,
priority: 22 ,
},
"charts-vendor" : {
test: /[\/\]node_modules[\/\](recharts|reactflow)[\/\]/,
name: "charts-vendor" ,
chunks: "all" ,
priority: 21 ,
},
"editor-vendor" : {
test: /[\/\]node_modules[\/\](@monaco-editor\/react|monaco-editor)[\/\]/,
name: "editor-vendor" ,
chunks: "all" ,
priority: 20 ,
},
"calendar-vendor" : {
test: /[\/\]node_modules[\/\](@fullcalendar\/core|@fullcalendar\/react|@fullcalendar\/daygrid)[\/\]/,
name: "calendar-vendor" ,
chunks: "all" ,
priority: 19 ,
},
"vendor" : {
test: /[\/\]node_modules[\/\]/,
name: "vendor" ,
chunks: "all" ,
priority: 10 ,
},
},
},
},
};
// vite.config.ts - Vite optimizeDeps includes we tried
export default defineConfig({
optimizeDeps : {
include : [
"react" ,
"react-dom" ,
"react-router-dom" ,
"@mui/material" ,
"@mui/icons-material" ,
"@mui/lab" ,
"@mui/x-date-pickers" ,
"mobx" ,
"mobx-react" ,
"mobx-utils" ,
"axios" ,
"moment" ,
"lodash.debounce" ,
"lodash.isequal" ,
"@loadable/component" ,
"react-transition-group" ,
"react-window" ,
"recharts" ,
"reactflow" ,
"@monaco-editor/react" ,
"monaco-editor" ,
"@fullcalendar/core" ,
"@fullcalendar/react" ,
"@fullcalendar/daygrid" ,
],
// Force pre-bundling of these dependencies
force : true ,
},
});
Ergebnis : Half bei einigen Cold Starts, glättete in unserem Repo jedoch die First-Visit-Latenz über viele lazy Routes hinweg nicht so stark wie die eager Vendor-Chunks in Webpack.
Was wir versucht haben, um Vite zu beschleunigen (und was nicht) Was wir in Vite versucht haben ESLint in einem separaten Prozess ausführen Was es tut: Lintet im Hintergrund, statt den Dev-Server zu blockieren.Auswirkung: Schnelleres Feedback beim Editieren.
Filesystem-Cache aktivieren Was es tut: Wiederverwendet Build-Ergebnisse über Neustarts hinweg.Auswirkung: Schnellere Cold Starts und Rebuilds.
Third-Party-Code vorbündeln (Vendor Split) Was es tut: Bündelt Bibliotheken wie React einmal und hält sie getrennt vom App-Code.Auswirkung: Weniger Arbeit bei jedem Save; flinkeres HMR.
Diese Tweaks ließen Vite besser wirken – waren aber nicht genug, um unsere größeren Performance-Themen zu lösen. Darum haben wir Webpack evaluiert.
Dinge, die wir hätten versuchen können Aggressiveres Tuning von optimizeDeps Warum wir es ausließen: Kann großen Projekten helfen, erfordert aber sorgfältiges Profiling und laufende Dependency-Hygiene. Der Zeitaufwand überwog den erwartbaren Gewinn für uns.
„Warm Crawl“ beim Serverstart Was es ist: Ein Script, das beim Start Routen besucht, um Module und Caches vorzuladen.Warum wir es ausließen: Zusätzliche Komplexität und uneinheitlicher Nutzen in realen Projekten.
Versionen für gelinkte Pakete pinnen
Was es ist: Versionen in einem Monorepo sperren, um Vites Re-Optimization-Churn zu reduzieren.Warum wir es ausließen: In manchen Setups nützlich, aber zusätzlicher Wartungsaufwand; vor einem größeren Rework nicht lohnend.
Vor- und Nachteile (in unserem Kontext) Vite – Vorteile Rasante Cold Starts und leichtgewichtige Konfiguration. Exzellentes HMR innerhalb bereits berührter Routen. Starkes Plugin-Ökosystem und moderne ESM-Defaults.
Vite – Nachteile Dep-Optimizer-Re-Runs können den Flow beim erstmaligen Navigieren über viele lazy Routes unterbrechen. Erfordert in großen Monorepos und mit gelinkten Paketen sorgfältiges Setup. Typed ESLint im Prozess kann die Responsiveness bei großen Projekten schmälern; besser out-of-process.
Webpack + Fast Refresh – Vorteile Vorhersagbare First-Visit-Latenz über viele Routen dank eager Vendor-Chunks. Feinkörnige Kontrolle über Loader, Plugins und Output. Fast Refresh erhält State und bietet ausgereifte Error Overlays.
Webpack + Fast Refresh – Nachteile Schwererer initialer Load als Vites Cold Start. Mehr Konfigurationsoberfläche zu pflegen. Historische Komplexität (abgemildert durch moderne Config-Patterns und Caching). Schnelle Performance-Tests, die Sie lokal für Ihr Projekt durchführen können Diese Checks sind schnelle, menschliche Benchmarks – kein Profiler nötig. Nutzen Sie eine Stoppuhr und DevTools, um reale Interaktionsverzögerungen und die wahrgenommene Flüssigkeit zu vergleichen.
Cold Start
So testen Sie: Starten Sie den Dev-Server neu und messen Sie die Zeit von npm run dev bis zur ersten interaktiven Seitenladung (eine Stoppuhr reicht aus).
Beobachtung: Vite startet typischerweise schneller aus dem Kalten. Webpack bleibt mit Filesystem-Cache akzeptabel, sobald es warm ist.
Erstbesuch einer schweren Route
So testen Sie: Öffnen Sie eine abhängigkeitsschwere Route zum ersten Mal. Beobachten Sie DevTools → Network und Console auf Optimizer-Runs oder Request-Schübe.
Beobachtung: Vite kann gelegentlich Re-Optimizations und Reloads auslösen. Webpacks Vendor-Chunks machen Erstbesuche tendenziell gleichmäßiger.
Cross-Route-Navigation
So testen Sie: Navigieren Sie durch mehrere unberührte Routen und notieren Sie die Responsiveness, bis jede interaktiv ist.
Beobachtung: Vite verbessert sich nach den initialen Loads (da Module gecacht sind). Webpack bleibt über Routen hinweg konsistent vorhersagbar.
Linting-Einfluss
So testen Sie: Vergleichen Sie ESLint im Prozess mit einem separaten Prozess. Messen Sie die Tipp-Responsiveness und die HMR-Geschmeidigkeit.
Beobachtung: ESLint out-of-process hielt den Dev-Server responsiv und bewahrte in beiden Setups ein geschmeidiges HMR.
Ausgewogene Guidance – wann wir welches wählen würden Wählen Sie Vite, wenn:
Cold Starts Ihren Workflow dominieren. Ihr Modulgraph nicht riesig ist oder nicht in viele lazy Routes fragmentiert. Plugins – insbesondere typed ESLint – sind leicht oder laufen out-of-process.
Wählen Sie Webpack + Fast Refresh, wenn:
Ihre App von eager Vendor-Pre-Bundling und vorhersagbarer First-Visit-Latenz über viele Routen profitiert. Sie präzise Kontrolle über Loader/Plugins und Build-Output wünschen. Sie Fast Refreshs State-Erhaltung und Overlays mögen. Fazit Sowohl Vite als auch Webpack sind exzellent. Angesichts der aktuellen Größe und Navigationsmuster von ilert-ui liefert webpack-dev-server + React Fast Refresh heute für uns die engste Feedback-Schleife – basierend auf qualitativer Developer-Experience, nicht auf Mikro-Benchmarks. Wir messen weiter, während sich unsere Codebase entwickelt, und werden Vite oder ein Framework erneut prüfen, wenn sich unsere Constraints ändern.
.png)
