Le 2 juin 2018 le créateur de NodeJS a débarqué sur la scène de la JSConf avec un maximum de stress. Il ne supporte plus NodeJS et commence à parler de Deno. Mais qu’est-ce qui ne va pas avec NodeJS ? Et pourquoi Deno serait notre sauveur à tous ? Aujourd’hui je te présente en avant-première quelque chose qui risque d’être dans tous les coins d’Internet dans le futur.
Da Vinci Code
Ryan Dahl est un type brillant. Il y a dix ans de ça, en 2009, il a débarqué à la même JSConf avec autant de stress. Il était là pour présenter un side project à lui : NodeJS. Tu faisais quoi toi y’a dix ans ? Moi je faisais du Symfony 1.4 et je pensais que j’étais le plus grand hacker du monde. Bref, le bougre est pas mauvais. Mais malgré tout, durant cette fameuse conf du 2 juin 2018, il n’a fait que s’auto-flageller. On aurait dit le Da Vinci code la scène. Franchement à 12:55 de la vidéo quand il se met à parler des node_modules j’ai cru qu’il allait craquer. Au passage il y a une belle leçon ici. Malgré son talent et ses succès, il ne fait qu’insister sur ces erreurs.
T’as eu la flemme de regarder les 25 minutes de la conf mais tu veux savoir c’est quoi les problèmes de NodeJS selon Ryan Dahl ? OK je te fais un tour du proprio rapide.
NodeJS et ses problèmes
1 : Promesses tuées dans l’oeuf
À la naissance de NodeJS Ryan a introduit les promesses, à la place des callbacks, pour les enlever aussitôt après. Du coup on se retrouve avec des callbacks partout dans l’API de base de NodeJS et ça vieillit mal. Surtout avec toutes les couches d’abstraction qui ont été faites par la suite pour pallier à ça.
2 : Sécurité faible
Même si le moteur Javascript utilisé par NodeJS (V8) est sécurisé, Node en lui même l’est pas. En fait quand tu lances un node tu as automatiquement accès aux fichiers, à des calls systèmes et la possibilité de lancer des scripts. Le runtime utilisé dans NodeJS ne devrait pas avoir des droits pareils sans restrictions.
3 : Le système de build (GYP) à la dérive
GYP est un outil qui va compiler des add-ons écrits en C ou C++ pour qu’ils puissent être utilisés comme n’importe quels add-ons avec un require dans le code. C’est indispensable au bon fonctionnement de NodeJS. Mais GYP c’est l’enfer. C’est tellement l’enfer que Chrome a arrêté de l’utiliser. Node est le seul utilisateur de GYP aujourd’hui.
4 : Le package.json et NPM indispensable
Le fichier package.json est central au fonctionnement de n’importe quelle application Node. Un require a un accès direct au package.json le rendant d’autant plus indispensable. Et en incluant NPM dans l’équation, Ryan a rendu ce fichier et NPM encore plus indispensable en réduisant par la même occasion la liberté des développeur(euse)s.
5 : Le système de modules et le fameux dossier node_modules
Et ce fonctionnement via package.json qui va télécharger des modules via le require amène un problème encore plus gros. L’extrême complexité de résolution des modules quand tu tapes npm install. C’est un espèce d’énorme algorithme qui va faire 1 milliard de calls pour te télécharger autant de modules et de dépendances de modules que tu vas stocker dans un dossier sans fond.
Heureusement ce jour-là le créateur de NodeJS est pas juste venu s’auto-flageller devant tout le monde. Non il est là avec une solution ! Et cette solution s’appelle Deno.
Deno c’est quoi ?
Deno est un runtime en ligne de commande pour exécuter du code Javascript et Typescript. Comme NodeJS, Deno est construit sur le moteur Javascript de Chrome : V8. Il est écrit entièrement en Rust (Nodejs est écrit en C et C++) ce qui promet pas mal de performances. Enfin pour garantir de l’I/O asynchrone l’event loop utilisée est Tokio. C’est celle de Rust, l’équivalent de libuv en NodeJS. Si je te parle chinois, c’est que t’as pas lu mon article sur le fonctionnement de Javascript et je t’invite à le faire.
Deno existe depuis bientôt 1 an. Il est en développement pour le moins intensif. Il a pour objectif de devenir un environnement de développement productif et sécurisé en Javascript avec un support natif de Typescript. Ça ressemble énormément à NodeJS dans l’utilisation. Un NodeJS réécrit en entier avec des technologies moins contraignantes. De base il évite tous les problèmes qu’on ne peut plus résoudre avec NodeJS aujourd’hui. Et bien sûr il y a son lot de nouveautés.
Deno et ses solutions
Deno commence tout de suite par dégager NPM, le package.json et le gros bordel du dossier node_modules. Finies les dépendances, finies les résolutions et place aux ES modules qui sont désormais le seul système de module accepté. Plus étonnant les modules peuvent être appelés via url HTTP ! Ils sont téléchargés et mis en cache indéfiniment. On en reparle dans la partie d’après.
Deno est sécurisé par défaut. Quand tu lances un runtime Deno si tu n’as pas spécifié les droits via un flag dans la ligne de commande tu n’as accès à rien. Pas d’accès au disque, au réseau ou à des opérations sur le système. Ça permet d’avoir plus de contrôle et de ne pas donner à un simple linter le droit de faire ce qu’il veut par exemple.
Il y a d’autres avantages à Deno comme le support natif de Typescript, l’utilisation de son compiler ou encore la compatibilité browser. Je te laisse voir la liste complète ici. Il est temps de mettre nos gros doigts dessus.
Deno en action
Sur Linux un script d’installation est déjà tout prêt pour nous faciliter la tâche.
curl -fsSL https://deno.land/x/install/install.sh | sh
Tu n’as plus qu’à rajouter le chemin du bin dans ta variable PATH via un export et on est bon. Regardons la face du Hello World servi par un serveur HTTP.
import { serve } from "https://deno.land/std@v0.12/http/server.ts";
const body = new TextEncoder().encode("Hello World\n");
const s = serve(":8000");
window.onload = async () => {
console.log("http://localhost:8000/");
for await (const req of s) {
req.respond({ body });
}
};Bon alors déjà si tu fais du Javascript on est d’accord que t’es à la maison avec Deno. On commence par importer via ESModules une libraire de serveur HTTP via une URL. Il est important de préciser que t’es pas obligé d’utiliser des URLs en passant, un path relatif vers un fichier ça marche aussi. Ensuite on utilise TextEncoder côté WebApis pour préparer notre texte. On prépare notre serveur pour le port 8000 et enfin on lance une fonction asynchrone au chargement du script. Cette fonction va itérer sur chaque requête faite au serveur et répondre par Hello World. OK si on lance tout ça qu’est ce que ça donne ?
Plusieurs choses intéressantes se sont produites. La première c’est qu’il va télécharger puis compiler le serveur HTTP et ses dépendances au moment du runtime. Ce qu’il faut savoir c’est que Deno est son propre manager de modules. Tous les modules téléchargés et compilés de cette façon sont mis en cache pour toujours dans Deno. Le seul moyen de re-télécharger ses modules, par exemple pour une mise à jour, est de mettre le flag –reload dans la commande.
En parlant de flag si tu regardes bien après le téléchargement des dépendances Deno demande l’autorisation d’accès au réseau sur le port 8000. C’est le serveur HTTP qui veut un accès au réseau mais comme Deno est un environnement sécurisé il ne peut pas le faire lui-même. On doit valider manuellement pour que le serveur puisse s’installer sur le port 8000 et fonctionner normalement. On peut également ajouter un flag d’autorisation spécifique d’accès au network pour le faire automatiquement.
Tu remarques que cette fois non seulement on a accès au réseau immédiatement, mais en plus on ne re-télécharge pas les modules et ses dépendances car tout a été mis en cache dans la commande d’avant.
Deno et NodeJS dans le futur
Alors on va pas se mentir là tout de suite avec Deno tu vas pas changer le monde. À l’heure où j’écris ces lignes y’a beaucoup de bugs et surtout tu peux pas faire grand-chose avec. Deno n’a pas pour but de tuer NodeJS. NodeJS est un environnement qui fonctionne bien. Il est activement maintenu par des brutes et il sera là pendant encore très longtemps. Cependant Deno propose des solutions aux problèmes de NodeJS. Et sur le papier Deno est un meilleur NodeJS. Et si je t’en parle aujourd’hui c’est qu’une version 1.0 de Deno arrive bientôt.
Au dernier JS Fest notre bon vieux Ryan Dahl a annoncé ses ambitions. Sortir une première version stable de Deno autour de la fin de l’été 2019. Ouais, en gros là tout de suite. Et si cette fameuse première version sort tous les hackerman du monde vont se jeter dessus comme des pitbulls sur un bout de viande. Les modules et autres helpers vont fleurir et vont rendre Deno de plus en plus attrayant au fil du temps. Et je pense que dans un futur proche les deux technologies pourraient cohabiter.
Épilogue
T’avais remarqué que Deno c’est Node en verlan ? En tout cas Deno est porté par un développeur brillant et une communauté de passionnés sur GitHub. Avec son ambition de devenir un meilleur Node ce projet risque de devenir très intéressant. Ça serait suicidaire de l’utiliser en production aujourd’hui. Mais il rentre complètement dans la catégorie des nouvelles technos à suivre de près. Et compte sur moi pour t’en reparler, que ça explose ou non.
clearfix