Deno vs Node : Quel est le meilleur runtime Javascript ?

Connaissez-vous Deno, runtime web récemment arrivé sur le marché ? Ce rival direct à Node, créé d’ailleurs par le même développeur, vient concurrencer son parent avec de nombreux arguments en sa faveur…

Vous voulez commencer un nouveau projet et hésitez entre Node et Deno ? Ou voulez faire passer votre projet Node déjà existant vers cette nouvelle techno ?

Faisons le point sur Deno dans cet article !

Deno, concurrent direct à Node

Historique

Comme nous venons de le dire, Deno a été créé par Ryan Dahl, également fondateur de Node. Ce nouvel environnement d’exécution (ou runtime, en anglais), a été annoncé en 2018. Si plusieurs versions sont sorties dès cette date, la version 1.0, officielle, est, elle, arrivée sur le marché en 2020.

Si le créateur de Node a voulu créer un concurrent à ce dernier, c’est parce qu’il le trouvait trop imparfait. L’annonce de Deno a d’ailleurs été faite lors d’un des discours de Ryan Dahl, nommé “10 Things I Regret About Node.js”.

Parmi ces regrets – ceux qui l’ont poussés à développer Deno – citons :

• La non-utilisation native des promesses ;
• La présence des node_modules et du package.json, qui viennent alourdir le projet ;
• Le manque de sécurité, la trop grande permissivité de la techno ;
• Le peu de modularité et de souplesse du produit.

Deno et Node : les principales différences

Deno et Node ont de nombreux points communs, et passer de l’un à l’autre sera assez facile pour tout développeur connaissant déjà le premier runtime JavaScript. Cependant, ce nouveau venu ayant été créé pour corriger certaines faiblesses de son parent, il possède des différences notables.

Parmi celles-ci :

• Node a été écrit en C++ ; Deno en Rust ;
• Deno n’a pas de système de gestion de package (npm) ; les modules sont directement importés via leurs sources web ;
• Il vient avec un ensemble d’outils intégrés, notamment pour les tests, le formattage ou la création de documentation ;
• Il utilise TypeScript par défaut, sans besoin de configuration ;
• Nous avons besoin de donner explicitement les autorisations d’accès à certaines fonctionnalités (appels serveur, accès aux fichiers physiques, etc.), ce qui augmente la sécurité du projet basé sur Deno ;
• Deno ne produit qu’un seul fichier exécutable en sortie ;

Nous reparlerons de toutes ces différences, de leurs avantages et inconvénients, plus loin dans cet article.

Deno dans la technique

Maintenant que nous avons fait le point sur la techno de manière globale, il est temps de rentrer un peu plus dans la technique !

L’installation

Deno ayant été développé dans le but de simplifier Node, son installation et son fonctionnement sont également optimisés.

Ainsi, pour installer ce runtime, cela se fait en une seule ligne de commande :

# Mac/Linux 
brew install deno

# windows
choco install deno

Pour démarrer un nouveau projet, le plus simple est de créer un fichier TypeScript, puis de l’exécuter via la commande ‘deno run’. Par exemple :

mkdir myProject && cd myProject
touch app.ts
deno run app.ts

Quelques exemples de code

Pour bien comprendre le fonctionnement d’une technologie de programmation, le mieux est de voir des exemples de code. Et Deno ne fait pas exception ! Voyons quelques snippets de code propres à ce runtime.

Le système d’import de module

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

for await (const req of serve({ port: 8000 })) {
    req.respond({ body: "Hi from Deno!\\n" }); 
}

Là où Node a besoin d’installer des modules via la commande ‘npm install’, Deno les importe directement depuis leur source web. C’est ce que nous voyons ici ; il n’y a pas besoin d’installer le module Server, nous l’importons directement via l’URL « https://deno.land/std/http/server.ts ».

Pour éviter d’avoir à télécharger les sources à chaque exécution, Deno vient avec un système de cache, qui garde les scripts en mémoire locale.

Les outils intégrés

deno fmt # formatte le code de façon standard
deno run # exécute le programme
deno lint # exécute un linter, pour vérifier la conformité du code
deno test # exécute les tests écrits dans le projet Deno
deno doc # cette commande génère de la documentation pour un fichier donné
deno cache # pour la gestion du cache. Pour supprimer le cache, on utilisera deno cache --reload app.ts

Deno vient donc avec un ensemble de commandes intégrées, comme le montre ce snippet de code. En plus d’éviter l’ajout de librairies externes, comme avec Node, l’exécution de ces outils en une ligne de commande facilite le travail des développeurs.

Autoriser l’utilisation de fonctionnalités natives

deno run --allow-net index.ts

Nous l’avons dit, Deno a besoin que l’on autorise l’utilisation de certaines fonctionnalités de façon explicite. Dans cet exemple, il faut ajouter l’option ‘allow-net’ pour permettre à l’application de faire des appels serveur vers l’extérieur. Avec Node, cette autorisation est implicite.

Node vs Deno : qui l’emporte ?

Si les deux technologies sont au fond assez similaires, notamment, car elles se basent sur le même moteur JavaScript (V8, de Google), utilisent les mêmes langages et interviennent sur le même genre de projets, les nouveautés qu’apporte Deno méritent un comparatif un peu plus poussé, avant de choisir la techno à utiliser.

Deno, ses avantages sur Node

Deno se définissant comme une évolution de Node ; il vient avec certains avantages.

Le fait d’avoir été écrit en Rust plutôt qu’en C++, le rend plus robuste, et permet de capter les erreurs internes à la compilation. Cela ne lui permet toutefois pas d’être plus rapide que Node.

L’ensemble des outils intégrés, tels que ceux pour le formatage ou la documentation (que nous avons donné en exemples), permettent de se passer de librairies externes et des risques qui viennent avec (failles de sécurité, code non maintenu, etc.).

Le besoin d’autoriser explicitement l’accès à certaines fonctionnalités, tels que les appels réseaux et l’écriture de fichiers, permet un niveau de sécurité plus poussé. Du côté de Node, on accorde implicitement toutes ces autorisations.

L’import direct des librairies externes via une URL et non un module allège le projet (pas de dossier node_modules) et permet d’avoir en permanence les dépendances à jour.

Également, l’utilisation native de TypeScript offre un gain de temps dans le cas où le développeur veut utiliser ce langage : il n’y a pas besoin de paramétrage.

Les inconvénients du runtime Deno

Si Deno vient avec de nombreux avantages, il n’est pas dénué d’inconvénients, bien que ceux-ci soient peu nombreux :

La nouveauté de la techno (annoncée en 2018, contre 2009 pour Node), fait qu’elle a une communauté plus petite, il sera peut-être plus difficile de trouver de l’aide. Les technos web évoluant très vite, une forte communauté est souvent appréciée, voire nécessaire, lorsque l’on travaille sur des projets complexes.

Cette jeunesse peut également provoquer des instabilités dans le runtime (des bugs ou failles n’ont peut-être pas encore été trouvés !).

Enfin, le fait que Deno vienne avec plus d’outils intégrés et soit plus complet, est autant un avantage qu’un inconvénient. Cela peut en effet alourdir le développement et le travail du développeur, surtout si ce dernier travaille sur un projet très simple. Cela concerne autant les commandes intégrées que le besoin explicite des autorisations.

Conclusion : Deno, meilleur que Node ?

Nous venons de le voir, Deno prend l’avantage sur Node sur de nombreux points. L’utilisation de TypeScript, une meilleure gestion des modules et tous ses nouveaux outils intégrés rendent le projet créé avec ce runtime plus sûr et plus maintenable.

Deno peut donc se révéler être une meilleure alternative à Node, dans une grosse partie des projets.

Cependant, si un développeur cherche à créer un projet très basique, la simplicité de Node lui sera peut-être davantage utile que la suite Deno.

Comme pour toute stack technique, le choix des technologies dépend donc avant tout du besoin, mais également de l’envie et des connaissances des développeurs !