Histoire, écosystème et gouvernance

Node.js n’est pas un langage de programmation. Ce n’est pas non plus un framework JavaScript. Node.js est un environnement d’exécution JavaScript.

La différence entre ces trois désignations peut sembler subtile, futile voire inutile, mais le terme "environnement" est la véritable nature de Node.

Exécuter du JavaScript côté serveur n’est pas une révolution. Netscape Enterprise Server s’y est déjà essayé au milieu des années 1990, juste après son introduction dans le navigateur web Netscape Navigator.

En 1997, la société Netscape s’est attelée à créer Rhino (www.mozilla.org/rhino/), un environnement d’exécution JavaScript tournant sous Java disponible sous licence libre. C’était un des projets liés à la réécriture de Netscape Navigator en Java. Si la société a depuis fermé ses portes, Rhino a entraîné l’émergence de projets utiles aux développeurs web.

Entre-temps, le langage JavaScript évolue, le Web 2.0 émerge des cendres de la première bulle Internet et d’autres initiatives voient le jour dans les années 2000 comme APE (Ajax Push Engine, ape-project.org/). Elles mettent également en œuvre JavaScript côté serveur. JavaScript était surtout un choix logique de partage de code entre client et serveur pour Comet, le précurseur des WebSockets.

Node représente un environnement d’exécution (runtime), un ensemble d’API JavaScript ainsi qu’une machine virtuelle (VM) JavaScript performante (parseur, interpréteur et compilateur) capable d’accéder à des ressources système telles que des fichiers (filesystem) ou des connexions réseau (sockets).

Typiquement, une personne développant en Node écrit du code se basant sur les API à disposition. Ce code est lu par le runtime Node, qui le transmet à la VM JavaScript. Enfin, cette dernière traduit le programme en langage machine (bytecode) avant que le programme soit effectivement exécuté par le processeur.

Pour comprendre comment Node a opté pour cette approche, retournons en 2009, lorsque son créateur Ryan Dahl cherche à résoudre élégamment un problème de performance de programmation.

En 2006, Ryan Dahl est un étudiant américain en troisième année de doctorat de mathématiques. Son but initial était de devenir professeur dans cette matière, mais il prend la décision de ne pas terminer sa thèse et d’entreprendre un voyage au Chili.

Alors qu’il cherche à effectuer des petits boulots, il y rencontre une autre personne développant des sites web. Ruby on Rails connaît un succès grandissant et attire son attention. Alors que Ryan envisage d’utiliser Rails, il découvre avec horreur la lenteur du framework et cherche à en découvrir les causes.

Ryan débute alors sa quête des applications web performantes et découvre Mongrel, un serveur HTTP écrit en Ruby. Il est séduit par deux choses :

La quête initiale le dirige alors vers la possibilité de créer un serveur web non bloquant ; en d’autres termes, un serveur capable, dans un même processus, de traiter d’autres requêtes en attendant de renvoyer la réponse initiale.

Nous sommes alors en 2008 et le site de partage de photos Flickr innove avec un nouveau système de téléversement d’images : une barre de progression représentant le statut du téléversement remplace alors la page figée – effet inhérent à l’envoi de fichiers depuis un formulaire HTML.

C’est le déclic pour Ryan : bien que Mongrel ait déjà un plug-in pour cette fonctionnalité, il souhaite simplifier davantage le travail pour les développeurs. Il reproduit le mécanisme avec succès en C. Les développeurs web jugeant la solution trop complexe, Ryan tente la même approche avec d’autres langages, comme Python, Lua ou même Haskell. Il se heurte au sempiternel problème des ressources bloquantes des différents interpréteurs.

Le deuxième déclic se produit en janvier 2009, lorsque JavaScript émerge dans une discussion entre développeurs. Eurêka ! La machine virtuelle JavaScript V8 de Google a été libérée en open source depuis quelques mois et Apple, Microsoft, Mozilla et Google se livrent à une course à la performance de leurs machines virtuelles respectives. En ligne de mire, il faut rendre la navigation sur mobile et sur ordinateur plus rapide et moins gourmande en ressources.

Ryan admet que JavaScript dispose des caractéristiques idéales, même s’il n’est pas un adepte du langage : fonctions anonymes, closures et l'event loop (dans le DOM en tout cas). Il manque juste aux machines virtuelles JavaScript la capacité d’accéder à des sockets, au système de fichiers et à d’autres fonctions système.

Ryan quitte alors son travail, s’inspire de ses travaux de modules non bloquants pour Nginx et s’affaire pendant six mois à marier JavaScript, V8 et l’environnement du système d’exploitation. De ses efforts naît Node.js.

Il présente alors officiellement son travail (gist.github.com/ry/a3d0bbbff196af633995 et www.youtube.com/watch?v=ztspvPYybIY) qui suscite l’enthousiasme et attire l’attention.

L’entreprise américaine Joyent l’embauche à plein temps pour continuer le développement de Node. Ils pressentent que cet outil répondra à leurs projets de datacenter et d’hébergement. Node et sa communauté se constituent et continuent leur chemin depuis lors ; pour une simple affaire de barre de progression et une obsession pour la perception de rapidité.

En 2018, l’avenir de Node est au beau fixe avec plus de 2 000 contributeurs et plus de 782 000 modules publics hébergés sur le registre npm.

La tension et l’attention autour de JavaScript sont énormes en 2009. La mode du tout Ajax et des mashups s’est estompée, mais une chose en est ressortie : JavaScript n’a plus à rougir ni à être relégué au rang de sous-langage. Les initiatives JSLint, CommonJS et les good parts de Douglas Crockford sont pour beaucoup dans la création de code élégant.

D’un autre côté, les entreprises développant des navigateurs web se livrent à une féroce compétition d’optimisation. Google, Mozilla et Apple ont besoin de navigateurs rapides pour améliorer leurs parts de marché sur les ordinateurs, mais aussi les téléphones et tablettes. On peut considérer que JavaScript est à cette époque le langage de programmation bénéficiant du plus grand investissement financier et humain en R&D.

La communauté JavaScript accueille avec ferveur Node lors de la conférence JSConf Europe en 2009. Elle contribue à son amélioration et à la création d’un écosystème de modules réutilisables.

Il faudra attendre la création de npm au tout début 2010, qui a pour but d’héberger des modules Node et de faciliter leur installation. Dès lors, une simple commande suffit pour inclure dans nos projets du code écrit par d’autres personnes.

npm devient une pierre angulaire, à tel point qu’il est inclus dans l’installation de Node à partir de la version 0.6.3 en novembre 2011. La communauté Node fait le reste du travail en constituant un écosystème de modules riches et variés : frameworks web, pilotes de bases de données, serveurs HTTP, serveurs WebSockets, préprocesseurs CSS, CoffeeScript, parseurs, proxy, serveurs de log, modules de tests, langages de templating, etc.

Malgré ses défauts de jeunesse, Node réussit le tour de force de la performance. La recette de l’accès non-bloquant a-t-elle fonctionné ? À en croire les personnes ayant migré vers Node pour ces raisons, la réponse est "oui".

Il est tentant de vouloir suivre un chemin populaire, d’adopter le dernier outil ou framework à la mode.

J’ai pourtant envie d’écrire qu’il n’est pas forcément nécessaire de passer à Node.

Si votre équipe dispose déjà de fortes compétences, d’aisance et de productivité dans un autre langage, il n’y a pas de raison de passer à Node. Cette équipe a tout intérêt à capitaliser sur ses connaissances pour être efficace et minimiser la dette technique de ses applications.

L'offre logicielle est également à prendre en compte : CMS, systèmes e-commerce ou autre application prête à l’emploi que la communauté Node n’offrirait pas à ce jour.

Un facteur important et souvent oublié est l’acceptation et la compréhension de l’utilisation de Node par une équipe. Il est alors plus intéressant de comprendre les raisons d’un blocage que de forcer ou d’imposer cet outil. La solution peut être simple : balayer des idées reçues, animer un atelier technique ou inviter un·e expert·e pour répondre aux questions, interrogations et utilité d’un tel changement.

Node ne vous aidera probablement pas si vous cherchez à réaliser des choses contre-productives pour JavaScript. Je pense à des opérations mathématiques de très haute précision, de l’apprentissage automatique avancé (machine learning) ou du calcul scientifique poussé par exemple. Il est difficile d’égaler la richesse fonctionnelle de Python et de ses bibliothèques (SciPy, NumPy, scikit-learn) ou la finesse de gestion de mémoire de C++ ou de Rust.

Node ne résout pas les problèmes par magie. Cela reste avant tout une affaire de compétences et d’expérience.

Node est un choix de langage principal tout à fait viable.

Il est préférable que ce choix soit une volonté partagée entre membres d’une équipe, qu’il soit motivé par ce que Node apporte et simplifie pour vous.

Node est tout désigné pour créer des applications à nombreuses actions concurrentes ; autrement dit, dès qu’une application ou programme fait appel à des accès réseau, aux fichiers ou au système.

Node est également adapté pour transformer des flux importants de données en économisant la mémoire. Cela concerne aussi bien la lecture de fichiers CSV, JSON ou XML de plusieurs gigaoctets.

Le mécanisme de modules de Node encourage à respecter le principe de responsabilité unique. Nos applications seront modulaires et autonomes au lieu d’être lourdes et monolithiques.

Les développeurs et développeuses verront dans Node leur compagnon idéal pour compiler, générer, assembler et minifier leurs applications front-end. Le bénéfice évident est le partage d’un outillage CSS, JavaScript et HTML entre équipes, par projet.

Conséquence directe, Node offre l’opportunité d'unifier vos équipes de développement front-end et back-end. Il devient un environnement commun, un langage partagé entre les individus, qui peuvent se focaliser sur des fonctionnalités quelle que soit la cible, aussi bien pour le Web, un serveur ou une API.

Node est un environnement adapté à l’apprentissage et l’amélioration de nos connaissances en JavaScript. On peut désormais penser sur du long terme, en se souciant moins de devoir supporter de vieilles versions de Node ou de navigateurs web tant il est facile de passer d’une version du langage à une autre.

Les développements initiaux de Node sont en majorité financés par Joyent, à commencer par l’embauche de Ryan Dahl.

L’écosystème des acteurs se diversifie avec le temps. Avec de nouveaux employés chez Joyent, puis avec des contributeurs externes qui voient un avenir prometteur dans le projet. S’ensuivent des entreprises privées comme IBM ou PayPal, qui sponsorisent le projet ou le salaire de contributeurs.

Node a connu une forte croissance depuis 2012. La gouvernance du projet open source a été effectuée par la société Joyent. Ses agissements et la direction donnée au projet ont régulièrement fait grincer des dents, notamment en entretenant un climat d’incertitude sur la pérennité à long terme, si Node venait à ne plus répondre aux intérêts commerciaux de Joyent.

Des voix se sont élevées pour critiquer l’absence d’une organisation ouverte, commercialement neutre et ouverte aux contributeurs externes. Cela a mené à la création d’un fork de Node : io.js.

La réconciliation entre les projets Node et io.js a sérieusement assaini les rapports de gouvernance. Cela a également apporté une direction et des opportunités plus claires de contribuer à la direction du projet.

Depuis juin 2015, la gérance du projet est garantie par plusieurs entités :

Le Technical Steering Committee (github.com/nodejs/TSC) réfère ses intentions d’actions au Board. Son fonctionnement est régi par une charte co-signée avec ce dernier. Ce comité est composé de contributeurs et de collaborateurs individuels.

À l’inverse, le Board géré par la Node.js Foundation est composé essentiellement d’acteurs de l’industrie – dont Google, IBM, Joyent et PayPal. Certains membres émérites ou choisis par le Board (github.com/nodejs/board) sont des individus agissant en leur nom propre.

Les participant·e·s du TSC ont une obligation de régularité, de présence et de vote aux différents rendez-vous organisés par le comité. Ce mécanisme a été choisi afin de préserver la vitalité du projet.

Un quota d’appartenance à une même entreprise a été mis en place pour maintenir une diversité de représentation. Dans une moindre mesure, ce mécanisme vise à réduire les possibles conflits d’intérêts ou une prise en otage du projet comme a pu le faire Joyent avant l’apparition de ce modèle de gouvernance.

Nous venons d’en apprendre davantage sur les origines de Node, les différentes parties prenantes dans son développement, mais aussi sa philosophie – de conception, de distribution et d’évolution.

Nous allons voir dans le prochain chapitre comment installer un environnement fonctionnel pour développer et exécuter des programmes Node.