Niveau Niveau débutant

Deno, le futur de Node ?

Articlejavascript

Publié par le , mis à jour le (10710 lectures)

javascript node typescript deno

Deno est un environnement d'exécution JavaScript et TypeScript qui a été pensé et conçu pour être une alternative à Node.js. Il permet à ce titre d'exécuter du code JavaScript, en-dehors d'un navigateur c'est-à-dire en ligne de commande ou en mode serveur grâce au moteur V8 de Chromium... mais il a été construit avec une série de différences clés par rapport à Node.js.

Le logo de Deno en situation

Un kiwi s'est caché dans cette image, saurez-vous le retrouver ?

Quelles sont les différences ?

Deno a été lancé par le créateur de Node lui-même : Ryan Dahl. Lors d'une conférence JSConf, ce dernier avait exprimé des regrets relatifs à sa première oeuvre qui date (déjà) de 2009. Vous pouvez découvrir ses arguments en vidéo : 10 choses que je regrette à propos de Node.js - Ryan Dahl

Entre autres :

  • Deno a été conçu pour être plus sécurisé que Node.js : son noyau a été écrit en Rust, qui est réputé pour sa robustesse, alors que Node fut conçu en C++. Par ailleurs tous les fichiers et ressources externes sont bloqués par défaut, ce qui signifie que vous devez explicitement autoriser l'accès à ces fichiers et ressources avant de pouvoir y accéder dans votre code. Cela peut aider à prévenir les attaques de type "chemin d'accès transversal" qui sont courantes dans les applications.
  • Deno supporte nativement TypeScript et JavaScript (tandis que Node.js utilise JavaScript bien entendu). TypeScript est un sur-ensemble de JavaScript qui ajoute comme son nom le suggère le typage statique des données, ce qui peut aider à éviter certains types d'erreurs de programmation.
  • Deno met l'accent sur la simplicité et l'uniformité, ce qui se reflète dans sa conception générale : toutes les fonctionnalités sont accessibles à travers un seul module global, plutôt que d'être divisées en différents modules comme c'est le cas dans Node. De plus, Deno inclut toutes les bibliothèques et outils nécessaires à l'exécution de code, vous n'avez donc pas besoin d'installer des packages tiers comme c'est le cas avec Node et npm.
  • Deno souhaite être au plus proche des standards et API natives par exemple il embarque Fetch ou WebStorage... dont une compatibilité avec les navigateurs : avec des ES Modules il n'y a pas besoin de webpack pour que ce soit prêt à l'emploi.

L'import de paquets se fait via URL, ce qui peut sembler initialement étrange mais fait sens dans la philosophie de Deno qui se veut décentralisé. Ce concept est bien expliqué par la documentation : Linking to third party code. Fini node_modules et package.json.

import { assertEquals } from "https://deno.land/std/testing/asserts.ts";

Côté performance, les résultats sont relativement similaires entre Deno et Node car le moteur interne reste V8.

Comment utiliser Deno ?

Avant toute chose, il faut garder à l'esprit que Deno est bien plus récent et que si des gros progrès sont réalisés pour améliorer la stabilité, on manque encore certainement de recul, de retours de bugs, de documentation et d'une communauté aussi importante que celle de Node pour déclarer que l'un peut remplacer l'autre d'un claquement de doigts... même s'il prévoit un module de compatibilité avec Node.

Pour utiliser Deno, vous devez d'abord l'installer en suivant les instructions fournies sur le site web officiel de Deno. Vous pouvez ensuite lancer des exécutions de code avec la commande deno dans le terminal, et vous vous retrouverez avec un environnement habituel où l'on peut entrer des instructions JavaScript et quitter avec close().

Voici un exemple de script Deno simple qui affiche "Hello World" dans la console :

// Fichier hello.js ou hello.ts
console.log("Hello World!");

Pour exécuter ce programme, vous pouvez utiliser la commande deno run :

deno run hello.js

Dès que l'on va tenter d'accéder à des ressources, Deno va demander l'autorisation. Par exemple pour l'accès en écriture à un fichier :

⚠️ Deno requests write access to "hello.log". Grant? [a/y/n/d (a = allow always, y = allow once, n = deny once, d = deny always)]

ou au réseau avec fetch :

⚠️ Deno requests net access to "wikipedia.org". Run again with --allow-net to bypass this prompt. Allow? [y/n (y = yes allow, n = no deny)]

On va pouvoir débloquer ces autorisations avec --allow-write (écriture de fichiers), --allow-net (accès au réseau), --allow-env accès à l'environnemment et --allow-run pour exécuter des sous-processus.

Il existe de nombreuses autres commandes et options que vous pouvez utiliser avec Deno pour exécuter et gérer vos programmes. Pour en savoir plus, consultez la documentation officielle de Deno

Commentaires

Ça fait un moment que j'entends parler de Deno. Dans le milieu professionnel, je n'ai pas encore vu d'architecture avec cet outil.

En ce qui concerne le choix du langage pour concevoir NodeJS ou Deno ça reste dérisoire. Le C++ n'a plus rien à prouver. Le C++ est un langage très robuste. Tout dépend comment le programme a été codé.

Deno n'a pas le même écosystème que node.js, le siens est beaucoup plus réduit. Il y a eu pas mal de portage au moment de la hype il y a un ou deux ans, mais beaucoup depuis n'ont pas été mis à jour. Deno est plus lent aussi. Deno n'est pas un challenger de node, il faut le voir plutôt comme un prototype dont node.js peut tirer partit pour ses futures implémentations ou ses prochains correctifs.

Par exemple, vous parlez de l'API fetch implantée nativement par deno, mais celle-ci est désormais effective sur les dernières versions de node.js. Idem pour typescript avec un flag dans la configuration, plus besoin de Babel depuis un moment déjà.

Soulevons aussi un point qui peut être incompris dans l'article ici présent : Deno n'est pas plus sécurisé car il est écrit en Rust, il est plus sécurisé dans le sens où l'accès au système hôte est fermé par défaut. Ce qui n'est pas du tout la même chose.

Et à ce propos, pour ce dernier point, peu importe au développeur d'une application que le projet soit écrit en Rust ou en C/C++. Pour lui ça ne change rien, ce n'est pas lui qui gère l'architecture. Ce n'est pas lui qui va gérer la mémoire mais les développeurs/concepteurs des deux écosystèmes susnommés. Le développeur de l'application va se contenter de javascript pour configurer tout ça, ses appels à libuv et au moteur V8 seront transparents (pour ne pas dire opaque : sait-il seulement ce qu'il y a sous le capot ?).

Commenter

Vous devez être inscrit et identifié pour utiliser cette fonction.

Connectez-vous (déjà inscrit)

Oubli de mot de passe ? Pas de panique, on va le retrouver

Pas encore inscrit ? C'est très simple et gratuit.