Le React Compiler passe en Rust, et Next.js 16.3 peut déjà l'utiliser

L'équipe React a réécrit le React Compiler en Rust, et les résultats commencent à se voir dans les temps de build réels. Le portage en Rust a atterri dans le monorepo React début juin (PR #36173), et Vercel l'a intégré à Turbopack quelques semaines plus tard. Avec Next.js 16.3, vous pouvez désormais opter pour le compilateur natif et ignorer complètement l'ancien chemin Babel.

Petit rappel pour ceux qui n'y ont pas encore touché : le React Compiler (autrefois appelé React Forget) mémoïse automatiquement vos composants et hooks, ce qui vous évite d'écrire manuellement useMemo et useCallback. Il est stable dans Next.js depuis la version 16.0. Le problème résidait dans son fonctionnement. En tant que transformation Babel, il ajoutait une surcharge d'exécution JavaScript à chaque build, et sur les grandes applications, cela devenait un véritable goulot d'étranglement pendant que le pipeline Rust de Turbopack attendait.

Ce qui est réellement plus rapide

La réécriture en Rust change la donne. L'équipe React indique que le portage s'exécute environ 3 fois plus vite en tant que plugin Babel, et jusqu'à 10 fois sur la logique de transformation isolée. Le gain le plus important survient quand le compilateur cesse d'être un plugin. Intégré directement à Turbopack, Andrew Imm de Vercel a mesuré plus de 40 % de gain de compilation sur v0, leur grande application Next.js, en partie parce que l'ancien chemin via le plugin SWC souffrait d'un démarrage à froid lent via WebAssembly. Les chiffres officiels de Next.js se situent entre 20 et 50 % de compilation des routes plus rapide sur leurs applications de test.

Une mise en garde honnête avant de s'emballer : c'est expérimental, et l'équipe React a qualifié le portage lui-même de travail en cours. L'architecture a été guidée par des humains mais, de l'aveu même de l'auteur, largement écrite par une IA. Tous les tests du compilateur passent et le résultat correspond à la version TypeScript pour 99,9 % de la base de code de Meta. Mais 99,9 % n'est pas 100 %, et ce n'est pas sans raison que c'est opt-in.

Comment nous procéderions

Quand nous construisons des applications cloud-native pour des clients enterprise, un changement de compilateur ou de bundler est exactement le type de modification qui paraît gratuite et qui finit par dévorer un sprint. Traitez donc ça comme un exercice de mesure, pas de foi.

Activez-le dans une branche, pas dans votre build principal. Avec Next.js 16.3, les options sont explicites : définissez reactCompiler: true et experimental.turbopackRustReactCompiler: true, et gardez à l'esprit que cela n'affecte que le chemin Turbopack, pas --webpack. Ensuite, mesurez votre propre application. La fourchette de 20 à 50 % est le chiffre de Vercel sur les applications de Vercel. Votre gain dépend de la densité en compilation de vos composants et de la froideur de démarrage de vos caches CI.

Le point que nous surveillerions le plus attentivement est la parité des sorties. Un compilateur qui mémoïse légèrement différemment peut modifier le comportement de rendu d'une façon que vos tests unitaires ne détectent pas. D'après notre expérience en PHP et Docker, nous avons appris à épingler les versions de la chaîne d'outils en CI et à comparer les sorties de build entre l'ancien et le nouveau chemin avant de livrer. Faites de même ici : lancez votre suite end-to-end complète sur le chemin Rust, comparez les sorties du bundle, et gardez le chemin Babel comme repli à un seul paramètre jusqu'à ce que vous lui fassiez confiance.

Le signal plus profond

Il y a une tendance de second ordre qui mérite d'être mentionnée. C'est une partie du mouvement continu des outils frontend vers Rust. SWC s'appuie désormais sur le compilateur Rust officiel, Oxc le distribue en crates, et Rspack 2.1 a ajouté le support natif. Toutes les tentatives n'ont pas été sans heurts — le mainteneur de Rolldown a retiré son intégration du React Compiler Rust pour la peaufiner d'abord —, donc la transition n'est pas terminée. Mais la direction est fixée. Si votre outillage de build est un empilement de loaders Webpack personnalisés et de requires dynamiques, cette dette va devenir de plus en plus coûteuse à porter.

Les équipes mobile ne devraient pas ignorer ça non plus. Dans nos projets natifs et React Native, le même schéma se répète : le compilateur y tourne aussi, et des temps de build prévisibles comptent encore plus quand votre CI jongle déjà avec des chaînes d'outils natives. Et du côté sécurité, nos engagements de pentest nous ont appris quelque chose d'ennuyeux mais réel. Chaque nouvelle dépendance de build représente une nouvelle surface d'attaque sur la chaîne d'approvisionnement. Un compilateur expérimental assisté par IA dans votre pipeline mérite une revue des dépendances, pas une installation à l'aveugle.

Une chose à faire aujourd'hui

Même si vous n'activez jamais l'option Rust : si vous êtes sur Next.js et n'utilisez pas encore du tout le React Compiler, c'est là que se trouve le vrai gain manqué. Activez reactCompiler sur une branche, supprimez un lot d'appels manuels à useMemo et useCallback, et mesurez l'impact sur le rendu et le build. Le portage Rust rend simplement ce chemin moins coûteux à adopter plus tard, une fois qu'il sortira de l'expérimental.

Si la chasse aux temps de build ou le démêlage d'une montagne de configs de bundler personnalisées vous parle, parlons-en. Nous aidons les équipes web et mobile à livrer plus vite sans miser la production sur un flag expérimental.