Vue 3.6 beta est arrivé, et il marque un moment charnière dans l'évolution du framework. Les réalisations principales : le Vapor Mode a atteint la parité de fonctionnalités avec le système virtual DOM, et le package de réactivité a subi une refonte fondamentale en utilisant la bibliothèque alien-signals. Ensemble, ces changements positionnent Vue 3.6 comme l'une des releases les plus significatives de l'histoire du framework.
Vapor Mode : Fonctionnalités Complètes
Le Vapor Mode est la réponse de Vue à une question que le monde frontend se pose depuis des années : et si on pouvait avoir l'ergonomie et le modèle de composant de Vue avec l'efficacité runtime des frameworks compilés, à manipulation DOM directe comme Solid ou Svelte ?
L'idée centrale est simple. Dans le modèle de compilation Vue 3 actuel, les templates sont compilés en fonctions de rendu qui produisent des noeuds virtual DOM. Quand l'état change, Vue crée un nouvel arbre virtual DOM et le diff contre l'arbre précédent pour déterminer l'ensemble minimal de mutations DOM réelles nécessaires. Ce diff vdom est suffisamment rapide pour la plupart des applications, mais il n'est pas gratuit — la création d'objets vnode et l'algorithme de diff consomment tous les deux du CPU et de la mémoire.
Le Vapor Mode remplace entièrement ceci. Au lieu de compiler les templates en fonctions de rendu, il les compile en JavaScript qui appelle directement les API DOM. Une boucle v-for devient une boucle qui appelle document.createElement et appendChild directement. Un v-if devient une condition qui insère ou supprime des noeuds. Le résultat est un bundle sans runtime virtual DOM et moins d'allocations au runtime.
L'équipe Vue a d'abord décrit le Vapor Mode fin 2024 et itère dessus depuis 2025. Avec la beta 3.6, l'équipe a atteint une étape : le Vapor Mode supporte maintenant toutes les fonctionnalités stables disponibles en mode virtual DOM. Cela signifie que les composants utilisant v-if, v-for, v-show, v-model, les slots, Suspense et l'API Composition devraient fonctionner en Vapor Mode sans modification.
L'exception est Suspense en mode Vapor-only — pas encore supporté, bien que les composants Vapor puissent être rendus à l'intérieur d'un边界 Suspense basé sur vdom.
Ce qui Change en Pratique
Pour les développeurs, la transition est conçue pour être largement invisible. Vous écrivez les composants Vue de la même manière. Sous le capot, le compilateur choisit le chemin Vapor. Le bundle qui atteint le navigateur est plus petit car le runtime vdom a disparu, et le comportement runtime est plus rapide car les mises à jour DOM contournent l'étape de diffing.
Pour les auteurs de bibliothèques et les développeurs utilisant les API de bas niveau de Vue — h(), createVNode, la manipulation directe de l'instance de composant — des ajustements peuvent être nécessaires. Le Vapor Mode fonctionne au niveau de la compilation des templates, donc le code qui passe par le pipeline des fonctions de rendu continue de fonctionner normalement.
Refonte @vue/reactivity avec alien-signals
Le système de réactivité, le moteur qui propulse ref(), reactive(), computed() et watch() de Vue, a été refactoré pour utiliser alien-signals. C'est un changement fondamental plutôt qu'un changement d'API de surface — ref() et reactive() fonctionnent toujours de la même manière.
La motivation est la performance. L'implémentation de réactivité précédente, bien qu'ingénieuse, avait des frais généraux liés à la façon dont elle suivait les dépendances et planifiait les mises à jour. alien-signals est conçu avec un objectif plus étroit : exécuter les calculs réactifs aussi rapidement que possible avec un minimum d'allocation mémoire. L'équipe Vue a évalué plusieurs implémentations de signaux et a choisi alien-signals pour ses performances de benchmark et son alignement avec le modèle de planification des mises à jour de Vue.
Cette refonte affecte le package @vue/reactivity directement, qui est également publié séparément sur npm et utilisé dans des projets en dehors de Vue — incluant certaines intégrations Solid.js et d'autres frameworks qui ont adopté les primitives de réactivité de Vue.
Améliorations de l'Hydration
La beta 3.6 ships également un grand lot de correctifs liés à l'hydration — plus de 30 commits dans la release beta.10 seule. L'hydration SSR de Vue 3, qui fait correspondre le HTML rendu serveur contre l'arbre de composants côté client, a été renforcée sur les cas limites impliquant :
- Les boundary d'hydration multi-racines et les composants asynchrones
- Les cibles Teleport avec des cibles manquantes ou changeantes
- L'hydration du contenu slot avec du contenu de fallback
- Les composants dynamiques rendus entre les boundaries SSR et client
Ce sont le genre de correctifs qui ne ressortent que dans des applications réelles complexes, et leur présence indique que Vue 3.6 est renforcé pour des cas d'usage en production à grande échelle.
Vers la Release Stable
Vue 3.6 entrant en beta signifie que l'ensemble des fonctionnalités est verrouillé et que l'équipe se concentre sur la stabilisation et les correctifs de compatibilité. Sans régressions majeures découvertes pendant la période beta, la release stable devrait suivre dans quelques semaines. L'équipe Vue itère rapidement — beta.1 a été publiée le 30 mars et beta.10 a été publiée le 13 avril, indiquant un développement actif.
Pour les équipes projet utilisant Vue 3, c'est maintenant un bon moment pour tester la beta 3.6 contre votre application, particulièrement si vous utilisez des patterns de code compatibles Vapor Mode. La politique de l'équipe Vue est d'éviter les changements cassants dans les releases mineures, mais les changements internes de réactivité dans la 3.6 signifient que les cas limites dans l'utilisation personnalisée de la réactivité valent la peine d'être testés.
