
Mais pour les ingénieurs Ryan Dahl, Bert Belder et Bartek Iwańczuk cependant, il est toujours important d'avoir un environnement de script puissant qui peut traiter un large éventail de domaines problématiques.
JavaScript est le langage dynamique le plus utilisé, fonctionnant sur tous les appareils dotés d'un navigateur Web. Un grand nombre de développeurs « parlent » couramment le JavaScript et beaucoup d'efforts ont été déployés pour optimiser son exécution. Grâce à des organismes de normalisation comme ECMA International, le langage a été soigneusement et continuellement amélioré.
Aussi, les ingénieurs Ryan Dahl, Bert Belder et Bartek Iwańczuk pensent que JavaScript est le choix naturel pour l'outillage de langage dynamique; que ce soit dans un environnement de navigateur ou en tant que processus autonomes.
« Notre vecteur d'origine dans ce domaine, Node.js, s'est avéré être une plateforme logicielle très réussie. Les gens l'ont trouvé utile pour créer des outils de développement Web, créer des serveurs Web autonomes et pour une myriade d'autres cas d'utilisation. Node, cependant, a été conçu en 2009 lorsque JavaScript était un langage très différent. Par nécessité, Node a dû inventer des concepts qui ont ensuite été repris par les organismes de normalisation et ajoutés au langage différemment. Dans la présentation Erreurs de conception dans Node, ceci est discuté plus en détail. En raison du grand nombre d'utilisateurs de Node, il est difficile et lent de faire évoluer le système.
« Avec l'évolution du langage JavaScript et de nouveaux ajouts comme TypeScript, la création de projets Node peut devenir une tâche ardue, impliquant la gestion de systèmes de génération et d'autres outils lourds qui enlèvent le plaisir des scripts de langage dynamique. De plus, le mécanisme de liaison à des bibliothèques externes est fondamentalement centralisé via le référentiel NPM, qui n'est pas conforme aux idéaux du Web.
« Nous pensons que le paysage de JavaScript et de l'infrastructure logicielle environnante a suffisamment changé pour qu'il soit utile de le simplifier. Nous recherchons un environnement de script amusant et productif qui peut être utilisé pour un large éventail de tâches ».
Vient alors Deno 1.0
Deno est un nouveau runtime pour exécuter JavaScript et TypeScript en dehors du navigateur Web.
Deno tente de fournir un outil autonome pour l'écriture rapide de fonctionnalités complexes. Deno est un seul fichier exécutable. Comme un navigateur Web, il sait récupérer du code externe. Dans Deno, un seul fichier peut définir un comportement arbitrairement complexe sans aucun autre outil.
Code JavaScript : | Sélectionner tout |
1 2 3 4 | import { serve } from "https://deno.land/std@0.50.0/http/server.ts"; for await (const req of serve({ port: 8000 })) { req.respond({ body: "Hello World\n" }); } |
Ici, un module serveur HTTP complet est ajouté en tant que dépendance sur une seule ligne. Il n'y a pas de fichiers de configuration supplémentaires, il n'y a pas d'installation à faire au préalable, il suffit de faire deno run example.js.
Comme pour les navigateurs, le code est exécuté par défaut dans un sandbox sécurisé. Les scripts ne peuvent pas accéder au disque dur, ouvrir des connexions réseau ou effectuer d'autres actions potentiellement malveillantes sans autorisation. Le navigateur fournit des API pour accéder aux caméras et aux microphones, mais les utilisateurs doivent d'abord donner leur autorisation. Deno fournit un comportement analogue dans le terminal. L'exemple ci-dessus échouera sauf si l'indicateur de ligne de commande --allow-net est fourni.
Deno veille à ne pas s'écarter des API JavaScript standardisées du navigateur. Bien sûr, toutes les API de navigateur ne sont pas pertinentes pour Deno, mais pour celles dont c’est le cas, Deno ne s'écarte pas de la norme.
Prise en charge de TypeScript de première classe
« Nous voulons que Deno soit applicable à un large éventail de domaines problématiques: des petits scripts unifilaires à la logique métier complexe côté serveur », indiquent les ingénieurs. À mesure que les programmes deviennent plus complexes, il est de plus en plus important d'avoir une certaine forme de vérification de type. TypeScript est une extension du langage JavaScript qui permet aux utilisateurs de fournir éventuellement des informations de type.
Deno prend en charge TypeScript sans outils supplémentaires. Le runtime est conçu avec TypeScript à l'esprit. La commande deno types fournit des déclarations de type pour tout ce qui est fourni par Deno. Les modules standard de Deno sont tous écrits en TypeScript.
Les Promises arrivent
Node a été conçu avant que JavaScript ne dispose du concept Promises ou async / await. L'équivalent de Node aux Promises était l'EventEmitter, sur lequel reposent d'importantes API, à savoir les sockets et HTTP. Mis à part les avantages ergonomiques de async / await , le modèle EventEmitter a un problème de contre-pression. Prenez un socket TCP, par exemple. Le socket émettrait des événements de « data » lorsqu'il recevait des paquets entrants. Ces callback « data » seraient émis de manière non contrainte, inondant le processus d'événements. Étant donné que Node continue de recevoir de nouveaux événements data, le socket TCP sous-jacent n'a pas de contre-pression appropriée, l'expéditeur distant n'ayant aucune idée que le serveur est surchargé et continuant d'envoyer des données. Pour atténuer ce problème, une méthode pause() a été ajoutée. Cela pourrait résoudre le problème, mais cela nécessitait du code supplémentaire; et comme le problème d'inondation ne se présente que lorsque le processus est très chargé, de nombreux programmes Node peuvent être inondés de données. Le résultat est un système avec une mauvaise latence de queue.
Dans Deno, les sockets sont toujours asynchrones, mais pour recevoir de nouvelles données, les utilisateurs doivent explicitement utiliser read(). Aucune sémantique de pause supplémentaire n'est nécessaire pour structurer correctement un socket de réception. Ce n'est pas unique aux sockets TCP. La couche de liaison de niveau le plus bas du système est fondamentalement liée aux Promises (que les ingénieurs appellent liaisons « ops »). Tous les callback Deno sous une forme ou une autre découlent de Promises.
Rust a sa propre abstraction Promises, appelée Futures. Grâce à l'abstraction « op », Deno facilite la liaison des Futures API de Rust aux promesses JavaScript.
API Rust
Le composant principal qui est proposé est l'interface de ligne de commande (CLI) Deno. La CLI est l’élément qui est en version 1.0 actuellement. Cependant, Deno n'est pas un programme monolithique, mais conçu comme une collection de crates Rust pour permettre l'intégration à différentes couches.
Le crate deno_core est une version très dénudée de Deno. Il n'a pas de dépendances sur TypeScript ni sur Tokio. Il fournit simplement une infrastructure opérationnelle et de ressources. Autrement dit, il fournit un moyen organisé de lier les Futures de Rust aux Promises JavaScript. La CLI est bien sûr entièrement construite sur deno_core.
Le crate rusty_v8 fournit des fixations Rust de haute qualité à l'API C ++ de V8. L'API essaie de faire correspondre le plus étroitement possible l'API C ++ d'origine. C'est une liaison à coût nul - les objets exposés dans Rust sont exactement l'objet que vous manipulez en C ++. (Les tentatives précédentes de liaisons Rust V8 ont forcé l'utilisation de poignées persistantes, par exemple.) Le crate fournit des binaires qui sont construits dans les...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.