JavaScript moderne (ES6+) et Asynchrone
1. La renaissance du JavaScript (ES6)
Créé en 10 jours en 1995 par Brendan Eich pour le navigateur Netscape, le
JavaScript (qui n’a absolument rien à voir avec le langage Java) a longtemps
été considéré comme un “langage poubelle” instable, utilisé uniquement
pour faire clignoter du texte ou faire tomber des flocons de neige sur les
blogs.
En 2015, le comité de standardisation ECMA publie la version ES6
(ECMAScript 2015). C’est une révolution absolue. Le JS devient un langage
professionnel, robuste, orienté objet moderne, et dominant le marché
mondial.
L’évolution de la syntaxe est radicale : - La mort de var : Historiquement, la
déclaration de variable avec var avait un comportement de portée (scope)
délirant et imprévisible. ES6 introduit let (pour les variables mutables de
portée de bloc) et const (pour les variables immutables). Dans le code
moderne, on utilise 90% de const, 10% de let, et 0% de var. - Les
Fonctions Fléchées (Arrow Functions) : Syntaxe ultra-courte const somme
= (a, b) => a + b;. Outre la concision, elles règlent le cauchemar historique
du comportement erratique du mot-clé this (le contexte lexical). - Le
Destructuring : Possibilité d’extraire élégamment une donnée précise d’un
énorme objet JSON en une ligne : const { nom, age } = utilisateur; plutôt
que const nom = [Link];.
2. Le moteur JavaScript : Le Monothread
Pour comprendre l’Asynchrone, il faut d’abord comprendre le drame
fondamental de l’architecture du JavaScript. Les langages comme Java, C++
ou Python peuvent faire du “Multi-threading” natif : si un calcul est lourd, ils
créent des processus parallèles sur les différents cœurs du processeur.
Le JavaScript est strictement “Single-Threaded” (Monothread). Il n’a
qu’un seul tuyau d’exécution (la Call Stack ou Pile d’exécution). Il ne peut
faire qu’une seule et unique chose à la fois. Le problème du web, c’est le
temps réseau. Si le JS doit interroger une base de données météo au Japon
(ce qui prend 3 longues secondes de délai de latence), et qu’il le fait de
façon “Synchrone” (bloquante), le fil d’exécution s’arrête. Conséquence
gravissime : toute l’interface graphique du navigateur “gèle” (Freeze)
complètement pendant 3 secondes. Le clic du bouton ne marche plus, le
défilement de la page s’arrête. C’est inacceptable pour l’utilisateur.
2.1 La boucle d’événements (Event Loop)
Pour ne jamais geler l’interface graphique, le JS contourne son handicap
monothread par l’Asynchronisme basé sur les événements.
Lorsque le JS rencontre une tâche chronophage (réseau, minuterie, accès
disque), il ne la fait pas lui-même. 1. Il “sous-traite” (délègue) la tâche à des
travailleurs de l’ombre en arrière-plan : les Web APIs (des moteurs
programmés en C++ fournis par le navigateur). 2. Le fil principal JS continue
d’exécuter la suite du code sans attendre. L’interface reste fluide. 3. Quand
le travailleur de l’ombre au Japon a enfin reçu la météo (3 secondes plus
tard), il dépose la réponse (un Callback) dans une “File d’attente” (Task
Queue). 4. Le surveillant perpétuel du système, l’Event Loop, vérifie que le
fil principal est bien libre. S’il est libre, l’Event Loop prend le Callback dans la
file d’attente et le jette sur le fil principal pour qu’il soit exécuté.
Cette architecture magistrale permet à NodeJS (le JS côté serveur) de traiter
des dizaines de milliers de requêtes web simultanées sur un seul petit cœur
de processeur, écrasant les serveurs classiques multi-threadés (comme
Apache) en termes de gestion de flux.
3. L’évolution de l’Asynchrone : De l’enfer au paradis
L’idée est géniale, mais comment écrit-on ce code Asynchrone ? Trois
générations de syntaxe se sont succédées.
3.1 La Génération 1 : L’enfer des Callbacks (Callback Hell)
Dans les années 2000 (l’ère jQuery/AJAX), on passait une fonction à
l’intérieur d’une autre fonction pour dire “Quand tu as fini de chercher
l’utilisateur, lance cette fonction”. Si l’on devait faire 4 requêtes réseau
successives (Chercher le client, puis avec son ID chercher sa commande,
puis avec la commande chercher le produit…), on imbriquait 4 fonctions les
unes dans les autres. Le code glissait vers la droite de l’écran en formant
une pyramide atroce (Le Pyramid of Doom ou Callback Hell). C’était illisible
et le traitement des erreurs (try/catch) était impossible.
3.2 La Génération 2 : Les Promesses (Promises - ES6)
En 2015, l’invention majeure : L’objet Promise. C’est un objet mathématique
qui représente “une valeur qui n’est pas encore là, mais qui finira par arriver
un jour”. Un reçu de commande au fast-food. La Promesse possède 3 états
stricts : - Pending (En attente). - Fulfilled (Succès de la requête). - Rejected
(Échec, ex: le wifi a coupé).
La promesse s’écrit de façon verticale et chaînée grâce aux méthodes
.then() (si succès) et .catch() (si échec). Fini la pyramide de la mort, le
code est plat et lisible, et l’erreur de 4 requêtes réseau enchaînées est gérée
par un seul et unique .catch() géant à la fin. La fonction reine du web
moderne pour faire du réseau (L’API fetch()) renvoie par défaut une
Promise.
3.3 La Génération 3 : Async / Await (ES8)
En 2017, la syntaxe atteint sa perfection sémantique (empruntée au langage
C#). L’objectif est d’écrire du code asynchrone qui ressemble visuellement à
du code synchrone classique, pour rassurer le cerveau du développeur.
En ajoutant simplement le mot-clé async devant une fonction, on lui donne le
pouvoir magique d’utiliser le mot await à l’intérieur.
async function afficherMeteo() {
try {
const reponse = await fetch('[Link]
const data = await [Link]();
[Link]("La température est", [Link]);
} catch (erreur) {
[Link]("Erreur réseau");
}
}
C’est une illusion d’optique géniale. Le mot await dit littéralement au fil
d’exécution : “Mets cette fonction en pause ici. Sors de la fonction, va faire
vivre le reste du site. Ne reviens à la ligne 4 que le jour où la donnée réseau
aura enfin répondu au serveur.” Le code est lisible par un humain, sans
callbacks, avec une gestion d’erreur classique, tout en gardant 100% de la
performance non-bloquante asynchrone.