Stacks

Vue et Svelte sont presque toujours présentés à travers une seule opposition : Svelte compile, Vue utilise un virtual DOM. Le raccourci est commode et il est trompeur, car les deux frameworks reposent fortement sur un compilateur. Ce qui diffère, c'est ce que produit chaque compilateur et ce qu'il reste à faire au runtime.

Svelte se décrit comme un framework qui utilise un compilateur pour transformer des composants déclaratifs écrits en HTML, CSS et JavaScript en JavaScript épuré et fortement optimisé. L'étape de build est le centre de la conception : le travail consistant à déterminer ce qui doit changer est repoussé aussi loin que possible dans la compilation.

Vue compile aussi, et le dit explicitement. Sa documentation indique que le framework contrôle à la fois le compilateur et le runtime, ce qui lui permet de mettre en oeuvre des optimisations à la compilation que seul un renderer fortement couplé peut exploiter. Vue appelle cette approche hybride le Compiler-Informed Virtual DOM. Le virtual DOM est toujours là, mais le compilateur indique au runtime où il n'a pas besoin de regarder.

Trois de ces optimisations méritent d'être connues par leur nom, car elles expliquent pourquoi opposer 'virtual DOM' à 'pas de virtual DOM' passe à côté du sujet. Le static hoisting : le renderer crée les vnodes des parties immuables lors du rendu initial, les met en cache, et réutilise les mêmes vnodes à chaque re-rendu suivant. Rien n'est re-diffé qui ne peut pas changer.

Les patch flags : Vue encode le type de mise à jour directement à la création du vnode, de sorte que le runtime utilise des opérations bitwise pour décider s'il doit faire un travail donné. Il ne pose pas de questions larges sur l'arbre, il vérifie un flag.

Le tree flattening : chaque bloc suit les noeuds descendants porteurs de patch flags, et pas seulement les enfants directs. Quand le composant se re-rend, le runtime parcourt l'arbre aplati plutôt que l'arbre complet, ce qui, selon la documentation, réduit fortement le nombre de noeuds parcourus lors de la réconciliation.

Lues ensemble, ces trois optimisations signifient que le virtual DOM de Vue n'est pas le diff naïf que suggère la comparaison raccourcie. Le compilateur a déjà rétréci l'espace de recherche avant que le runtime ne commence à chercher. C'est une conception différente de celle de Svelte, mais ce n'est pas l'absence de compilateur.

Alors où se situe le vrai choix ? Moins dans la théorie brute du rendu que dans ce qui l'entoure. Vue est livré avec davantage de décisions déjà prises, avec des bibliothèques officielles de routing et de gestion d'état et une structure recommandée, ce qui tend à raccourcir le chemin vers la productivité dans les petites équipes. La conception de Svelte met davantage l'accent sur une étape de build qui produit une sortie minimale, ce qui séduit quand la taille du payload et le travail au démarrage sont les contraintes que l'on ressent vraiment.

La maturité de l'écosystème est l'autre facteur honnête. Vue est déployé largement depuis plus longtemps, et cela se voit dans le volume de bibliothèques, d'outillage et de profils disponibles au recrutement. L'écosystème de Svelte est plus restreint, ce qui compte davantage sur une grosse application appelée à durer que sur une application ciblée.

Le conseil pratique n'a rien de spectaculaire : aucun des deux choix ne sera ce qui rend votre interface rapide ou lente. La structure des composants, la récupération des données, le traitement des images et la quantité de JavaScript que vous livrez domineront. Choisissez celui que votre équipe sera à l'aise de maintenir, et investissez le débat ainsi économisé dans la mesure de ce qui se charge réellement.