Deno V1 : une futur alternative à NodeJS ?

En dehors du titre, le générique masculin est utilisé sans aucune discrimination et uniquement dans le but d'alléger le texte.

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.



deno v1


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
deno run


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

deno v1


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.



node


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.



deno v1


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.





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 ?

Vladimir de Turckheim

Hey Mehdi, merci beaucoup d’avoir pensé à moi pour ton article!

L’avenir de Node.js est super intéressant de mon point de vue. Mais avant d’en parler, je commence par les petits warnings d’usage: “tout le contenu de ma réponse ne présente que mon opinion et je ne parle pas au nom de mon employeur, du projet Node.js ou de la OpenJS Foundation”. Voilà pour la partie relou.

Aujourd’hui, Node.js est un projet qui va globalement bien. En fait, je me fais moins de soucis pour node qu’il y a quelques années. Tout d’abord, et c’est pas rien, le projet est en sécurité: La Fondation nous fournit un cadre de travail qui permet d’avancer ensemble de concert sans avoir besoin de faire comme d’autres projets open source et de rester sous le contrôle d’un unique lead mainteneur qui prend toutes les décisions (un BDFL, perso, je suis trop démocrate pour bosser sur un projet open source qui adopte ce modèle).

Ensuite, ce cadre clair permet à des entreprises de toutes tailles (si j’étais un journaliste, je dirais “des géants du web, aux jeunes pousses innovantes”), de fournir des contributeurs au projet Node.js. Ça à l’air tout bête, mais c’est pas un sujet évident ! Il y a aussi beaucoup de contributeurs qui ne sont pas sponsorisés pour participer au projet. Au final, je trouve que node a trouvé un bon équilibre quant à l’origine des collaborateurs du projet. 

Cette richesse d’opinion fait qu’on peut fabriquer des features robustes ! Mais aussi, ça fait qu’on va parfois pas très vite pour les sortir. Parfois même, les débats sont houleux. Heureusement, il y a un Code of Conduct clair et une équipe de modération entraînée et vraiment super cool!

Bon, alors, maintenant que j’ai posé le décor, c’est quoi le futur de Node.js ? Bah d’abord il y a les trucs à court terme. 

Je crois qu’on est très proches de passer les ES modules comme stable dans le core ! (Je pense que ça doit être la feature la plus attendue par les devs!). Le top level await devrait pas tarder non plus. D’ailleurs, des collaborateurs de Node.js sont parmi les personnes qui ont spécifié ces fonctionnalités dans EcmaScript ou voire même en sont à l’origine. 

Mais en fait, j’ai bien envie de parler de ce que je vois comme avenir pour node à cause de/grâce à Deno. Alors pour être franc, le talk de Ryan, il y a 2 ans m’a fait beaucoup d’effet.

Si on omet les trucs un peu random (en vrai, qu’un projet utilise Make, Cmake, Gyp ou GN en interne, ça impacte pas les utilisateurs, si?), il y avait des super points ! Alors, ces dernières années, j’ai pas mal cogité dessus. Je vais prendre un exemple.

Le support TypeScript est une super feature. J’ai commencé à sonder le monde Node.js dessus. Très vite, on s’est rendu compte que comme TypeScript est un projet qui n’a pas peur des “breaking changes” entre versions mineures, on s’est dit qu’on arriverait pas à trouver de moyen pour faire une expérience utilisateur sympa. Par contre, on peut faire le support TypeScript sans mettre TypeScript dans node! Il se discute, un flag à passer à node (peut-être un truc comme `-t`) pour fournir un transpiler. Du coup tu ferais `node -t typescript module.ts`.

Ça serait cool ! Alors pourquoi c’est pas déjà fait ? D’abord parce que j’attends le support des modules ES6. Puis aussi, il faut le support des sourcemaps pour que ça marche bien. Ça tombe bien, c’est 2 trucs qui sont en cours ! Alors est-ce que ce flag viendra ? J’espère ! J’ai envie de le faire en tout cas, mais j’aurais peut-être pas le temps (j’ai 2 autres sujets sur node en ce moment). Par contre, si quelqu’un veut le faire, faut se lancer! Mes DMs sur Twitter sont ouverts, discutons-en !

Aujourd’hui, Deno est un formidable laboratoire pour tester des trucs. Et, ils ont le droit de se planter! Node.js est utilisé partout dans le monde et dans plein d’industries différentes. On a des utilisateurs qui demandent de la stabilité et des solutions à leurs problèmes.

En revanche, la  v1.0 de Deno a été publiée avec des failles de sécurité publiques dedans ! (Je t’avoue que l’ingénieur en sécurité des applications web que je suis a un peu de mal à suivre leur logique). Ils ont dû considérer que ce n’était pas important pour cette release et c’est assez étrange vu que la “sécurité” semble être leur premier argument marketing!

Est-ce que Deno va apporter des choses à long terme ? Pour le moment, il est trop tôt pour le dire. Et certains supporters de Deno que j’ai pu rencontrer ou que j’ai vu sur les repos Github du monde Node.js sont parfois maladroits dans leur façon de mettre en avant leur champion. Par exemple, depuis un talk dans une grande conf JS francophone, je peux plus aller à un meetup Node ou JS sans que quelqu’un vienne me troller sur “Deno will kill Node.js, lol”. C’est pas super agréable et je fais de mon mieux pour pas me laisser atteindre. Mais quand tu passes ta vie sur un projet comme ça, c’est parfois pas évident. J’en ai pas parlé directement avec d’autres collaborateurs Node.js, mais je crois comprendre que je suis pas le seul à rencontrer ces situations inconfortables (mais bon les trolls semblent être partout).

Avant de conclure, je voudrais faire un petit hors sujet. Je rencontre pleins de devs qui osent pas contribuer aux projets open sources. Souvent par syndrome de l’imposteur (je connais un blog qui en parle dans un excellent article d’ailleurs). Bon, alors, il y a 3 trucs que je voudrais mettre en avant: 

  • les collaborateurs sont pas surhumains. Je suis certain que beaucoup de lecteurs de cet article connaissent mieux des morceaux de Node.js et de JavaScript que moi!
  • les communautés open source peuvent être des endroits où les aventures humaines sont exceptionnelles. Je me suis fait des amis dans le monde entier avec Node.js. Et on est toujours content de voir des nouveaux arrivés dans le groupe!
  • le dernier point est le plus important. Si personne ne fait les choses, les choses ne sont pas faites. Je vois beaucoup de gens demander une fonctionnalité en particulier dans Node.js. Mais, parfois, elle n’est pas là juste parce que personne ne l’a codée! (si ça, c’est pas un call to action!)

Alors, ça sera quoi node dans 2, 5 ou 10 ans? Je pense que Node.js va rester une techno assez populaire du web. Mais j’espère qu’une saine compétition va se mettre en place entre Deno et Node.js et que le gagnant sera… le développeur qui va avoir droit à plein de features cools de la part de ces deux runtimes!

Que ça soit les contributeurs Deno ou Node.js, on parle de gens qui passent leurs semaines ou leur weekends voire les deux, pour fabriquer des outils gratuits, open source et plutôt sympas. Mais en vrai, Deno ou Node.js, c’est les développeurs qui fabriquent des trucs cools avec qui leur donnent toute leur valeur. On se revoit dans 2 ans pour en parler?

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 !

Qui me parle ?

jesuisundev
Je suis un dev. En ce moment je suis Backend Développeur / DevOps à Montréal. Le dev est l'une de mes passions et j'écris comme je parle. Je continue à te parler quotidiennement sur mon Twitter. Tu peux m'insulter à cet e-mail ou le faire directement dans les commentaires juste en dessous. Y'a même une newsletter !

3 commentaires sur “Deno V1 : une future alternative à NodeJS ?”

  1. Je suis un contributeur du projet deno. J’y contribue principalement sur la compatibilité nodeJS (ajout des modules en Rust et Ts)
    J’utilise node au quotidien pour le travail, et pour le moment deno n’est pas encore au niveau pour remplacer NodeJS pour du backend.
    Par contre comme outils de tooling et scripting… Je pense qu’il est déjà plus adapté que Node, des a présent.
    J’ai réalisé des POCs d’outils en ligne de commande. C’est beaucoup plus agréable a utiliser que Node de mon point de vue.

  2. “NodeJS est un environnement stable, solide”.

    Stable ? Il ne faut pas exagérer ! L’écosystème NodeJs a des qualités, mais ce n’est certainement pas par sa stabilité qu’il brille le plus. Ce serait comme essayer de dire que ruby (ou python) est hyper rapide, Java hyper léger, Go le meilleur langage fonctionnel, ou C++ le plus simple à apprendre. Ce sont des points sur lesquels des progrès sont parfois fait au gré des MaJ, mais qui restent des points relativement faibles.

    Y a pas longtemps => https://www.zdnet.com/article/another-one-line-npm-package-breaks-the-javascript-ecosystem/

    Oui, ce n’est pas directement le runtime NodeJs, mais ce genre de lib est partie prenante de l’environnement NodeJs et l’impacte d’une façon importante compte tenu du nombre de dépendances moyen de chaque projet/lib Js.

  3. Merci a vous 2, super article.
    En tant que petit utilisateur de NodeJs, j’aime les possibilités qu’il offre, la communauté, les performances, le fait d’avoir un seul langage qui me permet de faire du backend & frontend.

    Les évolutions de NodeJs sont encourageantes le nombre de release actuel démontre sa capacité a s’adapter, c’est une techno qui n’est pas prêt de s’éteindre.

    On ressent cependant une bonne capitalisation du retour d’expérience sur Nodes dans la conception de Deno. La gestion des paquets & dépendance, la concurrence des thread (qui me faisait lorgner sur Go), le support de Typescript et la sécurité (meme si ca semble apparemment un peu mis de côté pour cette v1). Ainsi Deno me donne le sentiment d’un outils plus packagé qui va au dela de l’aspect serveur en questionnant également les méthodes & besoins des développeurs afin de les standardisé.

    Reste a patienter pour les 2/3 prochaines années, l’écosystème NPM est riche mais offre aussi parfois de jolies surprise. Deno a les bonnes bases pour s’imposer et c’est certain que je le testerais sur quelques projets lorsqu’il aura plus de maturité.

T'en penses quoi ?

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