Comment nous avons reconstruit Next.js avec l'IA en une semaine
Comment nous avons reconstruit Next.js avec l'IA en une semaine, l'interface API Next.js vinext permet de créer des applications de production jusqu'à 4 fois plus rapidement, par Steve Faulkner
Next.js est un framework de développement web open source full-stack créé par la société privée Vercel, qui fournit des applications web basées sur React avec rendu côté serveur et rendu statique. La documentation React mentionne Next.js parmi les « chaînes d'outils recommandées » et le conseille aux développeurs qui « créent un site web rendu côté serveur avec Node.js ». Alors que les applications React traditionnelles ne peuvent rendre leur contenu que dans le navigateur côté client, Next.js étend cette fonctionnalité pour inclure les applications rendues côté serveur. Les droits d'auteur et les marques commerciales de Next.js sont détenus par Vercel, qui assure également la maintenance et dirige son développement open source.
La semaine dernière, un ingénieur et un modèle d'IA ont reconstruit de zéro le framework front-end le plus populaire. Le résultat, vinext (prononcé « vee-next »), est un remplacement direct de Next.js, construit sur Vite, qui se déploie sur Cloudflare Workers à l'aide d'une seule commande. Lors des premiers benchmarks, il construit des applications de production jusqu'à 4 fois plus rapidement et produit des bundles clients jusqu'à 57 % plus petits. Et nous avons déjà des clients qui l'utilisent en production.
Le tout a coûté environ 1 100 dollars en jetons.
Le problème de déploiement de Next.js
Next.js est le framework React le plus populaire. Des millions de développeurs l'utilisent. Il alimente une grande partie du web de production, et pour cause. L'expérience développeur est excellente.
Mais Next.js pose un problème de déploiement lorsqu'il est utilisé dans un écosystème sans serveur plus large. Les outils sont entièrement sur mesure : Next.js a investi massivement dans Turbopack, mais si vous souhaitez le déployer sur Cloudflare, Netlify ou AWS Lambda, vous devez reprendre le résultat de la compilation et le remodeler en quelque chose que la plateforme cible peut réellement exécuter.
Si vous vous dites : « N'est-ce pas ce que fait OpenNext ? », vous avez raison.
C'est en effet le problème qu'OpenNext a été conçu pour résoudre. De nombreux efforts d'ingénierie ont été consacrés à OpenNext par plusieurs fournisseurs, dont nous chez Cloudflare. Cela fonctionne, mais se heurte rapidement à des limites et devient un jeu de tape-taupe.
S'appuyer sur le résultat de Next.js comme base s'est avéré être une approche difficile et fragile. Comme OpenNext doit procéder à une ingénierie inverse du résultat de la compilation de Next.js, cela entraîne des changements imprévisibles entre les versions, qui demandent beaucoup de travail pour être corrigés.
Next.js travaille sur une API d'adaptateurs de premier ordre, et nous collaborons avec eux à ce sujet. Il s'agit encore d'un projet naissant, mais même avec des adaptateurs, vous continuez à vous appuyer sur la chaîne d'outils Turbopack sur mesure. Et les adaptateurs ne couvrent que la construction et le déploiement. Pendant le développement, next dev fonctionne exclusivement dans Node.js, sans possibilité d'intégrer un autre runtime. Si votre application utilise des API spécifiques à la plateforme telles que Durable Objects, KV ou AI bindings, vous ne pouvez pas tester ce code en développement sans recourir à des solutions de contournement.
Présentation de vinext
Et si, au lieu d'adapter la sortie de Next.js, nous réimplémentions directement l'interface API de Next.js sur Vite ? Vite est l'outil de compilation utilisé par la plupart des écosystèmes front-end en dehors de Next.js, qui alimente des frameworks tels que Astro, SvelteKit, Nuxt et Remix. Une réimplémentation propre, pas simplement un wrapper ou un adaptateur. Honnêtement, nous ne pensions pas que cela fonctionnerait. Mais nous sommes en 2026, et le coût de développement des logiciels a complètement changé.
Nous sommes allés beaucoup plus loin que prévu.
Code : Sélectionner tout - Visualiser dans une fenêtre à part npm install vinext
Remplacez next par vinext dans vos scripts et tout le reste reste inchangé. Vos fichiers app/, pages/ et next.config.js existants fonctionnent tels quels.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3vinext dev # Development server with HMR vinext build # Production build vinext deploy # Build and deploy to Cloudflare Workers
Il ne s'agit pas d'un wrapper autour de Next.js et de la sortie Turbopack. Il s'agit d'une implémentation alternative de la surface API : routage, rendu serveur, composants React Server, actions serveur, mise en cache, middleware. Le tout est construit sur Vite en tant que plugin. Plus important encore, la sortie Vite fonctionne sur n'importe quelle plateforme grâce à l'API Vite Environment.
Les chiffres
Les premiers benchmarks sont prometteurs. Nous avons comparé vinext à Next.js 16 à l'aide d'une application App Router partagée à 33 routes. Les deux frameworks effectuent le même travail : compilation, regroupement et préparation des routes rendues par le serveur. Nous avons désactivé la vérification de type TypeScript et ESLint dans la compilation de Next.js (Vite ne les exécute pas pendant les compilations) et avons utilisé force-dynamic afin que Next.js ne passe pas de temps supplémentaire à pré-rendre les routes statiques, ce qui ralentirait injustement ses chiffres. L'objectif était de mesurer uniquement la vitesse du regroupement et de la compilation, rien d'autre. Les benchmarks sont exécutés sur GitHub CI à chaque fusion vers le réseau principal.
Temps de compilation en production :
Taille du bundle client (compressé au format gzip) :
Ces benchmarks mesurent la vitesse de compilation et de regroupement, et non les performances de service en production. Le dispositif de test est une application unique à 33 routes, et non un échantillon représentatif de toutes les applications de production. Nous nous attendons à ce que ces chiffres évoluent à mesure que les trois projets continuent à se développer. La méthodologie complète et les résultats historiques sont publics. Considérez-les comme indicatifs et non définitifs.
La tendance est toutefois encourageante. L'architecture de Vite, et en particulier Rolldown (le bundler basé sur Rust qui sera intégré à Vite 8), présente des avantages structurels pour les performances de compilation qui apparaissent clairement ici.
Déploiement sur Cloudflare Workers
vinext est construit avec Cloudflare Workers comme première cible de déploiement. Une seule commande vous permet de passer du code source à un Worker en cours d'exécution :
Code : Sélectionner tout - Visualiser dans une fenêtre à part vinext deploy
Cela gère tout : la construction de l'application, la génération automatique de la configuration du Worker et le déploiement. L'App Router et le Pages Router fonctionnent tous deux sur Workers, avec une hydratation complète côté client, des composants interactifs, une navigation côté client et l'état React.
Pour la mise en cache de production, vinext inclut un gestionnaire de cache Cloudflare KV qui vous offre une régénération statique incrémentielle (ISR) prête à l'emploi :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
KV est un bon choix par défaut pour la plupart des applications, mais la couche de mise en cache est conçue pour être modulable. L'appel setCacheHandler signifie que vous pouvez échanger n'importe quel backend qui vous semble pertinent. R2 peut être plus adapté aux applications avec des charges utiles mises en cache importantes ou des modèles d'accès différents. Nous travaillons également à l'amélioration de notre API Cache qui devrait fournir une couche de mise en cache solide avec moins de configuration. L'objectif est la flexibilité : choisissez la stratégie de mise en cache qui convient à votre application.
Exemples en direct actuellement disponibles :
- App Router Playground
- Clone de Hacker News
- App Router minimal
- Pages Router minimal
Nous avons également un exemple en direct de Cloudflare Agents fonctionnant dans une application Next.js, sans avoir besoin de solutions de contournement telles que getPlatformProxy, car l'ensemble de l'application fonctionne désormais dans workerd, pendant les phases de développement et de déploiement. Cela signifie que vous pouvez utiliser Durable Objects, les liaisons IA et tous les autres services spécifiques à Cloudflare sans compromis. Jetez un œil ici.
Les frameworks sont un sport d'équipe
La cible de déploiement actuelle est Cloudflare Workers, mais ce n'est qu'une petite partie du tableau. Environ 95 % de vinext est du pur Vite. Le routage, les shims de module, le pipeline SSR, l'intégration RSC : rien de tout cela n'est spécifique à Cloudflare.
Cloudflare cherche à collaborer avec d'autres fournisseurs d'hébergement afin qu'ils adoptent cette chaîne d'outils pour leurs clients (l'effort est minime : nous avons obtenu une preuve de concept fonctionnant sur Vercel en moins de 30 minutes !). Il s'agit d'un projet open source, et pour assurer son succès à long terme, nous pensons qu'il est important de travailler avec des partenaires de l'ensemble de l'écosystème afin de garantir un investissement continu. Les PR provenant d'autres plateformes sont les bienvenues. Si vous souhaitez ajouter une cible de déploiement, ouvrez un ticket ou contactez-nous.
Statut : expérimental
Nous tenons à être clairs : vinext est expérimental. Il n'a même pas une semaine d'existence et n'a pas encore été testé en conditions réelles avec un trafic significatif à grande échelle. Si vous l'évaluez pour une application de production, procédez avec la prudence qui s'impose.
Cela dit, la suite de tests est exhaustive : plus de 1 700 tests Vitest et 380 tests Playwright E2E, y compris des tests directement portés depuis la suite de tests Next.js et la suite de conformité Cloudflare d'OpenNext. Nous l'avons vérifié par rapport au Next.js App Router Playground. La couverture atteint 94 % de la surface API Next.js 16. Les premiers résultats obtenus auprès de clients réels sont encourageants. Nous avons travaillé avec National Design Studio, une équipe qui vise à moderniser toutes les interfaces gouvernementales, sur l'un de leurs sites bêta, CIO.gov. Ils utilisent déjà vinext en production, avec des améliorations significatives en termes de temps de compilation et de taille des paquets.
Le fichier README est honnête sur ce qui n'est pas pris en charge et ne le sera pas, ainsi que sur les limitations connues. Nous préférons être francs plutôt que de faire des promesses excessives.
Qu'en est-il du pré-rendu ?
vinext prend déjà en charge la régénération statique incrémentielle (ISR) dès son installation. Après la première requête vers une page, celle-ci est mise en cache et revalidée en arrière-plan, tout comme Next.js. Cette partie fonctionne aujourd'hui.
vinext ne prend pas encore en charge le pré-rendu statique au moment de la compilation. Dans Next.js, les pages sans données dynamiques sont rendues lors de la compilation suivante et servies sous forme de HTML statique. Si vous avez des routes dynamiques, vous utilisez generateStaticParams() pour énumérer les pages à construire à l'avance. vinext ne le fait pas... pour l'instant.
Il s'agit d'une décision de conception intentionnelle pour le lancement. Cela fait partie de la feuille de route, mais si votre site est composé à 100 % de HTML pré-construit avec du contenu statique, vous ne verrez probablement pas beaucoup d'avantages à utiliser vinext aujourd'hui. Cela dit, si un ingénieur peut dépenser 1 100 dollars en jetons et reconstruire Next.js, vous pouvez probablement dépenser 10 dollars et migrer vers un framework basé sur Vite conçu spécifiquement pour le contenu statique, comme Astro (qui se déploie également sur Cloudflare Workers).
Pour les sites qui ne sont pas purement statiques, cependant, nous pensons pouvoir faire mieux que de tout pré-rendre au moment de la compilation.
Présentation du pré-rendu tenant compte du trafic
Next.js pré-rend chaque page répertoriée dans generateStaticParams() pendant la compilation. Un site comportant 10 000 pages de produits signifie 10 000 rendus au moment de la compilation, même si 99 % de ces pages ne recevront peut-être jamais de requête. Les compilations évoluent de manière linéaire avec le nombre de pages. C'est pourquoi les grands sites Next.js finissent par nécessiter 30 minutes de compilation.
Nous avons donc mis au point le pré-rendu tenant compte du trafic (TPR). Il est encore à l'état expérimental, mais nous prévoyons de le rendre par défaut une fois que nous aurons effectué davantage de tests en conditions réelles.
L'idée est simple. Cloudflare est déjà le proxy inverse de votre site. Nous disposons de vos données de trafic. Nous savons quelles pages sont réellement visitées. Ainsi, au lieu de tout pré-rendre ou de ne rien pré-rendre, vinext interroge les analyses de zone de Cloudflare au moment du déploiement et ne pré-rend que les pages qui comptent.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
Pour un site comportant 100 000 pages de produits, la loi de puissance signifie que 90 % du trafic est généralement dirigé vers 50 à 200 pages. Celles-ci sont pré-rendues en quelques secondes. Tout le reste revient au SSR à la demande et est mis en cache via ISR après la première requête. Chaque nouveau déploiement actualise l'ensemble en fonction des modèles de trafic actuels. Les pages qui deviennent virales sont automatiquement sélectionnées. Tout cela fonctionne sans generateStaticParams() et sans coupler votre build à votre base de données de production.
Relever le défi Next.js, mais cette fois-ci avec l'IA
Un projet comme celui-ci prendrait normalement des mois, voire des années, à une équipe d'ingénieurs. Plusieurs équipes de différentes entreprises s'y sont essayées, mais l'ampleur de la tâche est tout simplement énorme. Nous avons essayé une fois chez Cloudflare ! Deux routeurs, plus de 33 modules shims, des pipelines de rendu serveur, du streaming RSC, du routage de système de fichiers, du middleware, de la mise en cache, de l'exportation statique. Il y a une raison pour laquelle personne n'y est parvenu.
Cette fois-ci, nous l'avons fait en moins d'une semaine. Un ingénieur (techniquement responsable de l'ingénierie) dirigeait l'IA.
Le premier commit a été effectué le 13 février. À la fin de la même soirée, le routeur Pages et le routeur App fonctionnaient tous deux avec un SSR de base, ainsi que des middlewares, des actions serveur et du streaming. Le lendemain après-midi, App Router Playground rendait 10 des 11 routes. Au troisième jour, vinext deploy expédiait des applications vers Cloudflare Workers avec une hydratation client complète. Le reste de la semaine a été consacré au renforcement : correction des cas limites, extension de la suite de tests, portée de la couverture API à 94 %.
Qu'est-ce qui a changé par rapport aux tentatives précédentes ? L'IA s'est améliorée. Beaucoup améliorée.
Pourquoi ce problème est-il fait pour l'IA ?
Tous les projets ne se déroulent pas de cette manière. Celui-ci l'a fait parce que plusieurs éléments se sont alignés au bon moment.
Next.js est bien spécifié. Il dispose d'une documentation complète, d'une base d'utilisateurs importante et de nombreuses années de réponses et de tutoriels Stack Overflow. L'interface API est présente dans toutes les données d'entraînement. Lorsque vous demandez à Claude d'implémenter getServerSideProps ou d'expliquer le fonctionnement de useRouter, il ne hallucine pas. Il sait comment fonctionne Next.
Next.js dispose d'une suite de tests élaborée. Le dépôt Next.js contient des milliers de tests E2E couvrant toutes les fonctionnalités et tous les cas limites. Nous avons porté les tests directement à partir de leur suite (vous pouvez voir l'attribution dans le code). Cela nous a donné une spécification que nous avons pu vérifier mécaniquement.
Vite est une excellente base. Vite gère les aspects complexes des outils front-end : HMR rapide, ESM natif, API de plugin propre, regroupement de production. Nous n'avons pas eu à créer de regroupeur. Nous avons simplement dû lui apprendre à parler Next.js. @vitejs/plugin-rsc en est encore à ses débuts, mais il nous a permis de bénéficier de la prise en charge des composants serveur React sans avoir à créer une implémentation RSC à partir de zéro.
Les modèles ont rattrapé leur retard. Nous pensons que cela n'aurait pas été possible il y a encore quelques mois. Les modèles précédents ne pouvaient pas maintenir la cohérence d'une base de code de cette taille. Les nouveaux modèles peuvent prendre en compte l'architecture complète dans son contexte, raisonner sur la manière dont les modules interagissent et produire suffisamment souvent du code correct pour maintenir la dynamique. Parfois, je l'ai vu entrer dans les internes de Next, Vite et React pour détecter un bug. Les modèles de pointe sont impressionnants et semblent s'améliorer sans cesse.
Tous ces éléments devaient être réunis en même temps. Une API cible bien documentée, une suite de tests complète, un outil de construction solide et un modèle capable de gérer la complexité. Si l'un de ces éléments venait à manquer, cela ne fonctionnerait pas aussi bien.
Comment nous l'avons réellement construit
Presque chaque ligne de code dans vinext a été écrite par l'IA. Mais voici ce qui importe davantage : chaque ligne passe les mêmes contrôles de qualité que ceux que vous attendriez d'un code écrit par un humain. Le projet compte plus de 1 700 tests Vitest, 380 tests Playwright E2E, une vérification complète des types TypeScript via tsgo et un linting via oxlint. L'intégration continue exécute tout cela à chaque pull request. Il est essentiel de mettre en place un ensemble de garde-fous efficaces pour rendre l'IA productive dans une base de code.
Le processus a commencé par un plan. J'ai passé quelques heures à échanger avec Claude dans OpenCode pour définir l'architecture : quoi construire, dans quel ordre, quelles abstractions utiliser. Ce plan est devenu notre ligne directrice. À partir de là, le flux de travail était simple :
1. Définir une tâche (« implémenter le shim suivant/de navigation avec usePathname, useSearchParams, useRouter »).
2. Laisser l'IA écrire l'implémentation et les tests.
3. Exécuter la suite de tests.
4. Si les tests sont réussis, fusionner. Sinon, donner à l'IA la sortie d'erreur et la laisser itérer.
5. Répéter.
Nous avons également connecté des agents IA pour la révision du code. Lorsqu'une PR était ouverte, un agent la révisait. Lorsque les commentaires de révision revenaient, un autre agent les traitait. La boucle de rétroaction était en grande partie automatisée.
Cela ne fonctionnait pas parfaitement à chaque fois. Certaines PR étaient tout simplement erronées. L'IA implémentait avec assurance quelque chose qui semblait correct, mais qui ne correspondait pas au comportement réel de Next.js. Je devais régulièrement corriger le tir. Les décisions architecturales, la hiérarchisation des priorités, savoir quand l'IA se dirigeait vers une impasse : tout cela me revenait. Lorsque vous donnez à l'IA une bonne direction, un bon contexte et de bonnes garde-fous, elle peut être très productive. Mais l'humain doit toujours tenir les rênes.
Pour les tests au niveau du navigateur, j'ai utilisé agent-browser pour vérifier le rendu réel, la navigation côté client et le comportement d'hydratation. Les tests unitaires passent à côté de nombreux problèmes subtils liés au navigateur. Cela les a permis de les détecter.
Au cours du projet, nous avons effectué plus de 800 sessions dans OpenCode. Coût total : environ 1 100 dollars en jetons API Claude.
Ce que cela signifie pour les logiciels
Pourquoi avons-nous autant de couches dans la pile ? Ce projet m'a obligé à réfléchir profondément à cette question. Et à considérer l'impact de l'IA sur la réponse.
La plupart des abstractions dans les logiciels existent parce que les humains ont besoin d'aide. Nous ne pouvions pas garder tout le système en tête, alors nous avons construit des couches pour gérer la complexité à notre place. Chaque couche facilitait le travail de la personne suivante. C'est ainsi que l'on se retrouve avec des frameworks superposés, des bibliothèques wrapper et des milliers de lignes de code de liaison.
L'IA n'a pas cette limitation. Elle peut appréhender l'ensemble du système dans son contexte et se contenter d'écrire le code. Elle n'a pas besoin d'un framework intermédiaire pour rester organisée. Elle a juste besoin d'une spécification et d'une base sur laquelle s'appuyer.
On ne sait pas encore clairement quelles abstractions sont vraiment fondamentales et lesquelles ne sont que des béquilles pour la cognition humaine. Cette ligne va beaucoup évoluer au cours des prochaines années. Mais vinext est un point de données. Nous avons pris un contrat API, un outil de construction et un modèle d'IA, et l'IA a écrit tout ce qui se trouvait entre les deux. Aucun framework intermédiaire n'était nécessaire. Nous pensons que ce modèle se répétera dans de nombreux logiciels. Les couches que nous avons construites au fil des ans ne survivront pas toutes.
Remerciements
Merci à l'équipe Vite. Vite est la base sur laquelle repose tout cela. @vitejs/plugin-rsc en est encore à ses débuts, mais il m'a apporté le support RSC sans que j'aie à le construire à partir de zéro, ce qui aurait été rédhibitoire. Les responsables de Vite ont été réactifs et serviables lorsque j'ai poussé le plugin dans un domaine où il n'avait jamais été testé auparavant.
Nous tenons également à remercier l'équipe Next.js. Elle a passé des années à construire un framework qui a relevé la barre en matière de développement React. Le fait que leur API soit si bien documentée et leur suite de tests si complète a largement contribué à rendre ce projet possible. vinext n'existerait pas sans la norme qu'ils ont établie.
Essayez-le
vinext comprend une compétence d'agent qui gère la migration pour vous. Elle fonctionne avec Claude Code, OpenCode, Cursor, Codex et des dizaines d'autres outils de codage IA. Installez-la, ouvrez votre projet Next.js et demandez à l'IA d'effectuer la migration :
Code : Sélectionner tout - Visualiser dans une fenêtre à part npx skills add cloudflare/vinext
Ouvrez ensuite votre projet Next.js dans n'importe quel outil pris en charge et dites :
Code : Sélectionner tout - Visualiser dans une fenêtre à part migrate this project to vinext
La compétence gère la vérification de la compatibilité, l'installation des dépendances, la génération de la configuration et le démarrage du serveur de développement. Elle sait ce que vinext prend en charge et signalera tout ce qui nécessite une attention manuelle.
Ou si vous préférez le faire à la main :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
Le code source se trouve sur github.com/cloudflare/vinext. Les problèmes, les PR et les commentaires sont les bienvenus.
Sources : How we rebuilt Next.js with AI in one week
Et vous ?
Pensez-vous que cet outil est crédible ou pertinent ?
Voir aussi :
Répondre avec citation
Partager