Die Geschichte und der Fall von Create React App, einer Legende der Webentwicklung

Erinnern Sie sich an 2016? Damals war es, als würde man versuchen, ein einfaches React-Projekt schnell aufzusetzen, wie ein Regal ohne Anleitung zusammenzubauen. Man musste Webpack manuell konfigurieren, Babel einrichten, Konfigurationen für CSS-Loader schreiben und einen lokalen Dev-Server aufsetzen. Die Einrichtung der Umgebung dauerte einen ganzen Tag, obwohl man noch keine einzige Zeile seines eigentlichen Anwendungscodes angefasst hatte.

Dann veröffentlichte Facebook Create React App (CRA). Ein einziger npx create-react-app my-app Befehl erzeugte ein sofort einsatzbereites Projekt. Keine Eingabeaufforderungen, keine Dialogfelder, keine Tausenden von Konfigurationszeilen.

Heute ist dieses Tool offiziell als veraltet markiert und in den langfristigen Ruhestand geschickt worden. Die React-Dokumentation rät direkt zum Wechsel zu Alternativen wie Vite oder Next.js. Lassen Sie uns erkunden, wie CRA die Frontend-Branche transformierte, was unter der Haube steckte und warum seine Ära zu Ende ging.

Was Create React App leistete

Die Idee des Tools passte perfekt in das Konzept der „Zero-Configuration". Der Entwickler erhielt einen funktionierenden Stack, ohne sich in Build-Tool-Einstellungen einarbeiten zu müssen.

Die gesamte Infrastruktur war in einem einzigen Paket versteckt — react-scripts. Es war eine Black Box, die Webpack, Babel, ESLint und PostCSS enthielt.

Ein schneller Start sah so aus:

npx create-react-app my-app
cd my-app
npm start

Nach etwa dreißig Sekunden öffnete sich eine Seite in Ihrem Browser unter http://localhost:3000.

Die Verzeichnisstruktur war extrem sauber. Keine .babelrc oder webpack.config.js Dateien im Stammverzeichnis:

my-app
├── README.md
├── node_modules
├── package.json
├── public
│   ├── favicon.ico
│   ├── index.html
│   └── manifest.json
└── src
    ├── App.css
    ├── App.js
    ├── App.test.js
    ├── index.css
    └── index.js

Wie es unter der Haube funktionierte

CRA basierte auf drei Prinzipien: einer einzigen Build-Abhängigkeit, keiner anfänglichen Einrichtung und einem Escape-Hatch-Befehl.

Einzelne Abhängigkeit

Zuvor wurde das Aktualisieren der Tooling zum Albtraum. Webpack aktualisiert — Babel funktionierte nicht mehr. Babel aktualisiert — ein ESLint-Plugin funktionierte nicht mehr.

Bei CRA war react-scripts für alles verantwortlich. Das Aktualisieren dieser einen Bibliothek aktualisierte die gesamte Build-Kette darunter. Es bündelte:

• JSX-, ES6+- und TypeScript-Unterstützung standardmäßig
• Automatische Vendor-Präfix-Injektion in CSS über Autoprefixer
• Interaktive Testläufe mit Jest und Dateiüberwachung
• Build-Fehler-Overlays direkt im Browser

Wenn Sie einen Tippfehler in der Syntax machten, zeigte CRA einen klaren Bildschirm mit der genauen Zeile und dem Zeichen:

Der Eject-Mechanismus

Was, wenn die Standardkonfiguration nicht ausreichte? Sagen wir, Sie brauchten ein seltenes Plugin zur Verarbeitung bestimmter Dateitypen.

Für solche Fälle fügten die Entwickler den npm run eject Befehl hinzu. Er drehte das Projekt buchstäblich um: Entfernte react-scripts und kopierte alle Hunderte von Webpack- und Babel-Konfigs direkt in Ihr Projekt.

Dies war eine Einbahnstraße. Es gab keine Möglichkeit, die saubere Struktur zurückzubekommen, und Sie mussten das wachsende Konfigurationschaos selbst pflegen.

Warum Create React App veraltet wurde

Die Zeit arbeitete gegen CRA. Technologien entwickelten sich weiter, und die architektonischen Entscheidungen des Tools wurden zu Schwächen.

Erstens, Geschwindigkeit. Webpack analysiert beim Start des Dev-Servers das gesamte Projekt von Grund auf neu. Wenn ein Projekt auf Hunderte von Komponenten anwächst, dauern Start und Hot Reload Dutzende von Sekunden. Vite, das später kam, verwendet native Browser-ES-Module und baut Code on-the-fly mit dem blitzschnellen Go-Compiler esbuild.

Zweitens, die Verlagerung hin zu SSR und Server-Komponenten. CRA konnte nur client-zentrische Single Page Applications (SPA) erstellen — eine leere HTML-Datei, die mit Skripten im Browser des Benutzers gefüllt wurde. Gutes SEO und eine schnelle erste Darstellung erforderten serverseitiges Rendering, das CRA einfach nicht bieten konnte.

Drittens, aufgeblähte Größe. Der node_modules Ordner für ein frisch erstelltes Projekt wog Hunderte von Megabytes, und das Installieren der Abhängigkeiten dauerte ein paar Minuten, selbst bei schneller Verbindung.

Was statt CRA verwenden

Der offizielle React-Leitfaden gibt klare Richtungen vor:

• Vite — wenn Sie eine schnelle SPA, ein Hobbyprojekt oder einen persönlichen Blog ohne serverseitiges Rendering benötigen. Es startet in Millisekunden und läuft spürbar schneller.
• Next.js oder Remix — wenn Sie eine vollwertige Produktionsanwendung mit SSR, Routing, Bildoptimierung und Server-Komponenten erstellen.
• Expo — wenn Sie eine plattformübergreifende mobile App mit React Native schreiben möchten.

Erinnerung an eine Legende

Create React App leistete das Wichtigste: Es setzte einen hohen Standard für die Developer Experience. Es zeigte der gesamten Branche, dass das Erstellen einer Webanwendung einfach sein und kein tiefes Webpack-Wissen an Ihrem allerersten Arbeitstag erfordern konnte.

Heute hat das Starten neuer ernsthafter Projekte mit CRA keinen praktischen Nutzen mehr. Aber wenn Sie auf ein drei Jahre altes Tutorial stoßen oder schnell eine Sandbox aufsetzen müssen — CRA funktioniert immer noch.