- L’ancienne architecture double esbuild + Rollup est unifiée autour de Rolldown, un bundler basé sur Rust, ce qui permet d’atteindre des performances de build jusqu’à 10 à 30 fois supérieures
- Un nouveau registre de plugins est publié, permettant de rechercher et gérer les plugins Vite, Rolldown et Rollup
- Des fonctionnalités de confort pour le développement ont été ajoutées, comme Vite Devtools, la résolution des chemins TypeScript, le Wasm SSR et le console forwarding
- Cette version constitue le plus grand changement structurel de l’écosystème Vite à ce jour et pose les bases de l’évolution future vers une toolchain unifiée
Vite 8 basé sur Rolldown
- Vite 8 unifie l’ancienne architecture à double bundler, esbuild (pour le développement) et Rollup (pour la production), en un bundler unique : Rolldown
- Rolldown est un bundler haute performance écrit en Rust qui prend en charge la même API de plugins que Rollup
- La plupart des plugins Vite existants fonctionnent sans modification particulière
- Côté performances, il est 10 à 30 fois plus rapide que Rollup et prend en charge des fonctions avancées comme le cache au niveau module, le découpage flexible des chunks et le Module Federation
Processus d’adoption de Rolldown
- Au départ, un aperçu technologique a été proposé via le package
rolldown-vite afin de recueillir les retours de la communauté
- Des tests sur divers codebases réels ont permis de résoudre les problèmes de compatibilité
- Une infrastructure de tests CI dédiée a été mise en place pour les principaux plugins et frameworks
- En décembre 2025, la bêta de Vite 8 a été publiée avec une intégration complète de Rolldown
- Pendant la période bêta, Rolldown a progressé jusqu’au stade de Release Candidate tout en se stabilisant
Exemples concrets de gains de performance
- Plusieurs entreprises ont signalé des réductions du temps de build
- Linear : 46 s → 6 s
- Ramp : réduction de 57 %
- Mercedes-Benz.io : réduction jusqu’à 38 %
- Beehiiv : réduction de 64 %
- Plus le projet est volumineux, plus l’effet est marqué, et des améliorations continues de Rolldown sont annoncées
Toolchain unifiée et stack technique
- Vite 8 évolue vers une toolchain end-to-end dans laquelle Vite (outil de build), Rolldown (bundler) et Oxc (compilateur) collaborent étroitement
- Cohérence assurée sur l’ensemble du processus de parsing, transformation et optimisation
- Possibilité d’optimiser le tree shaking grâce à l’analyse sémantique d’Oxc
- Une structure permettant d’adopter rapidement les nouvelles spécifications JavaScript
Fonctionnalités supplémentaires
- Vite Devtools : permet d’analyser visuellement l’état du projet depuis le serveur de développement
- Prise en charge intégrée de la résolution automatique des chemins TypeScript (alias) et de emitDecoratorMetadata
- Wasm SSR : prise en charge des imports
.wasm?init dans les environnements de rendu côté serveur
- Browser console forwarding : transmet les erreurs du navigateur vers le terminal pour améliorer l’efficacité du débogage
- @vitejs/plugin-react v6 : suppression de Babel, adoption de React Refresh basé sur Oxc, réduction de la taille à l’installation
Orientations futures du développement
- Full Bundle Mode (expérimental) : effectue aussi le bundling pendant le développement, avec à la clé un démarrage serveur 3 fois plus rapide, un rechargement 40 % plus rapide et 10 fois moins de requêtes réseau
- Transmission de Raw AST et transformations Native MagicString pour réduire l’écart de performance entre Rust et JavaScript
- Une collaboration au sein de l’écosystème est en cours pour stabiliser l’Environment API
Évolution de la taille à l’installation
- Vite 8 augmente d’environ 15 Mo par rapport à Vite 7
- lightningcss (environ 10 Mo) : fournit une fonction de minification CSS par défaut
- Binaire Rolldown (environ 5 Mo) : hausse de taille en échange d’une optimisation de la vitesse
- Les prochaines versions continueront d’optimiser la taille
Guide de migration
- La plupart des projets peuvent être mis à niveau sans modification de configuration
- Les paramètres existants
esbuild et rollupOptions sont convertis automatiquement
- Pour les grands projets, une migration en deux étapes est recommandée
- Passer de Vite 7 à
rolldown-vite, puis mettre à niveau vers Vite 8
- Les procédures détaillées sont disponibles dans le Migration Guide officiel et le Changelog
Remerciements à Rollup et esbuild
- Rollup a fourni la base de l’écosystème de plugins de Vite, et Rolldown en reprend l’API
- esbuild a été une technologie clé pour offrir une expérience de développement rapide et a contribué à l’essor des outils basés sur Rust et Go
- Les contributions de ces deux projets sont profondément inscrites dans l’ADN de Vite
Communauté et collaboration
- Le développement de Vite 8 a été mené à bien grâce à la collaboration entre sapphi-red et l’équipe Vite, l’équipe Rolldown et de nombreux contributeurs de la communauté
- VoidZero, Bolt et NuxtLabs ont participé comme partenaires majeurs
5 commentaires
Avis sur Hacker News
Cela fait réfléchir à quel point l’industrie a gaspillé de ressources de calcul avec des outils inefficaces, utilisés sans remise en question sous prétexte que « les builds sont forcément longs »
On organisait nos plannings autour de ces builds lents, on en faisait des blagues sur les pauses, et on allait même jusqu’à construire des couches de cache
Bravo aux mainteneurs de Vite
La plupart des logiciels en production sont des dizaines de fois plus lents que nécessaire
Les apps Electron qui consomment plusieurs Go de RAM tout en étant plus poussives que des logiciels d’il y a 40 ans en sont la preuve
Il y a 14 ans, j’ai pris conscience du temps perdu à attendre les builds, avec un problème particulièrement marqué dans l’écosystème Java
Sur un projet Ruby, les tests d’intégration prenaient autrefois 10 minutes parce qu’ils recréaient la base de données à chaque fois
Kotlin/Spring Boot compile aussi lentement, et le compilateur Rust n’est pas spécialement rapide non plus
Mais les tests, on peut les maîtriser. Les tests unitaires devraient finir en quelques millisecondes, et les tests d’intégration peuvent être énormément améliorés via la parallélisation et l’aléatoirisation des données
Sur mon MacBook Pro, j’exécute en moins de 40 secondes plusieurs centaines de tests d’intégration Spring avec Redis, une base de données et Elasticsearch
Une fois cette configuration en place, on retrouve une boucle de feedback rapide et le plaisir de développer revient
Ma contribution à Vite 8 concernait la prise en charge de Wasm SSR
J’ai étendu les imports
.wasm?initpour qu’ils fonctionnent aussi en environnement SSRLe processus a été lent, mais j’ai été impressionné par l’aide minutieuse de l’équipe et par le fait qu’ils aient même ajouté de la documentation
On sent que l’équipe Vite ne se contente pas de créer des outils, elle prend aussi très au sérieux la formation des contributeurs et la collaboration
C’est vraiment agréable de voir ce type de gain de performance à l’époque d’Electron
Un projet que je maintiens depuis longtemps (il date d’avant React hooks) prenait autrefois 2 minutes à builder avec react-scripts basé sur Webpack
Aujourd’hui, avec Vite 8, c’est plié en 1 seconde. C’est un bon exemple de l’ampleur des ressources qu’on a gaspillées
Le navigateur devait pouvoir l’exécuter tel quel, et TypeScript a aussi été conçu pour être exécutable immédiatement après simple suppression des types
L’existence même de ces outils de build ressemble à une mauvaise direction
Après l’adoption de Vite 8, le temps de build de notre équipe est passé de 4 minutes à 30 secondes
C’était quasiment un remplacement drop-in, donc merci à l’équipe Vite
On l’utilisait déjà avant son intégration dans Vite, et c’est vraiment excellent
On dit souvent que c’est plus rapide que Next, donc à ce niveau-là ça doit être énorme
Merci à l’équipe Vite d’avoir créé une solution de bundling open source qui n’est pas enfermée dans un framework précis
(petite toux en mentionnant Turbopack)
Excellente nouvelle. Mais Next.js ne semble pas pouvoir profiter de ce genre de progrès communautaires
À cause du syndrome NIH chez Vercel
L’alpha de Turbopack a commencé avec Next 13, et ce n’est qu’avec Next 16 qu’il devient la valeur par défaut
En 2022, les benchmarks comparatifs avec Vite avaient aussi été biaisés
Problèmes de cache, performances lentes, faille de sécurité RSC, App Router confus, hébergement peu pratique hors Vercel, etc.
Choisir Next.js, c’est prendre un risque
Liens associés : discussion comparative, historique du cache, analyse des performances, CVE de sécurité, OpenNext
Même dans la documentation officielle, le fait que Next soit présenté comme le choix par défaut me paraît étrange
Je ne vois pas vraiment pourquoi utiliser React en mode non-SPA
Par exemple : Sitecore Cloud, Sanity, Contentful, etc.
Avec Vite+, Void Cloud, Void Framework, etc.
on dirait que l’affrontement entre Vercel et Void va commencer
La démo PRC(Server Functions) est particulièrement intéressante — elle montre une sécurité de type de bout en bout depuis la base de données jusqu’à l’UI
Nous étudions une architecture RPC avec Telefunc (alternative à tRPC) et espérons collaborer avec l’équipe de Void
Liens associés : vidéo de démo PRC, Telefunc, Vike
Void Cloud semble construit sur Cloudflare Workers, mais il y a encore peu d’informations pour l’instant
Malgré cela, le fait que Vite+ soit publié en open source sous licence MIT est très encourageant
Si Bun se concentre trop sur le soutien d’Anthropic et néglige l’OSS, il pourrait perdre son avantage concurrentiel
Référence : Void Cloud
Même si l’écosystème JS est chaotique, Vite offre constamment une excellente DX et une qualité de production remarquable
Avec le bundler Rolldown intégré, il va devenir une base encore plus rapide et plus flexible
En tant que développeur web depuis 1998, j’en suis vraiment fan
Comme j’accorde de l’importance à la maintenance à long terme, j’utilise esbuild directement
Je déteste devoir corriger à chaque fois qu’un wrapper comme Vite casse à cause de changements internes
Je gérais la validation des types avec Zod, et je ne faisais de génération de code que pour les types Postgres
La prochaine fois, j’utiliserais probablement Kysely
La prise en charge native de tsconfig paths est une très bonne amélioration de QoL
Ça réduit les doublons dans la configuration
Selon le projet, cela peut être plus simple
En réalité, JS était à l’origine un langage qui n’avait pas besoin de processus de build ; le navigateur devait pouvoir l’exécuter tel quel, et TypeScript aussi a été conçu pour pouvoir être exécuté directement une fois les types supprimés. L’existence même de ce genre d’outils de build me semble aller dans la mauvaise direction -> comment pourrait-on normaliser ça ?
Comme ce qui ne tournait que dans le navigateur peut désormais s’exécuter directement sur le serveur, j’ai l’impression que c’était une évolution inévitable.
Je pense que c’est un phénomène naturel lié à la sophistication croissante des applications web.
Il faudrait peut-être abandonner le JS des navigateurs comme on a abandonné Flash ? Pourtant, rien n'indique que le JS soit près de disparaître.