Vue 3.5 est sorti en septembre 2024 avec ce qu'Evan You a appelé une version mineure — et un système de réactivité refactoré qui livre 56% d'usage mémoire en moins et des opérations jusqu'à 10× plus rapides sur les grands tableaux profondément réactifs. La réponse de la communauté des développeurs était approximativement : "Cela ne ressemble pas à une version mineure."
Les chiffres confirment cet instinct. Le système de réactivité refactoré de Vue 3.5 livre des gains réels et mesurables.
Ce qui a rendu Vue 3.5 digne de mise à niveau
Un système de réactivité réécrit
Le changement central est une refonte interne complète de comment Vue suit l'état réactif. Le but était d'éliminer les valeurs computed stagnantes et les memory leaks qui pouvaient s'accumuler pendant le rendu côté serveur.
Le résultat était un gain net partout : usage mémoire réduit, meilleure performance sur les structures réactives profondément imbriquées, et résolution de problèmes durables avec les "computed suspendus" en contexte SSR. Critiquement, la refonte n'a eu aucun changement de comportement — tout ce qui marchait avant fonctionne toujours.
Destruction de props réactive, maintenant stabilisée
L'une des fonctionnalités les plus demandées du processus RFC de l'API Composition a atterri en 3.5 avec sa stabilisation. Précédemment, destructurer les props dans <script setup> cassait la réactivité.
// Avant 3.5 — la seule façon fiable
const props = withDefaults(
defineProps<{
count?: number
message?: string
}>(),
{ count: 0, message: 'hello' }
)
// Après 3.5 — la destruction native fonctionne réactivement
const { count = 0, message = 'hello' } = defineProps<{
count?: number
message?: string
}>()
Hydratation paresseuse pour SSR
Le rendu côté serveur a été un point de douleur connu. Vue 3.5 introduit une API de bas niveau pour contrôler la stratégie d'hydratation :
import { defineAsyncComponent, hydrateOnVisible } from 'vue'
const AsyncComp = defineAsyncComponent({
loader: () => import('./HeavyChart.vue'),
hydrate: hydrateOnVisible()
})
Les composants peuvent maintenant être différés jusqu'à ce qu'ils apparaissent dans le viewport.
useId() : IDs stables entre serveur et client
useId() résout le problème des IDs de formulaire qui diffèrent entre le serveur et le client :
<script setup>
import { useId } from 'vue'
const id = useId()
</script>
<template>
<form>
<label :for="id">Email:</label>
<input :id="id" type="email" />
</form>
</template>
La même composant rendu sur le serveur ou le client produit le même ID.
data-allow-mismatch
data-allow-mismatch permet de supprimer explicitement les avertissements pour les divergences connues entre serveur et client :
<span data-allow-mismatch>{{ user.localBirthday }}</span>
useTemplateRef()
useTemplateRef() résout le problème des refs de template qui nécessitaient des noms statiques :
<script setup>
import { useTemplateRef } from 'vue'
const inputRef = useTemplateRef('input')
</script>
<template>
<input :ref="dynamicRefName" />
</template>
TypeScript : silencieusement en amélioration
Vue 3.5 a également amélioré l'inférence TypeScript pour les grands codebases.
Vue 3.6 : Ce qui vient
Le headline feature de Vue 3.6 est Vapor Mode.
Vapor Mode est une stratégie de compilation qui élimine le DOM virtuel entièrement. Au lieu de diffing un arbre DOM virtuel à chaque mise à jour, il compile les templates Vue en opérations DOM directes — la même stratégie que Solid.js utilise pour atteindre ses performances de benchmark.
La réclamation intéressante d'Evan You : Vapor Mode permet à Vue d'atteindre le niveau de performance de Solid.js tout en gardant l'API Vue exacte. Vous ne réécrivez pas vos composants. Vous opts des sous-arbres individuels en mode Vapor, et le compilateur s'occupe du reste.
L'objectif de performance : 100 000 montages de composants en 100 ms. Pour contexte, le DOM virtuel de Vue 3 gère environ 10 000-20 000 montages de composants dans le même laps de temps.
Vapor Mode est actuellement en bêta. L'intégration dans le dépôt principal Vue est en cours. Un release stable est attendu en 2026.
Également remarquable dans le pipeline 3.6 :
- Alien Signals : Une réduction d'usage mémoire de 14% supplémentaire par rapport à 3.5
- Vue base bundle sous 10KB : L'empreinte runtime diminue significativement
Pourquoi cela importe
L'évolution de Vue a suivi un patron intéressant. Chaque version a mené le framework plus loin de "outil simple pour petits projets" et plus près de "infrastructure sérieuse pour grandes applications" — sans abandonner l'expérience développeur qui a rendu Vue attrayant.
Vue 3.5 est une étude de cas de cet équilibre. Les améliorations mémoire et performance sont du type qui rend les systèmes de production mesurablement meilleurs — pas cosmétiques, pas théoriques, mais réels.
La trajectoire vers 3.6 et Vapor Mode suggère que Vue n'est pas satisfait de se contenter de correspondre à la concurrence. Il veut fixer la barre de performance. C'est une ambition intéressante pour un framework qui s'est toujours défini par l'accessibilité et l'ergonomie plutôt que la vitesse brute.
Que Vapor Mode tienne sa promesse — et qu'il puisse maintenir la compatibilité avec l'écosystème existant pendant la transition — déterminera si Vue 3.6 est rappelé comme un point de pivot ou juste une autre release. Les premiers signaux sont prometteurs.
