La question de la performance se pose assez souvent lorsque l'on parle des librairies front-end. Même si dans les faits cela vient souvent d'une mauvaise utilisation de ces librairies, il est intéréssant de comparer le fonctionnement pour mieux comprendre les points d'optimisation. Et aujourd'hui on va voir pourquoi VueJS est plus performant de base que React.
Les blocs statiques
Le premier point qui rend VueJS plus performant de base est l'utilisation d'un compileur qui va venir transformer de manière plus importante le code des fichiers .vue en fichier JavaScript. Dans le cas du JSX la transformation est plutôt simple, les éléments JSX sont remplacés par un appel à la fonction createElement de React.
<div id="demo">Bonjour les gens</div>;
// Donnera
React.createElement("div", { id: "demo" }, "Bonjour les gens");VueJS, lors de sa transformation va détecter les noeuds statiques (qui ne dépendent pas de l'état du composant) et va "hoister" la définition de ces noeuds en dehors des composants afin de ne pas avoir à les regénérer à chaque rendu.
const _hoisted_1 = /* @__PURE__ */ createBaseVNode("div", null, [
/* @__PURE__ */ createBaseVNode("h1", null, "Hello world"),
/* @__PURE__ */ createBaseVNode("p", null, " Lorem ipsum dolor sit amet consectetur adipisicing elit. Inventore at quos deserunt deleniti. Recusandae architecto ipsa voluptatum fugiat, ea voluptatem, quod reiciendis eaque sequi aperiam adipisci placeat dolorum excepturi quidem! ")
], -1);Ici par exemple, Vue a détecté que cette div était statique et a déplacé automatiquement la définition en dehors de la fonction ce qui permet de ne pas recréer ces éléments à chaque rendu à chaque nouveau rendu.
Côté React une telle optimisation doit être fait manuellement à l'aide d'un React.memo() et d'un composant dédié. Cela permet aussi plus de contrôle de la part du développeur et permet de ne pas générer des noeuds qui ne seraient finalement pas utilisés.
Les rerendu
Le second point, et le plus important à mon sens, est la manière qu'à Vue.js de gérer les rendus des composants enfants. En effet, dans react un composant enfant est rerendu lorsque le composant parent est rendu. Dans le cas de Vue.js les sous-composants ne sont rendu que si les propriétés changent.
<template>
<div>
<p>
Votre nom : {{ name }}
<input type="text" v-model="name">
</p>
<MyTable :items="items">
</div>
</template>Dans cette situation, le composant MyTable ne sera rendu que si la valeur de items change. Sur React cette optimisation doit être fait de manière explicite par le développeur en créant un composant pur.
const MyTable = memo(({items}) => {
return <div>{/* ... */}</div>
})Computed
Les propriétés calculés sur Vue.js ne sont calculé que lorsque le composant y fait référence. Par exemple sur React.
export function MyPassword ({password}) {
const hashed = hash(password)
// ....
return <div>Hash : {hashed}</div>
}Le calcul du hash se fera ici avant chaque rendu.
<template>
<div>Hash : {{hash}}</div>
</template>
<script setup>
const props = defineProps({
password: String
})
const hashed = computed(() => hash(password))
</script>Côté Vue.js la valeur de hashed ne sera recalculée que lorsque la valeur est utilisée. Si la valeur n'est pas requise dans le template alors le calcul ne sera pas fait. Aussi, Vue.js est capable de détecter les valeurs utilisées et ne fera ici le calcul que lorsque password change.
Sur React, on pourra éviter les calculs mais il faudra encore une fois le faire de manière explicite.
export function MyPassword ({password}) {
const hashed = useMemo(() => hash(password), [password])
// ....
return <div>Hash : {hashed}</div>
}Donc Vue.js > React ?
D'après ces exemples on pourrait penser que Vue.js est un meilleur choix que React quoi qu'il arrive mais dans la réalité on est ici devant deux approches différentes. Vue.js préfère automatiser un maximum de chose pour permettre de se focaliser sur le code / logique et offrira de base de meilleur performances au détriment parfois d'un petit manque de contrôle.
React, quant à lui, ne fait rien automatiquement et demandera au développeur d'être plus explicite s'il souhaite optimiser les performances. Ce qui finit parfois par ajouter pas mal de bruit dans le code.
