Après l'exécution de JavaScript et un point sur le langage et ses alternatives, c'est donc le moment d'étudier l'utilisation concrète du langage dans les prochains articles.

Et pour celui là, ce sera à propos des bibliothèques - pas celles d'une marque suédoise, non - mais ça vous le saviez déjà si vous avez lu le titre de cet article.

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

🌀 La fièvre du DHTML et de l'AJAX

DHTML ou "Dynamic HTML", on en a déjà parlé dans le premier article de cette série. C'est un nom apparu dans les années 90 / 2000, en même temps que le JavaScript, et qui désignait un peu tout et rien à la fois. On disait surtout "Je fais du DHTML" pour dire "Je dynamise ma page web avec du JavaScript" vu que c'était désormais possible grâce à ce dernier, ainsi qu'avec l'apparition du DOM qui sert à manipuler le contenu et la forme d'un document HTML ou XML, notamment depuis JavaScript (car DOM n'est pas exclusif à ce dernier pour autant).

Intégré entre 2006 et 2007 aux principaux navigateurs web de cette époque, XMLHttpRequest (parfois abrégé en XHR) allait aussi faire une petite révolution dans l'utilisation du langage.

Cette API accessible en JavaScript permet donc d'envoyer des requêtes HTTP à un serveur et d'en recevoir du contenu de tout type (pas seulement du XML malgré son nom), et ce surtout après que la page web ait déjà été chargée. D'où le nom que l'on a donné à son utilisation : AJAX, pour "Asynchronous JavaScript and XML".

🔁 while (true) { new JSLibrary(); }

Avant, bien avant l'arrivée des langages se transpilant en JavaScript, l'envie de rendre l'utilisation du JavaScript plus accessible était déjà présente. Surtout lorsque, par exemple, les implémentations du CSS, du DOM ou encore même de XMLHttpRequest n'étaient pas exactement les mêmes entre les différents navigateurs web, demandant souvent d'écrire des morceaux de code différemment selon le navigateur de l'utilisateur...

C'est entre 2005 et 2006 que naquit les mastodontes des bibliothèques JavaScript : jQuery, Prototype.js, MooTools, script.auculo.us, Yahoo UI, Dojo... Certaines existent encore aujourd'hui et restent grandement utilisées, jQuery en étant sûrement le meilleur exemple.

Ces bibliothèques ont plusieurs objectifs communs pour pallier aux problématiques de l'époque : uniformiser l'utilisation du DOM à travers les navigateurs, simplifier la requête de données via XHR, créer rapidement des interfaces similaires aux applications de bureau, ajouter des notions "orienté objet" à JavaScript comme les classes ou l'héritage... ainsi que quelques extras comme l'animation d'éléments HTML, étant donné que CSS3 était encore soit inexistant, soit encore trop jeune à l'époque.

L'arrivée d'HTML5 et CSS3 ne fera qu'amplifier ce phénomène. Les connexions peer-to-peer (WebRTC), les Web Sockets, WebGL ou encore la géo-localisation : toutes ces nouvelles fonctionnalités désormais accessibles ont irrémédiablement mené à la création de bibliothèques pour, encore une fois, faciliter leur utilisation et prendre en compte les différences d'implémentation entre le navigateurs.

L'évolution d'HTML, CSS et JavaScript ont également mené à l'extinction de nombreuses bibliothèques, qui n'avaient plus la moindre utilité car les problématiques auxquelles elles répondaient ont tout simplement disparues.

Grâce aux bibliothèques, tirer profit des possibilités de JavaScript est plus rapide et plus facile, mais avec la contrepartie de parfois oublier l'utilisation classique du langage, mais surtout d'être de plus en plus dépendant d'elles. Trop peut-être ?

⛈️ L'effusion inarrêtable

À l'époque, faire bouger et changer le contenu d'une page HTML est tellement incroyable que l'on a rapidement créé une des tonnes de bibliothèques pour la moindre chose qu'il soit possible de faire : des boutons, menus, diaporamas, fenêtres modales, lecteurs vidéos, formulaires, et j'en passe.

Une grande part de ces bibliothèques se basent d'ailleurs sur d'autres pour fonctionner, le cas le plus connu étant les plugins jQuery. L'inconvénient, une fois encore, étant que votre page est dépendante de jQuery ainsi que de nombreux plugins.

Aussi, devant l'infinité de bibliothèques répondant à un même besoin, il est devenu difficile de choisir la bonne : est-elle fiable, populaire, bien documentée, toujours mise à jour ? Ou peut-être également que l'utilisation d'une bibliothèque n'est pas si essentielle pour accomplir ce que vous voulez faire.

Aujourd'hui, la tendance est plutôt à la réalisation de bibliothèques bien plus raisonnables : on évite d'utiliser jQuery ou d'autres lourdes dépendances si possible, on fait attention aux performances et à la compatibilité mobile notamment, etc.

📋 Petite sélection

Bien sûr, tout n'est pas noir dans l'océan des bibliothèques JavaScript, et en voici une petite sélection personnelle de certaines qui pourraient avoir un intérêt pour beaucoup de projets.

Outils

• DayJS et Luxon sont très utiles pour la manipulation ou l'affichage de dates.
• Modernizr permet de détecter les fonctionnalités supportées (ou non) par le navigateur web d'un visiteur, afin de réagir en conséquence si votre site ou application web a besoin de fonctionnalités spécifiques pour son bon fonctionnement.

Affichage

• D3.js est une référence dès que vous voulez créer des schémas ou représentations graphiques plus ou moins complexes de tout type de données.
• Mapbox GL JS est un excellent moyen d'afficher des cartes personnalisées (basées sur OpenStreetMap par exemple), qu'elles soient vectorielles ou bitmap, avec l'usage si possible de WebGL pour des performances ultimes.
• three.js et BabylonJS restent à l'heure actuelles les deux plus grosses bibliothèques pour utiliser facilement WebGL et réaliser des choses en 3D.

En définitive, il est bien sûr possible de trouver de bonnes bibliothèques. Unheap propose une sélection de plugins jQuery intéressants, et Javascripting semble être un répertoire ultime des principales bibliothèques existant à l'heure actuelle, avec un indice de popularité sur chacune d'entre elles.

L'essentiel à retenir étant donc là : s'en servir si besoin, oui, en abuser parce que c'est possible, non. Et comme tout choix technologique, il faut faire très attention à ce que l'on choisit pour éviter d'être dans le pétrin lorsque l'on se rends compte qu'un choix était finalement mauvais.

🔜 Next time on the series...

Bien souvent, pour concevoir un site ou une application web, il nous faut de quoi structurer un minimum la chose à l'aide d'un framework plus ou moins complet. C'est ce qui est expliqué dans le prochain article !