Deno : le nouveau NodeJS ?

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 milliards 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.



node_modules


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.



denoland


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. Ca 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 au 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. Ca 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’a 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 ca donne ?



deno


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.

deno

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 remarquer 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.

Qui me parle ?

Je suis un dev. En ce moment je suis Backend Développeur / DevOps à Ubisoft. Je suis passionné du dev et expert en blagues. Je continue à te parler quotidiennement sur mon Twitter. Tu peux m'insulter à cette e-mail ou le faire directement dans les commentaires juste en dessous.

Commentaire(s)

  1. Il paraîtrait qu’une loi va être votée pour interdire Javascript. En effet, il s’avérerait que cette plaisanterie originelle ait été prise au sérieux d’où la floraison déraisonné de programmes JS. faut désormais agir !

  2. C’est terrible. Moi qui fait déjà l’éloge de nodeJS avant d’avoir commencer son utilisation (je suis un cours d’introduction à nodeJS , vu que je ne veux pas apprendre PHP 😂😂 (on me force )). Et maintenant Déni et puis quoi encore !😰
    Et ces CMS en nodeJS vont dire quoi maintenant ???? Vraiment . Je vais croiser les bras . Je vais supposer n’avoir rien lu.

  3. Encore un signe que JavaScript n’est toujours pas arrivé a mâturité.

    A moins d’avoir des besoins de front-end web j’évite, personnellement j’évite.

    1. C’est n’importe quoi de dire qu’il n’est pas arrivé à maturité et ça montre une profonde méconnaissance de celui-ci :(. La seule chose de reprochable à JavaScript, c’est qu’il est faiblement typé, mais la solution est toute trouvée… Il y a typescript (merci Microsoft) pour résoudre ce problème :).

      J’espère que la prochaine évolution majeure de Js, ça sera un typage fort optionnel comme avec typescript, mais en natif dans les spécifications du langage.

      Pour ma part, JavaScript est devenu un langage très sérieux, très portable et très cool qui se bonifie avec le temps et qui commence même à être repris dans certains de ses concepts par d’autres langages.

      Ici, on ne remet pas en cause le langage JavaScript dans cet article, mais que nodejs (le runtime) arrive à des limites du à des choix et du code legacy qui datent de quelques années qui le rend compliqué à maintenir dans l’état aujourd’hui du point de vue de son créateur.

      Le créateur veut repartir sur du neuf pour définir une nouvelle base qui est plus proche de sa vision des choses d’aujourd’hui.
      Pourquoi pas, je trouve ça cool de se dire, “bon la technologie a 10ans, on pourrait faire un reboot pour dégager les librairies historique et le code legacy et ce putain de node module qui casse le cerveau”.

      Cependant pas d’inquiétude pour node à mon avis… Perso pour le web, il n’a pas d’équivalence d’un point de vue performance et scalabilité je trouve.

      Toutefois, je suis très enthousiaste de voir qu’il y ait de nouvelles approches côté backend pour le JavaScript :). C’est comme ça que l’informatique fonctionne et évolue depuis toujours. Il y a truc qui sort, il est adopté en masse ou pas.

      Ce que je trouve fort en JavaScript, c’est la richesse en framework en tout genre, en librairies et en technologies.

      On ne s’ennuie pas avec ce langage et il y a plein de produits très sérieux sur le marché.

      La MEAN stack ou autre a encore de beau jour devant elle :).

      1. C’est la seule façon de faire du front, et le front c’est cool mais l’outil est pas non plus génial, on peut aussi reprocher à JS :
        – qu’il faut y investir des tas d’heure pour bien comprendre ce que tu fais et pas te tirer une balle dans le pied,
        – que s’il est si bien et qu’on l’aime tellement pourquoi on code un dans autre langage comme TypeScript ?
        – que les libs standards sont trèèès pauvres. Tu peux rien faire sans télécharger 300mo de dépendance (bon courage pour auditer la sécurité avec tes 150 modules)
        – que tu as toujours 30 alternatives quand tu veux télécharger une lib et que j’ai pas que ça à faire
        – que le peu de lib présente restent des années après moins agréable que jQuery (POST un JSON de tête sans chercher la doc)
        – que c’est très unsafe par défaut avec les variables globales si tu mets pas le mot clé `var`
        – qu’il est une immense machine à créer de la dette technique,
        – …

        Je retourne prendre mes cachets 🙂
        Je suis frustré de JS parce que je dois m’en servir, mais évidement que ça permet des tas de trucs cools et c’est tant mieux que le mec fasse avancer le schmilblick

        1. Bah il y a toujours eu des transpilers pour les langages… En java par exemple, tu as groovy ou Scala. Typescript apporte la couche typage fort mais c’est purement pour ton ide et réconcilier les gars du java ou du c# avec le js 🙂 et pour mieux scaler le code à mon goût. Encore une fois deno, n’est pas une amélioration de JavaScript mais un genre de reboot de node. Rien à voir avec le langage JavaScript lui même.

          1. Et surtout typescript, ce n’ai pas un autre langage. C’est du js avec la possibilité de faire du typage fort. Cependant à la transpilation, c’est bien du js qui est généré.

          2. Je ne sais pas pour groovy mais scala ça ne transpile pas en java mais ça compile en bytecode java, y’a une différence.

  4. Ceux qui crachent sur Javascript c’est qu’ils ne l’ont jamais pratiqué.
    Javascript comme tout langage a ses forces et faiblesses. En règle générales les devs veulent qu’un langage se rapproche de leur langage de base. C’est comme vouloir que l’anglais soit construit comme le français, etc..
    En bref, c’est ne rien comprendre à la programmation.

T'en penses quoi ?

Your email address will not be published. Required fields are marked *