Deno V1 : une future alternative à NodeJS ?

Deno V1 est sorti officiellement le 13 mai dernier et a provoqué un gros drama dans la communauté Javascript. Ça ressemble énormément à NodeJS. C’est normal, le créateur de Deno est le même que celui de NodeJS. Mais c’est quoi Deno ? Et pourquoi ça pourrait devenir une alternative à NodeJS ?

Dans l’épisode précédent

Alors, si c’est la première fois que tu entends parler de Deno, il faut que tu ailles voir ce sublime article d’introduction à Deno. Tu auras toutes les infos sur Deno, en particulier ses origines qui sont fortement liées à Node. Je te fais un résumé rapide, je sais que t’as la flemme.

Deno est un runtime Typescript et Javascript sécurisé. Comme NodeJS, Deno utilise le moteur Javascript de Chrome : V8. Pour le reste c’est très différent.

Deno est écrit en Rust et l’event loop c’est Tokio. Là où NodeJS est écrit en C++ et utilise libuv. Encore une fois, je t’invite à te jeter sur l’article d’introduction à Deno si tu captes que dal à ce que je te raconte.

Surtout que cet article a fait pas mal de bruit quand il est sorti. J’ai déclenché la haine de certaines personnes dans la communauté NodeJS. Cher Thomas, moi aussi je pense que Deno est juste un projet laboratoire qui ne fait que renforcer NodeJS. Enfin, pour le moment. Car Deno V1, après 8 mois de retard, est finalement sorti de son œuf.

Premier contact

À l’heure où j’écris ces lignes, on est en V1.0.0. Côté installation, ça se passe très simplement.

curl -fsSL https://deno.land/x/install/install.sh | sh -s v1.0.0
sudo mv /path/to/deno /usr/bin/deno
deno --version
deno --help

Je te laisse regarder en détail toutes les sous-commandes listées avec la commande –help. Le truc important à comprendre avec les commandes Deno, c’est qu’elles comportent des features built-int dans Deno ! Des features qui nécessitent des outils entiers en Node.

• Bundle

Cette commande te permet de bundler ton application entière, avec ses dépendances, dans un seul fichier. L’utilité ici est de faire des bundles directement utilisables pour des sites webs ! C’est intéressant ici de noter que Deno a été pensé avec l’intégration des modules ES, ce qui fait que le bundling pour le front est facilité.

---

• Fmt

Deno V1 vient avec linter intégré. Pas de débat, tout le monde utilise le même, on retrouve un vrai souci de standardisation et de qualité ici.

---

• Test

Deno V1 vient avec un runner de test intégré ! La commande va évaluer le module passé en paramètres et rouler tous les tests déclarés avec Deno.test().

---

• Run

Deno V1 vient avec un support Typecript et Javascript intégré. Rien que ce détail va attirer tous les fanatiques de Typescript en masse.

Deno V1 : les features

Au lieu de détailler toute la liste des features, comme dans l’article d’introduction, on va passer rapidement dessus. En montant un serveur HTTP basique, on va déjà voir beaucoup de feature de Deno V1.

server.ts

import { serve } from "https://deno.land/std/http/server.ts";

const server = serve({ port: 8000 });
console.log(`http://localhost:8000/`);

for await (const req of server) {
  const body = await fetch('https://www.jesuisundev.com').then(response => response.text())
  
  req.respond({ body })
}

deno run --allow-net server.ts

• Gestion dépendances : Module ES via URL

Dès la première ligne, il se passe plusieurs choses intéressantes. D’abord on a l’utilisation native des modules ES avec une URL. Ça, c’est un truc de fifou. Tu peux pointer directement sur une URL d’une dépendance, ça va le télécharger et la mettre en cache !

---

• Gestion dépendances : Exit NPM et gestion du cache

Deno n’est pas compatible avec NPM. Les dépendances doivent pointer directement vers URLS (externe ou interne ou même un fichier local). Ça pousserait donc à utiliser des solutions comme pika.dev pour ses dépendances. À chaque fois qu’une dépendance est nécessaire, elle est téléchargée et mise en cache pour la prochaine fois.

Plus étonnant Deno préconise de comités les dépendances ! Si le site Web tombe en panne, tu conserves l’accès à la version téléchargée.

---

• Top-level await

Dans le code de mon petit serveur web, j’utilise un itérateur asynchrone pour traiter chacune des requêtes. J’utilise un await hors d’une fonction async. Deno V1 permet d’utiliser await a haut niveau sans contrainte et code inutile autour.

---

• Browser compatible

Dans mon bout de code, je vais fetcher le meilleur blog du monde via un fetch browser. Et cette affaire, ça marche parce que Deno est compatible avec les APIs browser. À l’heure où j’écris ces lignes, 100% des APIs browser ne sont pas encore toutes compatibles, mais ça va venir. Par contre le futur est déjà là.

---

• WebAssembly compatible

wasm.ts

const wasmBinaryBuffer = await fetch("https://bit.ly/3bhSp8O").then(response => response.arrayBuffer())
const wasmModule = await WebAssembly.instantiate(wasmBinaryBuffer)
const addFunctionExported = wasmModule.instance.exports._Z3addii
console.log(`Result of the WebAssembly module call : ${addFunctionExported(2, 2)}`)

deno run --allow-net wasm.ts
Result of the WebAssembly module call : 4

Le futur du web se fera avec WebAssembly. Si tu ne connais pas, tu peux te faire une séance de rattrapage en cinq minutes pour tout savoir sur le sujet. En tout cas c’est la même affaire, Deno V1 supporte WebAssembly de façon native.

---

• Typescript intégré

On peut lancer directement les fichiers typescript tel quel, sans configuration. Dans Deno V1 tout est intégré et déjà configuré pour Typescript. Pas besoin de tsconfig (tu peux quand même de façon optionnelle). Tu remarques que j’ai rajouté un flag –allow-net dans ma commande.

---

• Sandbox securisé

Deno V1 est un runtime sécurisé pour JS et TS. Ce qu’il est intéressant de comprendre c’est que de base Deno roule dans une sanbox. Là où NodeJS a accès automatiquement à tous les fichiers et les réseaux, Deno V1 il faut lui donner l’autorisation.

Ça fait déjà beaucoup pour un runtime qui vient d’arriver. En quelques années de développement, Deno a grandi plus vite que l’imaginaient beaucoup de gens. Et c’est pas fini.

J’ai joué un petit peu avec ces derniers temps. Mon avis a pas mal évolué dessus. Faut qu’on en parle.

Deno V1 : mon ressenti

Déjà, ce qui me frappe c’est la volonté de faire les choses biens avec ce projet. Tout est pensé pour le confort du développeur (linter, test, typescript intégrés) et pour le long terme (module es, webassembly, browser compatible).

Les modules standards officiels n’ont aucune dépendance externe et sont méticuleusement contrôlés par la core team pour ne laisser passer que du code de haute qualité.

Ce qu’il faut comprendre c’est que NodeJS, c’est du legacy code pour Ryan Dhal. Et comme n’importe quel développeur qui regarde son propre legacy code, ça lui fait pas plaisir. Le problème c’est que NodeJS c’est HUGE, ça tourne partout, la communauté est énorme et les packages qu’elle a créés encore plus !

Ça serait beaucoup trop complexe de tout fixer. Deno ne veut pas fixer Node. Les intentions sont plus hostiles que ça.

Ensuite, très franchement, ça ressemble beaucoup à Node dans l’utilisation. On en reparlera après, mais on sent bien que le cœur de cible de Deno c’est les utilisateurs de Node. Je me suis surpris à vouloir utiliser des affaires de Node avant de me rendre compte que j’étais pas dans le bon runtime. Je me sens beaucoup trop à la maison.

Mon utilisation de Node c’est des serveurs webs à forte concurrence. Le facteur performance est important pour moi. Je me rappellerais qu’à l’époque de la v0.24 les performances étaient désastreuses avec le serveur HTTP. Du coup je suis allé voir les benchmarks. Au moment où j’écris ces lignes, les chiffres sont nettement meilleurs, mais en dessous de Node. Et ça, c’est un super mauvais point à mon sens.

Enfin, j’étais très excité par la sortie de Deno V1. Passer la hype, après quelque temps d’utilisation concrète, c’est redescendu. Pour plein de raisons, je pense que Deno est clairement un step up dans la bonne direction. Mais c’est tout sauf une révolution.

Malgré tout ce que Deno apporte, c’est toujours pas assez (à mon sens) face aux arguments présents –et futurs– de Node. Si je lance un nouveau projet là tout de suite, je pars sur Node sans hésiter une seconde. Et du coup, je me demande comment va réagir la communauté Node.

Deno et la communauté Node

Les principaux utilisateurs de Deno seraient des utilisateurs de NodeJS. Des utilisateurs qui aiment leur technologie, qui en prennent soin et qui ont créé un écosystème incroyable autour d’elle. L’avenir de Deno est entièrement dans les mains de la communauté NodeJS. Et malgré tous les arguments que Deno V1 avance, j’ai du mal à voir cette communauté laisser Deno passer.

En tous cas, c’est sûr, pas de tout de suite. Tout de suite, NodeJS est un environnement stable, solide avec une communauté folle et des packages qui résolvent quasi tous les problèmes. NodeJS n’a plus rien à prouver et sera toujours là dans des dizaines d’années. D’ailleurs en passant, si tu es un jeune développeur qui passe par là : apprends Node ! Si vraiment ça t’intéresse, tu verras plus tard pour Deno.

En tous cas la sortie de Deno a créé pas mal de drama. Les trolls étaient tous de sortie. Beaucoup de personnes se posent la question de l’avenir de Node.

To all the nameless thousands that has spent time contributing to @nodejs, I’m sending ❤️. There are a few people that keep repeating that we will destroyed today. Don’t believe them.

To everybody else, we do not plan to go anywhere: we will keep supporting your amazing work.

— Matteo Collina (@matteocollina) May 13, 2020

C’est quoi la suite ?

J’ai pas une boule cristal et c’est toujours casse-gueule de prédire l’avenir. Par contre, je peux faire des hypothèses.

Il est possible que la communauté NodeJS ignore complètement Deno. Je dis ça parce que Node bouge beaucoup ces derniers temps. Les modules ES, WebAssembly arrivent, les workers threads sont déjà là et on voit beaucoup Node sur les sujets chauds comme l’IoT ou le serverless.

Il est possible que la communauté NodeJS adopte massivement Deno. Ça, j’y crois moyen, mais imaginons. Peut-être que les amoureux de Typescript vont être nombreux à préférer une solution qui le gère nativement. Peut-être que Deno va apporter encore plus de choses dans l’avenir et convaincre les sceptiques comme moi.

Il est possible que Deno devienne une simple alternative -interchangeable- avec Node. Le seul moyen que ça arrive c’est que Deno soit, d’une façon ou d’une autre, compatible avec Node. Je pensais que ce dernier point était impossible. Et puis je suis tombé sur cette issue faite par Ryan Dahl. L’équipe Deno est actuellement entrain de bosser sur le fait de rendre Node compatible avec Deno. Je suis curieux de voir ce qui va se passer s’ils arrivent à atteindre une compatibilité parfaite.

Et comme plusieurs avis sur un sujet c’est toujours enrichissant, j’aimerais donner la parole à un collaborateur NodeJS sur le sujet. En plus, Cocorico, il est Français !

Salut Vlad ! Comment tu vois l’avenir de Node dans les années qui viennent et pourquoi ?

Tu peux retrouver Vladimir sur son twitter ou sa page medium. Pour être au courant de ce qui se passe sur Node, il faut le suivre ! Merci beaucoup Vladimir d’avoir pris le temps de répondre à ma question avec autant de détails !

Épilogue

Dans la dernière conf en date de Ryan Dahl, il a validé que Deno se prononçait bien « Dino » et non pas « Déno ». Malgré cette belle V1, Node me semble beaucoup trop solide pour être inquiété à moyen terme. Par contre je suis curieux de l’évolution de tout ça dans quelques années. Tu peux compter sur moi pour te tenir au courant !