JavaScript's Bizarre Adventure - Part 4 : les frameworks

JavaScript

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, malgré que l'on recommande plutôt en ce moment l'usage simultané de plusieurs bibliothèques très spécialisées, mais cela ne nous empêchera pas de faire un point dessus.


La vitesse extrême avec les SPA

AOL

Vous allez voir, l'internette c'est vraiment trop génial !

A une époque où l'ADSL commençait à devenir commun chez les internautes, la navigation web resta 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 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 se fera par des requêtes émises en JavaScript. Il est dans certains cas possible de charger l'intégralité du site web d'un coup pour ne plus avoir à faire de requêtes lors de la navigation, mais il faudra alors faire attention à la consommation mémoire.

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

Batman

Knockout dans ta tête si tu n'écris pas proprement tes scripts !

Plusieurs frameworks ont évidemment vu le jour, mais nous n'en verrons qu'une petite sélection, et ce dans un ordre précis.

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, et qu'utiliser le pattern Model-View c'était très bien, mais surtout, c'était mieux.

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... soit pas mal d'idées qui seront reprises dans les frameworks qui l'ont suivi.

Knockout, qui est sorti la même année, décide de tout miser sur le pattern MVVM : Model-View-ViewModel. Un peu comme AngularJS, 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...

Mais alors, pourquoi "augmenter" (coucou Deus Ex) le HTML ? Sûrement pour éviter d'avoir du code trop verbeux en JavaScript, ou juste pour garder tout ce qui influence la présentation dans le HTML... Bref : qu'importe les raisons, cette façon de faire a rapidement décollé et reste utilisée par la majorité des frameworks.

Le sauveur... de courte durée

Angular

Les différents états d'un développeur essayant de comprendre AngularJS

AngularJS est un framework conçu par Google et révélé au grand jour en 2009, et-

Attends attends, genre il est sorti avant Backbone et Knockout ? Mais la logique dans tes articles quoi franchement

Alors déjà, on va se calmer. Ensuite, certes, c'est pas faux, mais AngularJS ayant une conception beaucoup moins "classique" que les deux derniers, il est généralement vu comme étant "plus moderne" qu'eux. (notez les gros guillemets ici)

Commençons donc par le constat qui va en fâcher plus d'un : AngularJS c'est terminé. Tout du moins, dans sa version actuelle. Alors oui, il a très bien démarré, apporté une solution originale à une problème d'actualité et vécu son âge d'or, sa conception réalisée au début d'une ère fait qu'il est aujourd'hui déjà obsolète. "Noraj de mon obsoletage", comme on dit chez les jeunes.

Bref, ce qui a quand même bousculé le petit monde du JS chez AngularJS, c'est surtout son "two-way data binding". Tout simplement, en écrivant des attributs spécifiques dans les éléments HTML de votre site web, vous pouvez les lier à des valeurs ou fonctions JavaScript, et ce en temps réel ainsi que dans les deux sens. Que ce soit la liaison d'un champ de formulaire ou celle d'un bouton qui appelle une fonction JS lorsque l'on clique dessus, tout un champ de possibilités s'est ainsi ouvert (waouh !).

Mais ce cher framework a aussi apporté un bon lot de choses aussi originales que complexes : les contrôleurs, les services, les scopes, l'injection de dépendances, et j'en passe. En gros, tout ce qui fait d'AngularJS une légère usine à gaz.

Et si l'on mettait du JS partout ?

ParksRec

"Oui alors il faut aussi du JS côté serveur pour faire marcher notre framework côté client"

Malgré l'architecture très classique du MVC, ou celle très spécifique d'AngularJS, certains ont profité du manque d'originalité des frameworks existants jusque là pour trouver de nouvelles façons de faire.

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

C'est à 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 donc d'avoir le même langage partout, il permet aussi de développer une application dite isomorphique : le même code 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.

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 d'être plus difficile à utiliser si vous voulez par exemple changer ses dépendances pour d'autres, comme substituer MongoDB par une autre base de donnés. Un contre-exemple est qu'il permet par contre le choix du framework pour le rendu HTML : AngularJS ou React.

React ? On va voir ça juste en dessous.

Diviser pour mieux coder

Pizza

En utilisant l'image d'une pizza, vous allez vite en comprendre l’intérêt.

Dans la recherche d'un monde web meilleur, un nouveau concept émerge à travers quatre spécifications d'HTML5 qui sont toujours en cours d'écriture : celui des Web Components. La spécification principale est celle des Custom Elements, qui vise à repenser les applications web sous forme de composants, qui sont donc :

  • Personnalisés : La création de nouvelles balises HTML est possible pour représenter nos prorpes 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 de la page web dans lequel il est utilisé.

Parmi les quatre spécifications, seul celle des HTML Templates est terminée, les autres étant encore en cours d'écriture par le W3C. Ce qui n'empêche pas de pouvoir commencer à les utiliser dans la plupart des navigateurs modernes, avec si besoin un polyfill pour les navigateurs ne les supportant pas du tout ou partiellement.

Mais il y a un léger frein à la démocratisation des Web Components : non seulement l'écriture de ces spécifications avance assez lentement, mais les principaux créateurs de moteurs web (Apple, Google, Mozilla) ont surtout 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 raconte donc ce qu'il se passe à ce sujet.

Malgré cela, des développeurs courageux ont voulu construire au plus vite des applications web de cette façon. C'est le cas de Google avec leur bibliothèque 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... tout y est pour faire de bonnes applications web au goût d'aujourd'hui. Même si l'aspect précurseur de la bibliothèque est indéniable, elle n'a pas connu une grande popularité et reste encore très peu citée lorsque l'on parle des "next big things" dans le monde du JavaScript.

Facebook et Instragram, de leur côté, révèlent la bibliothèque React dès 2013 avec une approche radicalement différente du développement "à la Web Components" : one-way data flow, Virtual DOM et écriture des templates en JSX entre autres. Plus une bibliothèque d'UI qu'un framework entier donc, elle apporte pas mal de nouvelles notions ainsi que tout un process de développement front-end à appréhender, mais avec la promesse d'un monde meilleur si vous réussissez à le comprendre.

Les petits nouveaux

Woah

Quand vous utilisez un framework du futur

Google l'a clairement dit : le futur d'AngularJS sera AngularJS. Mais plus précisément, ce sera Angular 2 : une réécriture complète du framework, aux concepts bien plus proches de la mode des Web Components, et qui s'utilise de préférence avec les langages TypeScript, ES2015 ou Dart. À l'heure de l'écriture de cet article, il en est déjà à sa version RC5, ce qui indique une version stable disponible sous peu.

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 AngularJS voire dans React, mais de façon très simplifiée et surtout facile d'accès.

Vue.js se gagne doucement mais très sûrement une certaine popularité dans le domaine concurrentiel des bibliothèques JavaScript dites hype-moderne-chic™, ce qui en fait aujourd'hui une solution fiable et robuste, sans compter aussi les nombreux plugins et ressources disponibles en rapport avec ce dernier comme peut en témoigner la liste Awesome Vue.js.

Next time on the series...

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

ToBeContinued