Afficher des données dynamiquement

Optimiser le chargement initial

Comparer différentes approches

Comme souvent en informatique, il n’existe pas de solution absolue pour effectuer un rendering. Il s’agit donc plutôt de trouver le bon équilibre entre maintenabilité, lisibilité et performance. L’importance respective de chacun de ces points variant suivant le contexte, il en est de même pour l’approche à adopter.

Pour nous assurer que nous faisons le bon choix, nous avons cependant besoin de savoir quel impact chacune de ces approches a sur les performances. Or, effectuer ce type de test s’avère souvent complexe, voire trompeur. Car la seule évaluation du temps de traitement du code JavaScript effectuant ce rendu ne peut suffire ici.

Du point de vue de notre code JavaScript, la DOM API fonctionne de manière synchrone. Lorsque, par exemple, nous exécutons le code suivant, aucune promise ni aucune callback n’est susceptible de nous indiquer que ces opérations peuvent prendre un temps plus long pour être traitées que les lignes de code elles-mêmes.

const el = document.createElement("div"); 
el.textContent = "Hello World!"; 
document.querySelector(".container").appendChild(el); 

Et pour cause : l’évaluation de ces instructions elles-mêmes est bel et bien synchrone. Seul l’affichage (paint) est, lui, asynchrone.

Soit l’opération suivante (où heavyHTML génère une chaîne de caractères représentant un code HTML composé de plus de 2 000 éléments) :

const container = document.createElement("div"); 
document.querySelector("main").appendChild(container); 
container.innerHTML = heavyHTML(); 
container.innerHTML = "<p>Hello World</p>"; 

Son "évaluation" est rapide, comme nous pouvons le voir en nous rendant dans les outils de développement Chrome, sous l’onglet Performance.

Bien utiliser la DOM API

Si l’on part de l’essentiel et que l’on fait abstraction de toute bibliothèque, la première question à se poser en matière de rendering est : "comment créer et afficher un ensemble d’éléments HTML ?". Il s’agit en effet de la première base de tout développement web, à tel point qu’il est possible de l’illustrer par un simple "Hello World!" :

const el = document.createElement("div"); 
el.textContent = "Hello World"; 
document.body.appendChild(el); 

Un tel exemple est cependant loin de représenter une réponse suffisante, sans aucune évaluation de l’expérience de développement ni des performances.

createRow(data) { 
  const tr = document.createElement('tr'); 
  const tds = [ '', '', '', '' ].map(() => { 
    return document.createElement('td') 
  }); 
 
  tds[0].classList.add('col-md-1'); 
  tds[0].textContent = data.id; 
 
  tds[1].classList.add('col-md-4'); ...

Littéraux de gabarit et innerHTML

Simple, efficace et comparable dans sa forme aux templates Angular, JSX ou Vue, l’association de littéraux de gabarit et de la propriété innerHTML est omniprésente dans les articles et livres traitant de développement web moderne. Nous l’avons d’ailleurs utilisée à de nombreuses reprises dans les chapitres précédents, afin de simplifier nos exemples. Du fait même de sa simplicité (et malgré ses très nombreux défauts), elle est (bien trop) souvent recommandée et adoptée dans le cadre d’applications Vanilla JS "réelles", en production.

Nous pouvons pourtant exposer ses limites par des exemples simples. Commençons donc par créer un code minimaliste comparable à celui présenté au chapitre Adopter une approche par composant, section Liens avec une approche fonctionnelle. Commençons donc par créer un code minimaliste similaire (mais non orienté composant), incrémentant et décrémentant un compteur count suite à un clic sur des boutons et affichant en continu sa valeur. 

{ 
  let count = 0; 
 
  const increment = () => { 
    count++; 
    render(); 
  }; 
 
  const decrement = () => { 
    count--; 
    render(); 
  }; 
 
  const container = document.querySelector("main"); 
 
  function render() { 
    container.innerHTML = ` 
      <p>${count}<p> 
      <div> 
        <button onclick="increment()">++</button> 
        <button onclick="decrement()">--</button> 
      </div> 
    `; 
  } 
 
  window.increment = increment; 
  window.decrement = decrement; 
 
  render(); 
} 

Ce code pose cependant plusieurs...

HyperScript

Nous sommes à ce stade face à un choix difficile :

Nous aurions donc besoin d’une nouvelle interface de programmation associant lisibilité et performance tout en permettant, idéalement, d’accéder efficacement et simplement aux éléments enfants afin d’effectuer des mises à jour ciblées.

Un grand nombre de bibliothèques offrent une syntaxe déclarative spécifique afin de répondre à ce type d’attentes. Toute syntaxe non standard exige malheureusement d’effectuer une analyse syntaxique. Analyse qui demande souvent d’effectuer de nombreux traitements, ralentissant d’autant plus l’application. 

Afin d’éviter de tels ralentissement, de nombreuses bibliothèques permettent d’effectuer cette analyse en amont, hors navigateur. Un template déclaratif est alors traduit en un ensemble d’instructions impératives moins coûteuses. React permet notamment d’utiliser JSX à cette fin, tandis qu’Angular propose une compilation AOT (Ahead-of-time).

Certaines bibliothèques offrent, cela dit, une interface purement programmatique "au-dessus" de la DOM API, ne nécessitant aucune analyse syntaxique.

Minimiser les accès au DOM

En matière de rendering, le DOM constitue le principal goulot d’étranglement.

Le DOM étant fortement hiérarchisé, chaque modification est susceptible d’entraîner deux opérations : un repaint, calcul de la visibilité de l’ensemble des éléments du DOM, quand seul l’aspect des éléments est affecté (en modifiant par exemple background-color, opacity ou visibility), ou un reflow, encore plus coûteux, puisque devant réévaluer les dimensions et les positions de l’ensemble des éléments suite à la modification d’un seul.

Le navigateur doit systématiquement effectuer un calcul lourd, bloquant toute autre opération. Ce qui peut, dans le pire des cas, figer la page de manière visible.

Afin de minimiser ce coût, plusieurs bonnes pratiques sont à respecter :

Cela dit, diminuer autant que possible le déclenchement de nouveaux repaints ou reflows constitue toujours la meilleure optimisation. En servant de "tampon", un VDOM vise précisément à ne déclencher une mise à jour du DOM (par réconciliation) qu’au moment le plus opportun, tout en offrant l’illusion d’une modification continue, justifiant ainsi largement sa popularité. Nous avons vu, en prenant l’exemple de RE:DOM, qu’il est parfaitement possible d’obtenir de très bonnes performances sans VDOM. Optimiser les accès au DOM demeure malgré tout indispensable. Ce qui pourra nécessiter des stratégies similaires à celles mises en œuvre dans le cadre d’un...

Optimiser pour la répétition

Nos benchmarks, afin de pousser le navigateur dans ses retranchements, répètent un très grand nombre de fois (1 000 et 10 000, suivant les tests) les mêmes opérations. Le composant "ligne" est donc lui-même instancié à de nombreuses reprises. Or, pour l’heure, ce composant a été essentiellement pensé pour n’être utilisé qu’une seule fois dans la page (comme peuvent l’être la plupart des vues associées à des routes). Dans ces conditions, les différences de performance jusque-là constatées ne sont pas significatives.

Or, si un même template HTML est reproduit à de nombreuses reprises, créer un élément via document.createElement (ce qui comprend donc notre exemple HyperScript) a un défaut majeur : le même code étant exécuté à chaque itération, générer 1 000 éléments augmente d’autant le temps d’exécution et la quantité de ressources consommées. En d’autres termes : nous ne faisons aucune économie d’échelle.

Il est donc préférable, dans ce cas, d’optimiser la création de l’élément en effectuant un maximum de traitements en amont. Ce que nécessite la définition d’un "patron" représentant l’ensemble de la structure statique de l’élément à générer.

const counterChildrenCache = new WeakMap(); 
 
function counterChildren() { 
  if (counterChildrenCache.has(this)) { 
    return...

Conclusion

Nous avons vu dans ce chapitre plusieurs approches permettant d’effectuer un rendering plus ou moins efficace sans faire appel à des bibliothèques. Toutes comprennent cependant de nombreux défauts. En particulier, l’expérience de développement obtenue semble très loin de celle offerte par la plupart des frameworks modernes.

Nos exemples sont simples, voire simplistes. Les développer au-delà de ces simples concepts aurait demandé des centaines de pages supplémentaires, voire un livre entier dédié à ce seul sujet. Ils démontrent cependant assez clairement que le rendering est toujours complexe et demande toujours une réflexion poussée.

À mesure qu’elle gagne en complexité, une application purement Vanilla JS risque de contraindre l’équipe de développement à "réinventer la roue", en demandant la création de sa propre bibliothèque de rendering généraliste (ce qui n’est jamais l’objectif), susceptible d’être reprise intégralement à mesure que l’équipe gagne en compétences et doit répondre à des questions nouvelles. La seule "bonne" solution dans ce genre de cas est donc de très peu mutualiser ce code, divers composants étant susceptibles de se reposer...

Références

1. NORMAN D. Le design des objets du quotidien [En ligne]. Revised and expanded edition. [s.l.] : Librairie Eyrolles, 2013. 347 p. Disponible sur : https://www.eyrolles.com/Entreprise/Livre/le-design-des-objets-du-quotidien-9782212678833/ (consulté le 30 novembre 2020) ISBN : 978-0-465-05065-9.

2. « Basics of UX | Web Fundamentals ». In : Google Developers [En ligne]. [s.l.] : [s.n.], [s.d.]. Disponible sur : https://developers.google.com/web/fundamentals/design-and-ux/ux-basics?hl=fr (consulté le 30 novembre 2020).

3. CASIMIR M. « UX/UI For The Modern Web Developer ». In : Medium [En ligne]. [s.l.] : [s.n.], 2018. Disponible sur : https://medium.com/@maloriecasimir/ux-ui-for-web-developers-d5547a4d9b24 (consulté le 30 novembre 2020).

4. KRUG S. Don’t make me think, revisited : a common sense approach to Web usability. Third edition. Berkeley, Calif. : New Riders, 2014. 200 p. ISBN : 978-0-321-96551-6.

5. GARRETT J. J. The elements of user experience : user-centered design for the Web and beyond. 2nd ed.Berkeley, CA : New Riders, 2011. 172 p. (Voices that matter). ISBN : 978-0-321-68368-7.

6. « Paint Timing 1 editor’s draft ». In : W3C [En ligne]. [s.l.] : [s.n.], [s.d.]. Disponible sur : https://w3c.github.io/paint-timing/ (consulté le 1^er décembre 2020).

7. « High Resolution Time Level 2 ». [s.l.] : [s.n.], [s.d.]. Disponible sur : https://www.w3.org/TR/hr-time-2/ (consulté le 1^er décembre 2020).

8. « Navigation Timing Level 2 ». [s.l.] : [s.n.], [s.d.]. Disponible sur : https://w3c.github.io/navigation-timing/ (consulté le 1^er décembre 2020).

9. « User Timing Level 3 »....