Outre le runtime Deno, l’outil fournit également une liste de modules standard qui sont examinés par les responsables de Deno et dont le fonctionnement est garanti avec une version spécifique de Deno. Ils cohabitent avec le code source de Deno dans le référentiel denoland/deno. Ces modules standard sont hébergés sur deno.land/std et sont distribués via des URL comme tous les autres modules ES compatibles avec Deno.
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.
Pour justifier le projet Deno, les responsables déclarent : « 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.
« 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 ». Voici, ci-dessous, les nouveautés apportées à la version 1.9 de Deno.
Serveur web natif HTTP/2
Le serveur HTTP actuel de Deno, std/http, est implémenté en TypeScript pur sur des sockets TCP. Il présente une latence de queue étonnamment bonne malgré l'utilisation d'un serveur HTTP scripté. Mais le principal inconvénient de std/http est qu'il n'est compatible qu'avec HTTP/1.1, sans possibilité de passer facilement à HTTP/2.
« En fin de compte, nous ne voulons pas nous occuper de l'écriture de serveurs HTTP. HTTP est de moins en moins trivial et il existe déjà des serveurs HTTP bien implémentés en code natif. C'est pourquoi nous avons utilisé Hyper pour construire une nouvelle API de serveur HTTP/2 native à Deno », déclarent les responsables du projet Deno. La liaison améliore le débit de hello-world de 48 % par rapport au serveur HTTP std/http TypeScript pur. Pour l'instant, il est recommandé d’utiliser le paramètre –unstable.
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 | const body = new TextEncoder().encode("Hello World"); for await (const conn of Deno.listen({ port: 4500 })) { (async () => { for await (const { respondWith } of Deno.serveHttp(conn)) { respondWith(new Response(body)); } })(); } |
Appels de commande plus rapides dans Rust avec serde_v8
Dans les versions précédentes de Deno, les appels de commande suivaient un modèle de demande/réponse, codant leurs données dans des « charges utiles » personnalisées de ArrayBuffers. Historiquement, ces charges utiles utilisaient divers encodages, allant de JSON, flatbuffers à des encodages binaires personnalisés... Ce n'était pas seulement un goulot d'étranglement au niveau des performances, c'était aussi une source substantielle de complexité et de fragmentation.
Aaron O'Mullan, un des responsables du projet Deno, a suggéré qu'au lieu de faire des allers-retours entre ces formats binaires, JS et Rust, il serait plus efficace de sérialiser directement entre les valeurs v8 et Rust. Suite à cette idée et à un prototype rapide, serde_v8 est né. serde_v8 a pour but de fournir une bijection « efficace au maximum » ou « sans surcharge » entre les valeurs v8 et Rust tout en restant expressif et familier.
Prise en charge de l'URL Blob et amélioration de la fonction fetch
La version 1.9 de Deno introduit la prise en charge de blob : (également connues sous le nom d'URL d'objets). L'API pour créer et révoquer les URL blob est la même que dans le navigateur :
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 | const blob = new Blob(["Hello World!"]); const url = URL.createObjectURL(blob); console.log(url); // blob:null/7b09af21-03d5-461e-90a3-af329667d0ac const resp = await fetch(url); console.log(await resp.text()); // Hello World! URL.revokeObjectURL(url); |
Fonction de complétions dans le LSP
Dans cette version, Deno Language Server, l'outil qui permet d'utiliser les extensions d'éditeur pour Deno, a bénéficié de quelques nouvelles fonctionnalités et améliorations importantes. La version 1.9 de Deno apporte une amélioration et réintroduit la fonction de complétions d'importation de l’ancienne extension VS Code. Elle permet aux utilisateurs d'obtenir des compléments dans les déclarations d'importation. Le LSP offre des complétions pour les fichiers locaux, les fichiers déjà téléchargés dans votre cache DENO_DIR, et aussi des complétions de registre.
Pour activer les complétions pour le registre https://deno.land/x, ce le bout de code ci-dessous doit être ajouté aux paramètres du code VS (ou autre éditeur) :
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | { "deno": { "suggest": { "imports": { "hosts": { "https://deno.land": true } } } } } |
Les autocomplétions de registre sont actuellement proposées par https://deno.land/x. Il reste à espérer que d'autres registres mettent en œuvre le protocole de registre pour prendre en charge cette nouvelle fonctionnalité. En plus des nouvelles complétions d'importation, les fonctions LSP textDocument/foldingRange et textDocument/selectionRange qui permettent à un éditeur de fournir un meilleur accrochage du texte pendant la sélection, et un meilleur support pour le pliage et l'expansion des blocs de code, ont été également implémentées. Cette version comprend également de nombreuses corrections de bogues pour le LSP, notamment un bogue sur les systèmes Windows.
Listes d'autorisations pour --allow-env et --allow-run
Plusieurs paramètres d'autorisation de Deno acceptent des listes d'autorisations qui permettent de définir les autorisations d'un programme de manière très précise. Par exemple, --alow-read=/tmp n'accorde le droit de lecture qu'au répertoire ./tmp.
Avant la version 1.9, --allow-env et --allow-run étaient tous deux « tout ou rien », ce qui signifie qu'en passant ces paramètres, on obtenait respectivement un accès complet aux variables d'environnement et le lancement de sous-processus pour tout binaire sur le système. Avec Deno 1.9, on peut spécifier exactement à quelles variables d'environnement le programme devrait avoir accès, ou quels sous-processus le programme est autorisé à lancer :
Code : | Sélectionner tout |
1 2 | $ deno run --allow-env=DEBUG,LOG https://deno.com/blog/v1.9/env_permissions.ts $ deno run --allow-run=deno https://deno.com/blog/v1.9/run_permissions.ts |
En outre, Deno.permissions.query() permet désormais d'interroger les autorisations d'exécution de binaires spécifiques en utilisant le champ de commande :
a
Code : | Sélectionner tout |
wait Deno.permissions.query({ name: "run", command: "deno" });
Prompt de permission interactive
Actuellement, dans Deno, si vous exécutez un programme auquel il manque les paramètres d'autorisation appropriés, il affiche une erreur et se termine. Dans la version 1.9, nous avons ajouté le paramètre --prompt qui permet aux utilisateurs d'accorder les autorisations de manière itérative, au fur et à mesure qu'elles sont requises pendant l'exécution.
L'utilisation de --prompt est particulièrement utile lors de l'exécution de scripts uniques à partir d'Internet. Inutile de connaître toutes les permissions requises à l'avance, au lieu de cela, il est possible d’exécuter le script sans aucune permission et les accorder ou les refuser une par une comme demandé par le programme.
Support ALPN dans Deno.listenTls
Le protocole HTTP/2 est agnostique vis-à-vis des connexions. Cela signifie qu'il peut être utilisé sur un socket Unix, un socket TCP ou sur une connexion utilisant TLS. Les principaux navigateurs Web n'autorisent HTTP/2 sur les connexions TLS que si elles annoncent la prise en charge de HTTP/2 lors d’une « handshake »TLS. Cela se fait via l'extension TLS Application-Layer Protocol Negotiation, également connue sous le nom d'ALPN. Cette extension de handshakeTLS permet au serveur et au client TLS de négocier le protocole d'application qu'ils utiliseront pour communiquer sur la connexion TLS.
Sur le web, les deux protocoles d'application dominants sont HTTP/1.1 et HTTP/2. Ils portent les noms de protocole ALPN "http/1.1" et "h2" respectivement. Les navigateurs n'enverront des requêtes HTTP/2 qu'aux serveurs qui annoncent la prise en charge de HTTP/2. Si aucun protocole ALPN n'est répertorié, ou si seul "http/1.1" figure dans les protocoles ALPN, HTTP/1.1 sera utilisé. Jusqu'à présent, le serveur std/http ne supportait que HTTP/1.1, il n'était donc pas nécessaire de supporter ALPN sur les connexions TLS. Avec l'introduction de Deno.serveHttp dans cette version, cela a changé. Pour rendre possible le HTTP/2 complet dans Deno, nous avons maintenant ajouté la prise en charge de la spécification des protocoles ALPN à annoncer lors du démarrage d'un auditeur TLS avec Deno.listenTls. Voici, ci-dessous, un exemple de création d'un serveur HTTPS avec prise en charge complète de HTTP/2 :
const listener = Deno.listenTls({
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | port: 443, certFile: "./cert.pem", keyFile: "./key.pem", alpnProtocols: ["h2", "http/1.1"], }); for await (const conn of listener) { handleConn(conn); } async function handleConn(conn: Deno.Conn) { const httpConn = Deno.serveHttp(conn); for await (const { request, respondWith } of httpConn) { respondWith(new Response(`Responding to ${request.url}`)); } } |
Nouvelle option TypeScript par défaut useDefineForClassFields
Deno 1.9 apporte également une modification du tsconfig par défaut de Deno pour inclure l'option useDefineForClassFields : true. Cette option aligne la gestion des champs de classe par TypeScript sur la sémantique standard des scripts ECMA. Cette option ne peut pas être écrasée dans le code utilisateur.
Installation de Deno
Deno est livré sous la forme d'un exécutable unique sans aucune dépendance. Si Deno est déjà installé, vous pouvez passer à la version 1.9 en exécutant deno upgrade. Si vous installez Deno pour la première fois, vous pouvez utiliser l'une des méthodes énumérées ci-dessous :
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | # Utilisation de Shell (macOS and Linux): curl -fsSL https://deno.land/x/install/install.sh | sh # Utilisation de PowerShell (Windows): iwr https://deno.land/x/install/install.ps1 -useb | iex # Utilisation de Homebrew (macOS): brew install deno # Utilisation Scoop (Windows): scoop install deno # Utilisation Chocolatey (Windows): choco install deno |
Source : Deno
Et vous ?
Avez-vous déjà utilisé Deno ? Si oui, qu’en pensez-vous ? Si non, êtes-vous intéressés ?
Quelle utilité pourriez-vous lui trouver ?
Que pensez-vous des améliorations apportées à la version 1.9 de Deno ?
Voir aussi :
Deno passe en version 1.0. Le runtime pour exécuter JavaScript et TypeScript, tente de fournir un outil autonome pour l'écriture rapide de fonctionnalités complexes
Quels sont les coûts liés à l'utilisation de frameworks JavaScript pour le développement Web ? Une analyse des sites utilisant React, Vue.js ou Angular
Node.js 15 est disponible et apporte le support de npm 7, une implémentation expérimentale AbortController, ainsi qu'une mise à jour du moteur JavaScript V8 qui passe en version 8.6
State of JavaScript 2020 : TypeScript leader incontestable des déclinaisons de JavaScript, le typage statique devient la fonctionnalité la plus demandée et React reste le framework front-end dominant