Qu'est-ce que Deno et en quoi ce projet est-il différent de Node.js?

Ryan Dahl, créateur de Node.js, a passé un an et demi à travailler sur le projet Deno . Il s'agit du nouveau runtime JavaScript qui devrait résoudre les problèmes inhérents à Node.js.

Ne vous méprenez pas. La plateforme Node.js est un excellent environnement côté serveur pour exécuter JavaScript. Il doit sa popularité principalement à un immense écosystème et, en fait, à la prise en charge de JavaScript. Cependant, Ryan Dahl admet que quelque chose à propos de Node.js devrait mériter son attention. Il s'agit en particulier de sécurité, de modules et de gestion des dépendances.


Pour sa défense, on pourrait dire qu'il ne pouvait pas savoir à quel point la plateforme Node.js deviendrait populaire dans un laps de temps assez court. De plus, en 2009, JavaScript ressemblait toujours à un langage limité et étrange, dont tous ceux qui n'étaient pas paresseux se moquaient. Il convient également de noter qu'à cette époque, de nombreuses fonctionnalités JavaScript qui étaient courantes de nos jours n'existaient pas.

Qu'est-ce que Deno et quelles sont les principales fonctionnalités de cette plateforme?

Deno est un runtime sécurisé TypeScript intégré au moteur V8 JS développé par Google. La plateforme Deno a été créée à l'aide des outils suivants:

• Rust (le noyau Deno est écrit en Rust et le noyau Node est en C ++).
• Tokio (boucle d'événement écrite en Rust).
• TypeScript (Deno, sans paramètres supplémentaires, prend en charge JavaScript et TypeScript).
• V8 (moteur JS de Google utilisé dans le navigateur Chrome, Node.js et d'autres projets).

Parlons des opportunités que nous offre la plateforme Deno.

Sécurité (autorisations)

Parmi les caractéristiques les plus importantes de Deno, qui reçoivent une attention particulière, la sécurité peut être notée.

Contrairement à Node, Deno, par défaut, exécute le code dans un bac à sable. Cela signifie que le runtime n'a pas accès aux entités et capacités suivantes:

• Système de fichiers.
• Réseau.
• Exécution d'autres scripts.
• Variables d'environnement.

Jetez un œil au fonctionnement du système d'autorisation de Deno. Considérez le script suivant:

(async () => {  const encoder = new TextEncoder();  const data = encoder.encode('Hello world\n');  await Deno.writeFile('hello.txt', data);  await Deno.writeFile('hello2.txt', data); })(); 

Ce script crée une paire de fichiers texte - hello.txt et hello2.txt . Le texte Hello world placé dans ces fichiers. Le code est exécuté dans le bac à sable. Par conséquent, il n'a pas accès au système de fichiers.

Faites également attention au fait que nous utilisons ici l'espace de noms Deno , plutôt que de faire référence à quelque chose comme le module fs , comme nous le ferions dans Node. L'espace de noms Deno fournit au développeur de nombreuses fonctions d'assistance de base. Mais nous, en utilisant l'espace de noms, perdons la compatibilité du code avec le navigateur. Nous en parlerons ci-dessous.

Ce script peut être exécuté avec la commande suivante:

 deno run write-hello.ts 

Après cela, nous verrons une notification avec le contenu suivant:

 Deno requests write access to "/Users/user/folder/hello.txt". Grant? [a/y/n/d (a = allow always, y = allow once, n = deny once, d = deny always)] 

En fait, nous pouvons bien voir cela deux fois au cours de chacun des appels. Bien sûr, si nous répondons à la question du système en sélectionnant l'option allow always , la deuxième fois nous ne recevrons pas cette notification.

Si nous choisissons l'une des options de deny , une erreur PermissionDenied sera PermissionDenied . Le processus de script sera alors terminé, car il n'y a pas de code pour gérer les erreurs.

Le script peut être exécuté comme ceci:

 deno run --allow-write write-hello.ts 

Nous ne verrons aucune notification; les deux fichiers seront créés.

Outre l' --allow-write , qui affecte le travail avec le système de fichiers, vous pouvez utiliser d'autres indicateurs lors de l'exécution de scripts. Ce sont --allow-net , --allow-env et --allow-run . Ils ouvrent respectivement l'accès du script au réseau, à l'environnement et au lancement des sous-processus.

Modules

Deno, comme les navigateurs, charge les modules par URL. Au début, beaucoup de gens sont confus par ce qu'ils voient dans les commandes d'importation de code serveur avec des URL. Mais cela, en fait, a du sens. Attendez un peu - et vous le comprendrez vous-même.

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

Ici, vous pouvez avoir une question sur ce qui est si spécial à propos de l'importation de packages par URL? La réponse à cette question est simple: grâce à l'utilisation d'URL, les packages Deno peuvent être distribués sans utiliser de registre central comme npm. Npm a eu beaucoup de problèmes ces derniers temps.

L'organisation de l'importation de code via URL permet aux créateurs de packages d'héberger leur code où bon leur semble. C'est la décentralisation dans toute sa splendeur. Plus de package.json et node_modules .

Lorsque nous lançons l'application, Deno charge tous les modules importés et les met en cache. Une fois qu'ils sont mis en cache, Deno ne les rechargera pas sauf si nous demandons explicitement qu'ils soient --reload à l'aide de l'indicateur --reload .

Concernant ce système de travail avec les modules, plusieurs questions importantes peuvent être posées.

Que se passe-t-il si la ressource sur laquelle se trouve le code du module est inaccessible?

Le code du module n'est pas stocké dans un registre centralisé. La ressource Web qui héberge ce code peut ne pas être disponible pour de nombreuses raisons. Pendant le processus de développement, ou pire encore, la mise en production du projet, il est risqué d’espérer que l’hébergement du module sera toujours disponible.

Comme déjà mentionné, Deno met en cache les modules chargés. Étant donné que le cache est stocké sur un disque local, le créateur de Deno recommande de le traiter à l'aide du système de contrôle de version (c'est-à-dire git) et de l'inclure dans le référentiel du projet. Avec cette approche, même lorsque la ressource sur laquelle le code est stocké est inaccessible, tous les développeurs de projet conserveront l'accès aux versions téléchargées des modules.

Deno stocke le cache dans le dossier spécifié par la variable d'environnement $DENO_DIR . Si nous ne configurons pas cette variable, Deno stockera le cache dans le répertoire système standard pour les caches. La $DENO_DIR peut être définie de manière à pointer vers un dossier de notre référentiel local. Ce dossier peut être traité à l'aide de votre système de contrôle de version.

▍Dois-je importer constamment des modules par URL?

La saisie régulière d'URL longues peut s'ennuyer rapidement. Heureusement, Deno nous donne deux façons de faciliter cette tâche.

La première consiste à utiliser la possibilité de réexporter le module importé à partir du fichier local. Par exemple, cela pourrait ressembler à ceci:

 export { test, assertEquals } from "https://deno.land/std/testing/mod.ts"; 

Supposons que le fichier dans lequel se trouve la commande ci-dessus s'appelle local-test-utils.ts . Maintenant, si nous avons à nouveau besoin des fonctions test ou assertEqual , nous pouvons les importer comme ceci:

 import { test, assertEquals } from './local-test-utils.ts'; 

En conséquence, il s'avère que le module n'a pas été chargé par URL ou non.

La deuxième option consiste à créer une carte d'importation sous la forme d'un fichier JSON:

 {   "imports": {      "http/": "https://deno.land/std/http/"   } } 

Lorsque vous utilisez un fichier similaire, la commande d'importation peut ressembler à ceci:

 import { serve } from "http/server.ts"; 

Pour que ce schéma fonctionne, vous devez informer le système de l'utilisation de la carte d' --importmap dans le projet, en utilisant l'indicateur --importmap lors de l'exécution du script:

 deno run --importmap=import_map.json hello_server.ts 

OwComment la gestion des versions des modules est-elle gérée?

Le contrôle de la version du package est de leur responsabilité. Du point de vue du client, choisir la bonne version de package revient à l'ajouter à l'URL:
https://unpkg.com/liltest@0.0.5/dist/liltest.js .

Compatibilité du navigateur

La plateforme Deno vise la compatibilité de son code avec les navigateurs. D'un point de vue technique, lorsque nous utilisons des modules ES, nous ne sommes pas obligés d'utiliser certains outils d'assemblage, comme webpack, qui offrent la possibilité d'exécuter l'application dans un navigateur.

Cependant, des outils comme Babel convertissent le code JS moderne en code compatible ES5. Par conséquent, ce code peut être exécuté même dans des navigateurs non récents qui ne prennent pas en charge les fonctionnalités JavaScript modernes. Mais cette approche a aussi un inconvénient, qui consiste dans le fait que les bundles de projets Web se développent en raison du fait qu'ils obtiennent beaucoup de code auxiliaire.

En fait - nous prenons des décisions concernant les objectifs de nos projets. Nous choisissons les outils appropriés.

Prise en charge de TypeScript

Deno simplifie l'utilisation de TypeScript, éliminant ainsi la nécessité pour les développeurs de configurer quoi que ce soit pour exécuter le code TS. Mais les programmes Deno peuvent également être écrits en JavaScript sans problème.

Résumé

Deno, le nouvel environnement d'exécution pour TypeScript et JavaScript, est un projet intéressant qui démontre la durabilité depuis un certain temps maintenant. Cependant, avant qu'il ne puisse être considéré comme prêt pour la production, il a encore un long chemin à parcourir.

L'approche décentralisée de l'utilisation des modules implémentés dans Deno vise à libérer l'écosystème JavaScript d'un référentiel de packages centralisé, qui est aujourd'hui npm.

Ryan Dahl dit qu'il prévoit de sortir Deno 1.0 à la fin de l'été. Si vous êtes intéressé par l'avenir de ce projet - faites attention à son référentiel .

Chers lecteurs! Que pensez-vous de Deno?