Etat de l’art des bibliothèques front-end en 2017
L’état de l’art est l’état des connaissances à un instant donné selon Wikipedia. Or dans le web, on peut dire que cet état est en mouvement perpétuel, les techniques changent, les bibliothèques et frameworks changent avec elles, vite, très vite.
Pour donner un ordre d’idée, les bibliothèques majeures depuis 10 ans sont:
- jQuery en 2006
- AngularJS en 2009
- React en 2013
- PolymerJS en 2014

On trouve des dérivés, ils sont très nombreux, qui font plus ou moins la même chose autour de ces moteurs de vue comme Marko, Mithril, Mustache, Jade, Pug, VueJS, etc. Mais fondamentalement, certaines étapes technologiques sont passées et on ne revient pas en arrière sur ces avancées.
Le virtual-dom pour les performances
C’est le cas par exemple du virtual-dom, technique qui consiste à maintenir une version “json-like” du DOM et de ne changer le DOM que de façon incrémentale plutôt que de tout remplacer en fonction de l’image JSON équivalente (comme un proxy), le gain en performance est très appréciable car manipuler le DOM consomme de la ressource, en effet lors d’une manipulation comme appendChild le navigateur doit recalculer les styles, le layout, etc. On trouve ce virtual-dom dans la plupart des bibliothèques aujourd’hui, depuis AngularJS 1.
Le déclaratif pour la robustesse
Le templating déclaratif est aussi de la partie, bien que aussi vieux que le HTML lui-même qui consiste à construire de façon déclarative la vue plutôt que la construire de façon impérative. La différence est simple, dans le premier cas on écrit du HTML et dans l’autre on écrit du code Javascript. L’avantage d’être déclaratif, donc d’écrire du HTML, c’est qu’il n’y a pas d’algorithme à l’opposé de l’impératif qui consiste à faire un enchainement de createElement et appendChild, en somme un programme… C’est ce qu’utilisent AngularJS et React alors qu’avec jQuery, il faut ajouter des ‘event listeners’ de façon impérative.
Les standards à la place des bibliothèques
Par ailleurs, il est bon de rappeler que jQuery devrait être un fantôme du passé. Cette librairie a été créée à l’époque pour supporter les différences entre les navigateurs, je pense à addEventListener Vs. attachEvent, ce dernier n’était compatible que avec Internet Explorer et ce n’était pas standard. Aujourd’hui, les navigateurs suivent les standards, avec plus ou moins de retard, mais ils ont une base commune sur laquelle on peut s’appuyer, une API commune, super ! Il n’est plus utile par exemple d’appeler $(‘.element’) pour trouver un élément avec jQuey, un document.querySelector(‘.element’) fait le même travail et est standard. Il en est de même pour les évènements, etc. Seul ajax reste un peu complexe et mérite une encapsulation en attendant la future implémentation améliorée appelée fetch. De manière générale il est facile de savoir ce qui est supporté par les navigateurs via http://caniuse.com/ autant pour le HTML que pour l’API Javascript.
L’approche par composant
L’une des dernières nouveautés dans le templating front-end n’est pas une technique mais un design pattern. Celui du composant, ou component en anglais. Introduit avec AngularJS 2.0 et React, il casse les vues contenant une page entière en morceaux réutilisables. Hum, ça ressemble à de l’objet, non ? Qui dit encapsulation, dit facile à tester et maintenir avec un effet de bord proche de zéro ! On retrouve ce concept un peu partout dans les bibliothèques d’aujourd’hui, VueJS et Marko le proposent en plus de leur rendu habituel à la AngularJS 1. De base, le web contient de nombreux composants: input, button, ul, form, etc. La différence réside dans la déclaration de nouvelles balises, par exemple <x-logo /> serait une balise qui contient une image. <x-avatar /> serait une balise avec l’avatar d’un utilisateur avec des informations au survol de la souris. Bref, des composants qui sont réutilisables et testables, le rêve.
Le futur des standards: les web components
Les standards du web (W3C) suivent et s’inspirent des tendances, par exemple querySelector vient de jQuery, un besoin est créé, une lib le comble puis un standard arrive. Ce n’est pas toujours le cas, le web manque cruellement, selon-moi, d’un moteur de template, il est obligatoire aujourd’hui d’utiliser une bibliothèque encore aujourd’hui pour cela. Avec l’arrivée des template strings via l’ES2015 on peut faire un premier pas et ouvre des possibilités qui seront sans aucun doute exploitées. D’autres complètent ces nouveautés, on peut nommer les web components qui sont en draft et utilisables aujourd’hui en avance grâce à PolymerJS. Il s’agit de déclarer ses propres balises par composant comme vu plus haut, de façon native et standard. Celui-ci utilise son propre moteur de rendu au-dessus d’un standard qui déclare de nouvelles balises. Plus d’informations sur les web components ici. Rapidement cela donne le code suivant:
class Avatar extends HTMLElement {onClick...render...}
window.customElements.define('x-avatar', Avatar);Le langage importe peu. La plupart des templates se font compiler… C’est le cas de React / JSX qui permet de mettre du HTML dans le Javascript, c’est le cas de Angular / Marko qui permettent d’écrire du Javascript dans le HTML. Jade, qui est une syntaxe minimaliste pour produire du HTML. Dans tous les cas pour faire du templating dynamique il faut forcément passer par l’interprétation de Javascript côté navigateur, que ce soit écrit à la main ou compilé depuis ES2015, Java, JSX, etc. On peut tout de même écrire du template à la main, en Javascript bien sûr, via Hyperscript qui n’est en fait que du Javascript déclaratif (un enchainement d’objets et de tableaux).
En bref
Un outil de rendu doit avoir au minimum:
- du virtual-dom
- une approche par composant (avec ou sans balise personnalisées)
- une démarche déclarative
Accompagné des éléments inhérents au web: produire du code HTML et écouter les évènements qui s’en échappent.

Aller plus loin
Je terminerais avec deux liens vers deux avis très différents que sont l’approche par composant Javascript pur (comme React) et l’approche web components (PolymerJS) qui doit être un standard prochainement mais qui est toujours en draft à l’heure actuelle.
Plaidoyer pour React et ses clones:
https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/
Plaidoyer pour les web components (réponse à l’article ci-dessus):
https://robdodson.me/regarding-the-broken-promise-of-web-components/
Sur le long terme, ces deux approches finiront peut-être par fusionner en un standard. L’avantage des standards c’est qu’ils ne périssent pas ou peu. <form> est toujours présent aujourd’hui et le sera toujours, une API unique peu importe le projet et l’année de sa conception (quasiment), ce qui n’est pas du tout le cas de ceux qui sont basés sur un framework qui ne sera plus maintenu. Quid des applications sous AngularJS 1 alors que tout a changé depuis la version 2 et que nous sommes à la 4 ? La maintenance devrait être le soucis majeur quand on choisit ses outils pour une application. C’est à elle qu’il faudra rendre compte 2–3 ans après la création du projet, une application qui n’est pas maintenable est une mauvaise application en production. Il semble que le VanillaJS (cf. Javascript sans framework) aura toujours de beaux jours devant lui dans les méandres des évolutions techniques.
Et vous ? Quel moteur pour une application maintenable sur le long terme ?
