Il est déjà bien compliqué de choisir des bibliothèques lorsque l'on veut faire quelque chose, mais alors c'est encore pire pour ce qui est d'un framework JavaScript.

Il est fort probable que votre futur site ou application web se base sur un framework du fait de sa taille ou encore de ses besoins, bien que l'on recommande parfois plutôt l'usage de plusieurs bibliothèques très spécialisées.

✨ Cet article a été actualisé en Août 2020 pour suivre les évolutions du domaine.

⚡ La vitesse extrême avec les SPA

A une époque où l'ADSL commençait à devenir commun chez les internautes, la navigation web restait plutôt lente, l'émergence des plugins tiers permettant l'inclusion de média riches (Shockwave, Flash, Java...) dans les sites web n'arrangeant pas du tout la chose. La technique de l'AJAX était alors une aubaine : pouvoir charger uniquement le contenu qui nous intéressait lors d'une interaction de l'utilisateur, plutôt qu'une page dans son intégralité (accompagnée de ses feuilles de style, ses scripts, ses images...).

C'est alors qu'a émergé une nouvelle façon de concevoir des sites web, celle des "Single-Page Application" (aussi appelée SPA). Concrètement, après le premier chargement correspondant à l'arrivée du visiteur sur le site web, tout le reste de la navigation ne se fera que par des requêtes émises en JavaScript.

Mais faire un site ou une application single-page nécessite d'écrire du JavaScript, beaucoup de JavaScript ! D'où l'apparition de véritables frameworks, permettant de gérer l'affichage de votre site, les formulaires, la réception et l'envoi de données, voire bien plus.

🏚️ Les vieux de la vieille

Commençons comme d'habitude par un petit histoire afin de comprendre l'évolution de tout cela.

Backbone, sorti en 2010, a tenté de dompter un peu les développeurs JavaScript en leur expliquant par exemple qu'il fallait arrêter de maltraiter le DOM à la main, et qu'utiliser le pattern Model-View était une meilleure idée.

Il apporte aussi un système de "collections" qui permet de facilement gérer la récupération et la modification de données à travers une API RESTful, ainsi qu'un système routage, d'événements... en somme, pas mal d'idées reprises dans les frameworks qui l'ont suivi.

Knockout, sorti la même année, décide de tout miser sur le pattern Model-View-ViewModel (MVVM). Il demandera alors d'écrire des informations complémentaires dans le HTML de son application web pour relier des éléments HTML à des choses côté JavaScript : des variables, des fonctions...

En 2011 apparaît le framework Ember.js, lui aussi basé sur le pattern MVVM, et friand très tôt des fonctionnalités modernes de JavaScript dès qu'elles étaient disponibles. Il reste aujourd'hui un acteur majeur dans le monde JavaScript, et est utilisée par les plus grandes entreprises : Apple, Microsoft, Netflix, LinkedIn, Square...

Mais alors, pourquoi "augmenter" le HTML ? Sûrement pour éviter d'avoir du code trop verbeux en JavaScript, ou juste pour garder tout ce qui concerne la présentation des données dans le HTML... Cette façon de faire aura rapidement décollée et restera utilisée par la majorité des frameworks.

🦸 Le sauveur... de courte durée

AngularJS est un framework conçu par Google et révélé au grand jour en 2009, qui aura bousculé le petit monde du JavaScript avec son idée de "two-way data binding". Comme les précédents frameworks, vous reliez des valeurs ou fonctions JavaScript au HTML en y rajoutant des attributs spécifiques, mais désormais tout se fait en temps réel et dans les deux sens : toute composant HTML qui change (du texte écrit dans un champ, une sélection faite dans une liste) peut immédiatement appeler du JavaScript et mettre à jour quelque chose ailleurs sur la page.

Mais ce cher framework a aussi apporté un bon lot de choses tout aussi originales que complexes : les contrôleurs, les services, les scopes, l'injection de dépendances... en somme, beaucoup de moyens de palier au fait que JavaScript était, à l'époque, inadapté à l'écriture de grosses applications. C'est probablement cela qui explique l'amour du framework par un grand nombre d'entreprises à sa sortie, et c'est ainsi qu'il peut exister encore et toujours des applications en AngularJS 1 qu'il faudra maintenir pendant un moment.

Le framework aura été entièrement réécrit à l'occasion de sa version 2, pour s'adapter aux évolutions apportées par ECMAScript 2015. Depuis, on ne dira plus que "Angular" tout court. Il reste activement développé par Google mais son côté "usine à gaz" lui colle encore à la peau, et il n'est de ce fait pas très apprécié par beaucoup de développeurs. On notera aussi qu'Angular aura fini par choisir TypeScript comme langage de préférence !

💡 Et si l'on mettait du JS partout ?

Malgré l'architecture très classique du MVC, ou celle très spécifique d'Angular, certains frameworks ont cherché encore plus loin pour réinventer la façon de faire des applications web.

Un de ces frameworks s'appelle Meteor, dont le développement a débuté en 2011, avec sa première version stable en 2014. Parmi toutes ses originalités, sa plus grande est sa conception dite en "fullstack JavaScript".

Cela veut dire qu'il se compose non seulement d'une partie exécutée côté client - comme tous les autres frameworks - mais également d'une partie exécutée côté serveur grâce à Node.js. En plus d'avoir le même langage partout, il permet aussi de développer une application dite isomorphique : un même code de logique applicative peut s'exécuter aussi bien côté client que côté serveur.

Un exemple d'utilisation de l'isomorphique : côté serveur, votre application renvoie des réponses HTML classiques à n'importe quel visiteur, et côté client, elle pourra faire des appels vers une API ou une base de données directement dans le navigateur du visiteur et faire par la même occasion le rendu du contenu HTML sans même recharger la page. Ou alors, on peut par exemple utiliser un cache dans le navigateur avant d'envoyer directement des données au serveur, en cas de perte de la liaison internet.

Même si Meteor a l'avantage de proposer une solution "clés en main" où tout fonctionne en harmonie dès le début du projet, il présente aussi l'inconvénient apporté par ces frameworks : être souvent contraint d'utiliser certaines solutions techniques, par exemple MongoDB comme base de donnés.

🔪 Diviser pour mieux coder

Dans la recherche d'un monde web meilleur, le concept des Web Components émerge à travers quatre nouvelles spécifications dans HTML5. La spécification principale est celle des Custom Elements, qui permet de créer de nouveaux éléments HTML avec les caractéristiques suivantes :

• Personnalisés : La création de nouvelles balises HTML est possible pour représenter nos propres composants, par exemple <app-menu>
• Atomiques : Il faut de préférence que le composant ait une petite influence ou qu'il représente une petite fonctionnalité, ce qui tends à rendre son code plus compréhensible et plus facilement réutilisable grâce à une découpe réfléchie
• Isolés : Un composant doit idéalement pouvoir fonctionner sans dépendre d'un autre, vu qu'il est désormais possible d'isoler son contenu (ainsi que son style CSS) de la page web dans lequel il est utilisé

Il y a eu très tôt un certain frein à la démocratisation des Web Components : non seulement l'écriture de ces spécifications a pris du temps, mais les principaux créateurs de moteurs web (Apple, Google et Mozilla) ont surtout eu beaucoup du mal à se mettre d'accord. L'implémentation de ce concept pouvant avoir plusieurs formes très différentes, arriver à un consensus est difficile et Mozilla nous en a par exemple raconté les raisons dans cet article.

Avant la finalisation même de ce concept, Google a voulu proposer une bibliothèque pour pouvoir s'en servir au plus tôt : Polymer, présentée en 2013 avant d'avoir une première version stable en 2015 : création facilitée de Custom Elements, two-way data binding, logique dans les templates HTML... Aujourd'hui, cette bibliothèque n'est donc plus nécessaire, et il est proposé à la place LitElement pour faciliter la création de Web Components suivant les standards.

Aujourd'hui, toutes les spécifications liées aux Web Components sont enfin terminées et supportées par tous les principaux navigateurs web, mais la réussite et la performance des bibliothèques comme React ou Vue.js peut rendre difficile le fait de s'intéresser à cette alternative, qui n'est pas forcément nouvelle mais qui aura pris énormément de temps à être utilisable.

✨ Le duo gagnant

En plus de ce concept des Web Components, est arrivé un tournant dans l'écosystème des bibliothèques/frameworks JavaScript avec l'arrivée quasi simultanée de deux acteurs majeurs, qui restent indémodables à l'heure actuelle.

Facebook et Instragram,  révèlent en 2013 la bibliothèque React avec une approche radicalement différente : une circulation des données "du haut vers le bas" ("one-way" plutôt que "two-way"), un DOM virtuel pour de meilleures performances, et une écriture des vues en dans un nouveau paradigme appelé "JSX". Bien qu'elle soit plus une "bibliothèque d'interface" plutôt qu'un gros framework, elle apporte pas mal de nouvelles notions ainsi que tout un process de développement front-end à appréhender, mais qui vaut largement le coup.

En deçà des géants du web, on trouve aussi de bonnes surprises de la part d'indépendants. Evan You, un ancien de chez Meteor et de chez Google, lâche dans la nature sa bibliothèque Vue.js en 2014 avant de proposer une version stable fin 2015. Légère et pragmatique, elle offre bon nombre de fonctionnalités déjà vues dans Angular voire dans React, mais de façon plus simplifiée et plus facile d'accès. La bibliothèque a donc pu gagner une certaine popularité dans le domaine concurrentiel des bibliothèques JavaScript (notamment en Asie).

🔜 Next time on the series...

Après avoir vu les bases du monde qui représente JavaScript, il est temps d'aller explorer des choses un peu plus pointues. Pour le prochain article de cette série, on parlera ainsi de ce que l'on appelle les "package managers".