Résoudre le call­back hell — Javas­cript 102

Après la mise en place, il est peut-être temps de faire un premier script. J’ai tenté un petit script que j’ai fait la veille en ruby : lister toutes les images dans une hiérar­chie de réper­toires et faire un gros fichier Json qui réca­pi­tule les diffé­rentes tailles.

Faire un petit fichier outil CLI à l’aide de comman­der.js : un call­back. Lister les fichiers d’un réper­toire : un call­back. Lire les exif : un call­back. Écrire dans un fichier JSON : un call­back.

Bon, lire et écrire peuvent se faire en synchrone sans call­back – et dans mon cas précis ça ne chan­ge­rait proba­ble­ment rien – mais je suis là aussi pour apprendre comment faire pour plus tard dans cet écosys­tème.

Une hiérar­chie de quatre fonc­tions de rappel pour ce qui m’a pris 5 à 10 lignes tout mouillé en Ruby, ça me fait mal. J’avoue, je suis presque surpris que la trans­for­ma­tion en JSON ne me demande pas un call­back.

Me voici en plein call­back hell. Le problème est connu. J’ai bête­ment pensé qu’on me donne­rait une solu­tion rapi­de­ment, un outil ou un usage à suivre.

On me pointe vers les promesses ES2015 mais l’API Node et tous les modules en ligne conti­nuent à utili­ser des call­back. Sérieu­se­ment, personne n’a cher­ché à présen­ter l’API Node direc­te­ment en promesses ?

C’est donc à moi de trans­for­mer chaque méthode ou chaque module pour qu’il utilise des promesses. Promi­sify semble être la baguette magique pour ça. À partir de là il suffit de conver­tir chaque module pour enchaî­ner des promesses (atten­tion aux écueils).

Fran­che­ment ça reste assez moche. Des gens biens me pointent vers les systèmes à base de géné­ra­teurs (je recom­mande la lecture de ce lien) et le module co. Le code résul­tant est déjà bien plus lisible malgré les arti­fices.

On me rappelle alors les async / await (là aussi, je recom­mande la lecture). Je crois que c’est seule­ment main­te­nant, après cette explo­ra­tion, que je comprends l’in­té­rêt et le fonc­tion­ne­ment. Parfait, si ce n’est qu’il faut choi­sir presque au hasard entre trois plugins diffé­rents pour ajou­ter la fonc­tion­na­lité à Babel.

Atten­tion, ce n’est pas magique. Il faut se rappe­ler que ce n’est qu’une surcouche aux promesses, et il y a quelques écueils (lien indis­pen­sable si vous comp­tez utili­ser async/await) à bien connaitre là ici aussi, entre autres pour ne pas perdre les excep­tions dans un trou noir.

Je me retrouve avec un code qui a l’air rela­ti­ve­ment élégant mais la réalité me rattrape : Visi­ble­ment quasi aucun code en produc­tion ne fonc­tionne ainsi. Une majo­rité des gens utilisent encore des call­backs, les autres se sont conten­tés des promesses. Est-ce une bonne idée de déjà viser les async/await ?

Il reste aussi que j’ai l’im­pres­sion de retrou­ver le mode multi-tâche coopé­ra­tif de Micro­soft Windows 3.1 en moins bien inté­gré. Je ne vois aucune raison pour que la biblio­thèque stan­dard m’im­pose des call­backs, des promesses ou des async/await à tout bout de champ plutôt que de gérer ça en interne.

L’OS sait déjà passer à un autre proces­sus quand mon programme est en attente d’une i/o. Si la machine virtuelle du langage veut gérer plusieurs fils d’exé­cu­tion en interne pour opti­mi­ser le proces­seur, qu’elle le gère elle-même via l’API mise à dispo­si­tion. C’est à elle d’iden­ti­fier que je veux ouvrir un fichier et de savoir qu’elle peut favo­ri­ser un autre fil d’exé­cu­tion en atten­dant que le disque me remonte la donnée. Je trouve ahuris­sant que ces méca­nismes débordent sur mon code et le complexi­fient ainsi.

Oui, les promesses ne servent pas qu’à gérer la lenteur des i/o et faire coopé­rer les diffé­rents fils d’exé­cu­tions de la machine virtuelle V8 mais c’est quand même pour ça qu’on me les impose partout dans l’API de Node.js. Ça en devient même un style de program­ma­tion et les modules proposent des call­backs partout et pour tout (à vue de nez, y compris là où ça n’a pas vrai­ment de sens, à mon humble avis par mime­tisme).

Promesses, async, call­backs… J’adore tous ces concepts, mais quand j’en ai besoin moi, pas pour compen­ser les choix d’ar­chi­tec­ture du moteur sous-jacent.

Javas­cript a énor­mé­ment évolué, dans le bon sens. Côté syntaxe ES2015 et suivant donnent un résul­tat qui m’at­tire beau­coup. Le fonc­tion­ne­ment et l’API de Node.js me semblent pour l’ins­tant gâcher tout ce résul­tat. Un beau langage avec un boulet aux pieds.