L'histoire et la chute de Create React App, une légende du développement web

Vous souvenez-vous de 2016 ? Essayer de créer rapidement un simple projet React était comme assembler un placard sans notice. Vous deviez configurer Webpack manuellement, paramétrer Babel, écrire des configurations pour les loaders CSS, et mettre en place un serveur de développement local. Configurer l'environnement prenait une journée entière, alors même que vous n'aviez pas touché une seule ligne de votre code applicatif.

Puis Facebook a publié Create React App (CRA). Une seule commande npx create-react-app my-app générait un projet prêt à l'emploi. Pas d'invites, pas de boîtes de dialogue, pas des milliers de lignes de configuration.

Aujourd'hui, cet outil a été officiellement marqué comme obsolète et mis en retraite longue durée. La documentation React conseille directement de passer à des alternatives comme Vite ou Next.js. Explorons comment CRA a transformé l'industrie du frontend, ce qui se cachait sous le capot, et pourquoi son ère a pris fin.

Ce que faisait Create React App

L'idée de l'outil s'inscrivait dans le concept de « zéro configuration ». Le développeur obtenait une stack fonctionnelle sans avoir à se plonger dans les paramètres des outils de build.

Toute l'infrastructure était masquée dans un seul package — react-scripts. C'était une boîte noire contenant Webpack, Babel, ESLint et PostCSS.

Un démarrage rapide ressemblait à ceci :

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

Après environ trente secondes, une page s'ouvrait dans votre navigateur à l'adresse http://localhost:3000.

La structure du répertoire était extrêmement propre. Pas de fichiers .babelrc ou webpack.config.js à la racine :

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

Comment ça fonctionnait sous le capot

CRA reposait sur trois principes : une seule dépendance de build, zéro configuration initiale, et une commande de sortie de secours.

Dépendance unique

Auparavant, mettre à jour les outils relevait de l'enfer. Vous mettiez à jour Webpack — Babel cassait. Vous mettiez à jour Babel — un plugin ESLint cessait de fonctionner.

Dans CRA, react-scripts était responsable de tout. Mettre à jour cette seule bibliothèque mettait à jour toute la chaîne de build en dessous. Elle regroupait :

• Support JSX, ES6+ et TypeScript prêt à l'emploi
• Injection automatique de préfixes vendeur en CSS via Autoprefixer
• Exécutions de tests interactives avec Jest et surveillance des fichiers
• Overlays d'erreurs de build directement dans le navigateur

Si vous faisiez une faute de syntaxe, CRA affichait un écran clair pointant vers la ligne et le caractère exacts :

Le mécanisme d'eject

Et si la configuration par défaut ne suffisait pas ? Disons que vous aviez besoin d'un plugin rare pour traiter des types de fichiers spécifiques.

Pour ces cas, les créateurs ont ajouté la commande npm run eject. Elle retournait littéralement le projet comme une chaussette : elle supprimait react-scripts et copiait toutes les centaines de lignes de configurations Webpack et Babel directement dans votre projet.

C'était un billet aller simple. Il n'y avait aucun moyen de retrouver la structure propre, et vous deviez maintenir ce bazar de configuration vous-même.

Pourquoi Create React App est devenu obsolète

Le temps a joué contre CRA. Les technologies ont avancé, et les décisions architecturales de l'outil se sont transformées en faiblesses.

Premièrement, la vitesse. Webpack recompile et analyse l'intégralité du projet depuis le début au démarrage du serveur de dev. Quand un projet grandit jusqu'à des centaines de composants, le démarrage et le hot reload prennent des dizaines de secondes. Vite, arrivé plus tard, utilise les modules ES natifs du navigateur et construit le code à la volée avec le compilateur Go ultra-rapide esbuild.

Deuxièmement, le virage vers le SSR et les composants serveur. CRA ne pouvait construire que des applications monopages (SPA) centrées sur le client — un fichier HTML vide qui se remplissait de scripts dans le navigateur de l'utilisateur. Un bon SEO et un premier affichage rapide nécessitaient un rendu côté serveur, ce que CRA ne pouvait tout simplement pas fournir.

Troisièmement, la taille pléthorique. Le dossier node_modules d'un projet fraîchement créé pesait des centaines de mégaoctets, et installer les dépendances prenait quelques minutes même sur une connexion rapide.

Qu'utiliser à la place de CRA

Le guide officiel React donne des directives claires :

• Vite — si vous avez besoin d'une SPA rapide, d'un projet personnel, ou d'un blog sans rendu côté serveur. Il démarre en millisecondes et fonctionne sensiblement plus vite.
• Next.js ou Remix — si vous construisez une application de production complète avec SSR, routage, optimisation d'images et composants serveur.
• Expo — si vous prévoyez d'écrire une application mobile multiplateforme avec React Native.

Mémoire d'une légende

Create React App a fait la chose la plus importante : il a fixé un standard élevé pour l'Expérience Développeur. Il a montré à toute l'industrie que construire une application web pouvait être simple et ne pas nécessiter de connaissances approfondies en Webpack dès votre premier jour de travail.

Commencer de nouveaux projets sérieux sur CRA aujourd'hui n'a aucune valeur pratique. Mais si vous tombez sur un tutoriel vieux de trois ans ou besoin de créer rapidement un bac à sable — CRA fonctionnera toujours.