Salut et bienvenue dans ce nouvel épisode du podcast de Codegarage,
je m'appelle Nicolas Brandon-Bernard et aujourd'hui on va parler du virtualdom.
Alors si vous utilisez des bibliothèques ou des frémoires qui appelaient comme vous voulez,
comme React, Préact ou Vu, eh ben vous utilisez un virtualdom et peut-être sans le savoir.
Alors à quoi est-ce que ça sert ? Est-ce que ça améliore les performances
d'une application web et dans quelle condition ? Et surtout est-ce qu'il y a des alternatives ?
On va voir un petit peu tout ça ensemble dans cet épisode.
Alors on va commencer par parler du DOM classique avant de parler du virtualdom.
Donc normalement vous le savez déjà mais le DOM c'est un acronyme pour document object model
et c'est simplement une représentation d'une page HTML par le navigateur,
sous en fait la forme d'un espèce d'arbre d'éléments,
pas une espèce d'ailleurs, c'est un arbre d'éléments qui va contenir des balises
et dans ces balises au bout d'un moment vous allez trouver des nœuds de texte.
Chaque élément, chaque attribut va devenir un objet que JAR script peut manipuler grâce à
l'API DOM et donc modifier le DOM en JAR script c'est agir directement sur cette structure.
Donc quand on va ajouter un élément, changer une classe, supprimer un nœud,
eh ben en fait ces opérations elles peuvent être coûteuses puisque chaque changement de
l'arbre d'homme va demander au navigateur d'abord de recalculer la mise en page,
c'est ce qu'on va appeler le reflow, ensuite il va devoir redessiner l'écran ou une partie
de l'écran c'est ce qu'on appelle repaint et ensuite s'il y en a il va devoir relancer des
animations, des transitions en CSS etc. Et quand une application est devin trop complexe,
qu'il y a des interactions qui sont très fréquentes ou qu'il y a vraiment un très
gros arbre d'homme pour une page ou simplement qu'il y ait des données dynamiques qui changent
automatiquement très fréquemment, eh bien les mises à jour de ce DOM vont se démultiplier et
modifier le DOM à chaque petit changement d'état, ça a des vraies conséquences sur les performances,
ça peut créer par exemple des ralentissements ou des fois vous pouvez voir un peu l'interface
ou les animations qui sont un petit peu saccadées. Et c'est pour ça que des ingénieurs sont arrivés
avec le concept de virtual DOM. Le virtual DOM c'est une copie virtuelle comme son nom indique qui est
en mémoire et donc c'est une copie du DOM réel. En fait quand on va avoir un changement qui
survient dans notre application, que ce soit réacte, vu peu importe, comme par exemple un clic
de l'utilisateur qui va déclencher un changement d'état, eh bien voilà ce qui se passe. En fait
d'abord on va avoir une copie de notre arbre virtuel qui va représenter le nouvel état justement
de l'interface et on va stocker cet arbre virtuel en mémoire. On va comparer cet arbre avec le
précédent, avec l'état précédent, c'est ce qu'on va appeler faire le diff ou le diffing. Ensuite on
va calculer les changements minimums qui sont nécessaires à appliquer sur le vrai DOM et on
va exécuter ces changements en général de manière groupée et optimisée. Ce processus là c'est
ça qui va permettre de rendre le DOM virtuel plus performant sur certaines opérations. Si je vous
prends un exemple très concret, ok, admettons que votre DOM est trois éléments à embriquer les
uns dans les autres, on va les appeler éléments A, B et C et que vous vouliez ajouter les nœuds
D et E juste en dessous en tant qu'enfant de l'élément B, eh bien on va avoir notre DOM de
base qui a les éléments A, B, C embriqués, notre virtuel DOM qui a les éléments A avec
dedans l'élément B, avec dedans à la fois l'élément C, l'élément D et l'élément E,
eh bien on va faire le diff de ça et donc le diff de ça, c'est simplement le nouvel élément D
et le nouvel élément E. Quand on va faire la reconciliation, notre DOM final aura l'élément D
et l'élément E. Alors maintenant pour rendre ça plus clair, je vais vous faire une petite
analogy, imaginez dans votre tête un designer qui doit mettre à jour un document imprimé. En
fait, il y a une version papier, ok, qui va être le DOM réel et il y a une version numérique qui
va être égale au virtuel DOM. En fait plutôt que de réimprimer tout le document à chaque petite
modification, eh bien on va comparer les deux versions, on fait tous les changements et on ne
réimprime que les pages modifiées. Alors maintenant si on revient sur notre concept de virtuel DOM,
à quel moment est-ce qu'on gagne vraiment en performance ? Eh bien en réalité, si on imagine
qu'il y a beaucoup d'interactions avec notre application et qu'en fait en l'espace d'un clic,
par exemple, on va avoir, admettons, donc on va reprendre nos éléments avec A, B, C, D, E, ok,
admettons qu'après un clic, eh bien notre élément D, eh bien il subisse plusieurs modifications. On
va dire par exemple que d'abord on a du texte à l'intérieur qui va changer, ensuite on a du texte
à l'intérieur du noeux qui est à l'intérieur d'une D qui va changer également et puis on va avoir
une couleur qui change et puis on a une classe qui s'ajoute. Là on a déjà quatre opérations et
en réalité on se rend compte qu'à la fin de toutes ces opérations, du coup, après notre clic,
eh bien l'élément D, il est simplement supprimé de l'arbre puisque en fait on n'en a plus besoin.
Toutes les autres modifications, c'est-à-dire les petits effets de bord qui n'étaient pas forcément
voulus mais en fait tous ces effets-là, ils auraient quand même été exécutés à la chaîne si jamais
on n'était pas passé par un virtual DOM. Donc ça veut dire que le DOM, il aurait été modifié cinq
fois. D'abord on change un texte, ensuite on change le texte d'un enfant, ensuite on change une
couleur, on change une classe, etc. pour enfin le supprimer. Alors que dans notre virtual DOM,
ces modifications-là, elles vont être faites les unes à la suite des autres mais comme c'est
Paint, Nieriflo, ni relancement de choses en CSS. Et donc en réalité, le diff qui va se faire au
final, eh bien c'était dans notre arbre d'homme, on avait ABCDE, on a dit qu'on a supprimé D et
que E était contenu dans D. Donc c'est la seule opération qui va être faite, on va supprimer l'élément D
qui contenait l'élément E. Donc en réalité, on a une opération sur le DOM réel contre cinq
opérations sur le DOM réel sans passer par le virtual DOM. Alors comme je le disais en tout début
d'épisode, c'est intéressant de savoir aussi quels sont les alternatives et si on a, et effectivement
on a deux autres assez gros frameworks ou bibliothèques, on va dire front-end qui ont une
stratégie différente. Il y a d'abord Svelte et il y a Angular. Alors Svelte, lui, il va faire les
modifications directement sur le DOM natif, mais il va compiler à l'avance en fait vos template
et toutes les opérations qui vont être liées justement à la modification du DOM. C'est à dire
que ce que je vous ai parlé tout à l'heure, selon je vous ai parlé tout à l'heure la réconciliation
entre, la phase de réconciliation entre le DOM virtuel et le DOM réel pour optimiser le nombre
d'opérations à faire, eh bien Svelte, il va le faire mais sans la copie du DOM, il va simplement
précompiler à l'avance, à chaque fois que vous allez lui dire, eh bien dès qu'il y aura un clic, il
y aura cette modification là, cette modification là, cette modification là, eh bien cette optimisation,
il va la faire pendant la compilation de votre app, parce qu'il connaît exactement quelle partie
du DOM doit être mis à jour dans quel ordre et à quel moment et donc pendant la compilation, il va
faire en sorte que si jamais vous supprimez à la fin l'élément que vous aviez modifié juste avant,
eh bien il va pas faire les modifications, il va simplement faire la suppression. Donc ça veut dire
que ça fonctionne, c'est souvent plus performant, Svelte est un des plus performants, mais ça veut
dire aussi qu'il est un petit peu moins flexible dans son utilisation et qu'il a besoin de tout un
système de build, de compilation qui est plus lourd et plus complexe, on va dire, que React,
alors notamment React, et donc par exemple React, on retrouve du server-side-run-dering avec Next,
des choses comme ça ou même React Native, eh bien en fait Svelte est beaucoup moins capable de
faire des choses comme ça puisque eh bien elle est uniquement, il génère du code uniquement pour le
navigateur et du code le plus optimisé possible. Donc ça c'était la solution de Svelte et la
solution d'Angular, Angular lui il va simplement écouter en fait à chaque fois que vous avez une
donnée qui est injectée dans un template, eh bien il va écouter simplement la modification de ses
données et réagir à chaque fois qu'il y a une modification de la donnée, mais ce qui fait aussi
que Angular est un de ceux qui est le moins performant puisque quand vous utilisez React avec le
Virtualdom et des bons hooks bien adaptés avec Memo, Use Callback etc évidemment,
je vais pas vous expliquer aujourd'hui, mais vous arrivez vraiment à avoir des performances très
très bonnes et qui se rapprochent même un petit peu de celle de Svelte, mais Angular restera
toujours un peu derrière puisque pour le coup lui les opérations dont on a parlé tout à l'heure
avec modification d'un élément, changement de sa couleur et suppression, eh bien en fait il
va effectuer les trois modifications, les unes à la suite des autres, donc on va perdre nécessairement
performance, mais c'est possible évidemment d'avoir un framework moderne et qui marche quand
même très très bien évidemment, qui est utilisé par plein de grosses entreprises, mais qui marche
sans Virtualdom. J'espère que cet épisode vous aura plu, que vous aurez appris des choses, moi je vous
donne rendez-vous la semaine prochaine pour un prochain épisode, alors attention pendant l'été,
là on commence à s'approcher de l'été, je vais prendre un petit peu de vacances, on aura peut-être
un petit peu moins d'épisodes ou en tout cas un peu moins fréquemment, mais il y en aura quand
même, ne vous inquiétez pas. En tout cas je vous retrouve sur code-garage.com pour retrouver
tous nos articles de blog, tous nos épisodes de podcast, tous nos cours et là il y a même des
choses, je peux pas vous en dire trop mais il y a des choses, en plus des cours, une nouvelle grosse
fonctionnalité sur la plateforme qui arrive et donc pas mal de personnes me parlent depuis des années
et ça va enfin sortir, donc j'ai très très hâte de vous en parler, mais avant de se quitter,
rappelez-vous de laisser cinq étoiles, un commentaire, un avis, surtout maintenant on peut laisser des
commentaires sur Spotify, donc on peut échanger directement et moi je peux vous répondre,
je réponds à quasiment tous les commentaires, donc franchement allez-y et la note de cinq
étoiles évidemment pour que le podcast continue de monter dans le référencement.
Moi je vous donne rendez-vous la semaine prochaine pour un prochain épisode, prenez soin de vous, salut !