Le 8 novembre 2009 � la JSConf de Berlin, Ryan Dahl d�voilait son prototype Node.js en version 0.1.16.

Son postulat de d�part �tait que l'usage d'une boucle d��v�nements (event loop) associ�e � une gestion des entr�es/sorties non bloquantes (non-blocking I/O) est bien plus efficace pour programmer un serveur que d'utiliser un thread par client connect� en se basant sur la diff�rence d'architecture opposant nginx � Apache.

La boucle d'�v�nements tient bien mieux la mont�e en charge, et permet d'utiliser plus efficacement les ressources de la machine.

Son prototype a �t� adopt� tr�s rapidement par l'industrie du web am�ricaine, pour �tre aujourd'hui le coeur de l'�cosyst�me JavaScript et la composante principale des syst�mes d'information de fournisseurs de services tr�s connus comme PayPal, Twitter ou Netflix.

Qui est Ryan Dahl

Ryan Dahl a grandi aux USA � San Diego, il n'est pas un informaticien de formation. Initialement il poursuivait un PhD en math�matiques (�quivalent US du Doctorat) � l'universit� de Rochester.

Jugeant les maths trop difficiles � appliquer au r�el, il laissait tomber ses �tudes pour partir en Am�rique du Sud, o� il fut embauch� comme d�veloppeur web sur une stack � base de Ruby on Rails dans une entreprise qui vendait des snowboards.

Puis il partit en Allemagne accompagnant sa petite amie, o� il commen�a � fr�quenter les conf�rences sur Rails et travailla en tant qu'ind�pendant sur diff�rents modules pour le serveur web Nginx.

Fin 2008, � la sortie du moteur JavaScript V8 de Google il commen�a � jouer avec, et disposant de temps libre du fait d'une activit� professionnelle en dent de scie, il se mit en t�te de d�velopper un prototype de plateforme serveur utilisant V8 et appliquant les principes appris de Nginx .

En l'espace de 6 mois, Node.js �tait n�.

Jusqu'en 2012, Ryan Dahl travailla professionnellement sur le d�veloppement de Node.js au sein de la soci�t� Joyent � San Francisco. Puis il d�cida de mettre un terme � cette activit� consid�rant que Node.js �tait devenu ce qu'il voulait qu'il soit au d�part et que le langage Go qui venait de sortir des fours de Google �tait plus adapt� pour le d�veloppement de serveurs.

Au cours des ann�es suivantes il disparut des radars puis rejoint notamment le Google AI Residency Program, int�ress� par les d�veloppements r�cents en machine learning.

Ryan Dahl est r�apparu aux yeux du monde le weekend dernier ... � la JS Conf de Berlin pour une pr�sentation nomm�e "Design Mistakes in Node", ce qui peut �tre traduit en "Erreurs de conception de Node".

JSConf Berlin 2018

Lors de sa pr�sentation, Ryan Dahl explique qu'il s'est remis � utiliser intensivement Node.js au cours des 6 derniers mois. Pour lui, les langages dynamiques sont les plus adapt�s pour des projets de calculs scientifiques et JavaScript est le meilleur langage dynamique.

Il trouve Node.js sympa � utiliser, mais est g�n� par des erreurs de conception qu'il est impossible de corriger d�sormais, l'�cosyst�me �tant beaucoup trop gros.

Selon Ryan Dahl, Node.js souffre de 10 erreurs de conception (ses 10 regrets)

- Ne pas avoir conserv� les promesses (Promises).

Elles ont �t� ajout�es en juin 2009, et retir�es en f�vrier 2010.

Il jugeait � l'�poque que les promesses ajoutaient un concept suppl�mentaire pour g�rer l'asynchronisme alors que les callbacks �taient disponibles. Il les a retir�s pour conserver une API minimaliste.

Les promesses sont la brique de base n�cessaire � l'impl�mentation de async / await. En retirant les promesses, Ryan Dahl a donc retard� consid�rablement l'arriv�e et la standardisation de async / await, jug�e comme l'abstraction la plus simple et la plus propre pour g�rer l'asynchronisme, et forc� le monde � utiliser des callbacks.

- S�curit�.

Le moteur V8 de Google est un bon bac � sable s�curis� pour l'ex�cution de programmes, mais node fait sauter cette s�curit� en donnant par d�faut l'acc�s � tout le syst�me (syst�me de fichiers, r�seau, etc.).

Par d�faut, un programme node ne devrait pouvoir utiliser que les ressources qu'on lui autorise. Par exemple un linter ne devrait pas pouvoir acc�der au r�seau ni �crire de fichiers sur le disque de l'utilisateur.

En d�finitive, node devrait �tre plus s�curis� par d�faut.

- Le syst�me de build (GYP) est trop complexe.

D�pend de Python et est utilis� pour lier les d�pendances �crites dans d'autres langages (C, C++, etc.) � node.

Il le juge inutilement complexe et pense qu'il s'agit l� de sa plus grosse erreur de conception.

- Le syst�me de build (GYP) aurait pu �tre remplac� par les foreign function interface d�s le d�but.

Deuxi�me regret concernant le syst�me de build, il n'a pas �cout� certains membres de la communaut� qui proposaient une alternative jug�e aujourd'hui meilleure, les foreign function interface (FFI). Il s'agit d'un m�canisme permettant d'appeler des fonctions d'une d�pendance �crite et compil�e dans un langage B depuis un programme �crit et compil� dans un langage A.

L'avantage principal de ce syst�me est qu'il supprime la n�cessit� d'une recompilation de la d�pendance � int�grer.

Quiconque a d�j� utilis� une d�pendance npm n�cessitant une recompilation via node-gyp sous Windows conna�t la douleur r�sultant de ce choix.
La recompilation n�cessite l'installation de Python et de l'environnement de compilation complet (Compilateur C++ de Visual Studio par exemple), tout �a pour utiliser une malheureuse d�pendance npm (le tr�s utilis� browser-sync par exemple ...).

- Le package.json d�finit un module.

En autorisant la fonction require() � inspecter nativement le contenu des fichiers package.json et en incluant npm dans les livraisons de node, il a d�fini npm comme le gestionnaire de packages de facto et donc impos� l'usage d'un fichier package.json pour d�finir un module, ce qui n'�tait pas le cas avant.

Le probl�me de ce choix, c'est que npm est un syst�me centralis� et contr�l� par une entit� priv�e (npm inc) ce qui lui d�pla�t fortement.

-require('somemodule') n'est pas sp�cifique.

Il veut dire par l� que l'usage de la fonction require ne suffit pas � d�finir comment r�cup�rer ce module.

Ce module doit �tre aussi d�fini dans le package.json (dans la propri�t� dependencies) pour d�terminer dans quelle version le module va �tre r�cup�r�.

Ce module existe �galement dans le r�pertoire node_modules/ local au projet, il peut aussi exister globalement sur la machine.

Enfin ce module existe �galement dans la base de donn�es de npm (le registre en fait).

- Le package.json permet de d�finir un r�pertoire comme �tant un module.

L'existence du package.json pour d�finir un module permet l'existence d'un module sous forme de r�pertoire.

Il estime que c'est une abstraction inutile, car elle ne correspond � rien sur le web dans le sens ou une URL d�signe une ressource et pas un r�pertoire. De plus cette abstraction tire avec elle toute sorte d'informations inutiles (la licence, l'URL du d�p�t git, une description, etc. ) lorsque le but est de lier une biblioth�que � une application.

Si les modules �taient obligatoirement un fichier unique, alors il serait possible de g�rer le versionning dans l'URL. Le fichier package.json pourrait �tre supprim�.

- node_modules/ est trop gros.

Le r�pertoire node_modules/ occupe beaucoup trop d'espace sur le disque.

Le principe d'avoir un r�pertoire contenant toutes les d�pendances � l'ext�rieur du code source de l'application, mais � l'int�rieur du r�pertoire du projet (donc de chaque projet) semble s�duisant, mais en pratique, une simple variable d'environnement $NODE_PATH aurait suffit.

Par ailleurs ce fonctionnement d�vie du fonctionnement des navigateurs.

- La possibilit� de ne pas sp�cifier l'extension lors de l'utilisation de require('somemodule').

Mauvaise fonctionnalit�, car rend l'import moins explicite. On ne sait pas s'il s'agit d'un .js, d'un .ts, ou d'autres choses.

Complexifie l'algorithme du module loader qui doit chercher dans tous les cas de figure possibles pour trouver le module � charger (cf le pseudo-code de l'algorithme dans la doc officielle pour se faire une id�e !).

L� encore cela d�vie de la mani�re dont les navigateurs fonctionnent.

- index.js.

Enfin il s'excuse pour l'existence du fichier index.js qui sert de point d'entr�e par d�faut, cr�ant un cas suppl�mentaire pour l'algorithme de r�solution des modules.

Il pensait que ce serait une bonne id�e d'utiliser la m�me convention que pour le html (index.html qui est par convention le point d'entr�e d'un site web).

Cela a ajout� une complexit� inutile, en particulier apr�s le support du package.json qui permet la d�finition du point d'entr�e (propri�t� main).

En conclusion de cette liste de regrets, Ryan Dahl explique qu'il trouve que Node.js est un bon outil et que son probl�me avec se limite en d�finitive avec la mani�re dont node g�re le code source de l'utilisateur.

Il explique ce manque par le fait que son sujet initial �tait de changer la mani�re dont les d�veloppeurs g�raient les I/O, et qu'en se focalisant sur ce probl�me il n'a pas pass� assez de temps sur ce probl�me fondamental de syst�me de modules qui a �t� ajout� apr�s coup parce qu'il en fallait bien un.

Son prototype deno

Ryan Dahl d�finit deno comme un "moteur d'ex�cution TypeScript s�curis� b�ti sur V8" ("A secure TypeScript runtime on V8").

Le code source du prototype est disponible sur GitHub.

Objectifs :

- S�curit�.

Par d�faut, un script ne doit pas avoir les droits d'utiliser le r�seau et d'acc�der en �criture au syst�me de fichier. L'utilisateur du script doit accorder explicitement ces droits via des options d'ex�cution (--allow-net et --allow-write). Cela permet aux utilisateurs d'utiliser des scripts utilitaires �crits par des inconnus (comme des linters) sans se poser de question.

Les fonctions natives du syst�me ne doivent pas pouvoir �tre li�es au moteur d'ex�cution JavaScript. Tout doit passer par un syst�me de message (send et recv). Cela simplifie tout et permet de facilement auditer le syst�me.

Le lien entre le processus deno et V8 est r�alis� au moyen de protobuff.

deno est actuellement �crit en go, mais ce n'est pas forc�ment un choix d�finitif, il envisage �galement de le faire en Rust voire en C++.

L'id�e g�n�rale est donc d'obtenir une s�curit� d'ex�cution comparable � celle du navigateur, mais c�t� serveur. En effet dans votre navigateur vous ex�cutez quotidiennement du code dont vous ignorez totalement la source, mais comme celui-ci est ex�cut� dans un processus qui n'a acc�s � rien cela pose moins de probl�mes de s�curit�.

- simplifier le syst�me de modules.

Aucune compatibilit� recherch�e avec node et le r�pertoire node_modules.

Les imports sont obligatoirement des fichiers sous forme d'URL (relatives ou absolues) :

  
import { test } from "https://unpkg.com/[email protected]/testing.ts" 
import { log } from "./util.ts"

Le code externe est t�l�charg� � la premi�re ex�cution et mis en cache. Il n'est t�l�charg� � nouveau que si l'utilisateur le demande explicitement via le flag --reload.

L'extension du fichier est obligatoire.

On peut "vendorer" ses d�pendances en sp�cifiant manuellement un r�pertoire de cache diff�rent. Par "vendorer", il veut dire utiliser une sorte de r�pertoire node_modules/ si on tient � avoir ses d�pendances externes en local. Avant l'existence de node et des diff�rents outils construits dessus, il �tait courant dans les projets web de cr�er un r�pertoire vendor/ pour y placer ses d�pendances.

- TypeScript out of the box.

Ryan Dahl adore TypeScript. Il est donc support� nativement sans besoin d'aucune configuration. Actuellement son prototype embarque TypeScript 2.8.

TypeScript n'�tant qu'un superset de JavaScript, il est possible d'ignorer totalement TypeScript si on ne l'aime pas. Il suffit de ne pas l'utiliser.

Le support de TypeScript out of the box pose des probl�mes de performances au d�marrage du programme, probablement li�s � la transpilation, mais il pense pouvoir y rem�dier dans un futur proche.

- Livrer un seul ex�cutable avec un minimum de d�pendances.

Pardonne-moi cher lecteur, j'avoue humblement ne pas avoir compris du tout cette partie. Il liste les d�pendances utilis�es par son binaire deno via l'utilitaire ldd, mais la m�me commande appliqu�e � node donne � peu pr�s le m�me r�sultat. Je ne vois donc pas bien en quoi il s'agit d'une am�lioration, si quelqu'un de plus cal� que moi sur le sujet lit la news je serais heureux de l'amender !

- Utiliser les avantages de 2018.

Utilisation d'un bundler pour convertir la source et ses d�pendances en un livrable unique.

Actuellement les projets node sont g�n�ralement d�ploy�s et ex�cut�s tels quels depuis leur source, il n'y a pas de phase de transformation en livrable contrairement aux projets frontend. Ryan Dahl semble appr�cier le bundler Parcel.

Lors de l'�criture de Node.js, beaucoup des API (comme http) ont d� �tre �crites enti�rement. Ce n'est plus n�cessaire actuellement et il veut utiliser l'existant en Go, Rust ou C++ pour g�rer cette partie de l'API.

- Buts divers.

Ryan Dahl pense qu'une promesse non g�r�e (une promesse sans clause catch) devrait tuer le processus imm�diatement � l'ex�cution, ce qui n'est pas le cas dans node.

Il pense que l'API de deno devrait se conformer � l'API des navigateurs sans red�finir son propre nommage. Le code produit serait donc beaucoup plus facilement compatible avec les navigateurs.

Sources :
- Vid�o de sa pr�sentation � la JSConf 2018 de Berlin (slides).

- Vid�o de sa pr�sentation de Node.js � la JSConf 2009 de Berlin (slides).

- Interview de Ryan Dahl par le podcast Mapping the Journey dat�e du 31 ao�t 2017.
- "I hate almost all software", site de Ryan Dahl, octobre 2011.

Et vous ?

�tes-vous d'accord avec l'analyse de Ryan Dahl � propos des probl�mes de Node.js ?
Comptez-vous suivre l'�volution de son prototype ?
Pensez-vous que deno conna�tra le m�me destin que node ?