Discussion :

[Stéphane le calme]

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

Les langages dynamiques sont des outils utiles. Les scripts permettent aux utilisateurs de lier rapidement et succinctement des systèmes complexes et d'exprimer des idées sans se soucier de détails tels que la gestion de la mémoire ou les builds systèmes. Ces dernières années, des langages de programmation comme Rust et Go ont rendu beaucoup plus facile la production de code machine natif sophistiqué; ces projets sont des développements incroyablement importants dans l'infrastructure informatique.

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 - Visualiser dans une fenêtre à part

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 actions Github CI, mais elle permet également aux utilisateurs de compiler V8 à partir de zéro et d'ajuster ses nombreuses configurations de construction. Tout le code source V8 est distribué dans le crate lui-même.

Enfin, rusty_v8 tente d'être une interface sûre. « Elle n'est pas encore sûre à 100%, mais nous nous en approchons. Pouvoir interagir avec une VM aussi complexe que V8 de manière sûre est assez étonnant et nous a permis de découvrir de nombreux bogues difficiles dans Deno lui-même ».

Limites

Les ingénieurs rappellent qu'il est important de comprendre que Deno n'est pas un fork de Node - c'est une implémentation complètement nouvelle. Deno est en cours de développement depuis seulement deux ans, tandis que Node est en cours de développement depuis plus d'une décennie. Étant donné le montant de l'intérêt pour Deno, ils prévoient qu'il continuera d'évoluer et de mûrir.

« Pour certaines applications, Deno peut être un bon choix aujourd'hui, pour d'autres pas encore. Cela dépendra des exigences. Nous voulons être transparents sur ces limitations pour aider les gens à prendre des décisions éclairées lorsqu'ils envisagent d'utiliser Deno ».

Compatibilité

Malheureusement, de nombreux utilisateurs trouveront un manque frustrant de compatibilité avec les outils JavaScript existants. Deno n'est pas compatible, en général, avec les packages Node (NPM). Une couche de compatibilité naissante est en cours de création ici mais elle est loin d'être terminée.

Bien que Deno ait adopté une approche stricte pour simplifier le système de modules, Deno et Node sont finalement des systèmes assez similaires avec des objectifs similaires. Au fil du temps, les auteurs s'attendent à ce que Deno puisse exécuter de plus en plus de programmes Node prêts à l'emploi.

Performances du serveur HTTP

« Nous suivons en permanence les performances du serveur HTTP de Deno. Un serveur HTTP hello-world Deno fait environ 25 000 requêtes par seconde avec une latence maximale de 1,3 milliseconde. Un programme Node comparable fait 34k requêtes par seconde avec une latence max plutôt erratique entre 2 et 300 millisecondes.

« Le serveur HTTP de Deno est implémenté en TypeScript au-dessus des sockets TCP natifs. Le serveur HTTP de Node est écrit en C et exposé en tant que liaisons de haut niveau à JavaScript. Nous avons résisté à l'envie d'ajouter des liaisons de serveur HTTP natif à Deno, car nous voulons optimiser la couche socket TCP, et plus généralement l'interface op.

« Deno est un bon serveur asynchrone et 25 000 requêtes par seconde sont largement suffisantes pour la plupart des applications. (Si ce n'est pas le cas, JavaScript n'est probablement pas le meilleur choix.) En outre, nous nous attendons à ce que Deno présente généralement une meilleure latence de queue en raison de l'utilisation omniprésente des Promises. Cela dit, nous pensons qu'il y a plus de gains de performances à gagner dans le système, et nous espérons y parvenir dans les prochaines versions ».

Source : Deno 1.0

Et vous ?

Avez-vous déjà entendu parler de Deno ?
L'avez-vous déjà utilisé ? Si oui, qu’en pensez-vous ? Si non, êtes-vous intéressé ?
Quelle utilité pourriez-vous lui trouver ?
Que pensez-vous des limites de Deno ?

[grunk]

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

C'est clair qu'aujourd'hui mettre en place un projet JS c'est juste un enfer en grosse partit à cause l'absence de réel standard. Il faut faire son fichier package.json , puis si on fait un typescript un tsconfig.json. Il faut ensuite configurer un bundler (déjà le choisir ..) puis un linter ...
La où a peut près tous les autres langage , il suffit de faire fichier > nouveau projet et tout est prêt.

Deno semble répondre à cette problématique en embarquant toute la suite d'outil et c'est franchement pas du luxe.

Par contre j'adhère pas trop a sa vision sur les imports. Je trouve ca quand même pas mal d'avoir une seule source de confiance (en l'occurence npm). Qu'on puisse importer un simple fichier très bien par contre je vois mal un projet importer plein de dépendancse d'url différentes. Rien ne garantie que ce qui est derrière l'url va pas changer du jour au lendemain. npm apporte certaines sécurités sur la question.

Le projet est intéressant , est ce qu'il va réussir à détroner son prédécessur ... c'est pas gagné. node est maintenant vraiment très implanté. Il aurait peut être été plus judicieux de partir sur un "node2" et laisser mourir petit à petit l'actuel.

[Marco46]

Par contre j'adhère pas trop a sa vision sur les imports. Je trouve ca quand même pas mal d'avoir une seule source de confiance (en l'occurence npm). Qu'on puisse importer un simple fichier très bien par contre je vois mal un projet importer plein de dépendancse d'url différentes. Rien ne garantie que ce qui est derrière l'url va pas changer du jour au lendemain. npm apporte certaines sécurités sur la question.

Il te suffit d'héberger tes dépendance sur ton propre serveur web et le problème est réglé. L'avantage de la solution de Ryan Dahl c'est qu'elle est tout aussi souple et elle te libère de l'obligation d'utiliser le registre npm (cf le talk à la base de deno).

[Doksuri]

[mode_sodium]#JS c'est naze, et puis voir un gars qui lit un powerpoint en begayant c'est nul[/mode_sodium]

[grunk]

Il te suffit d'héberger tes dépendance sur ton propre serveur web et le problème est réglé. L'avantage de la solution de Ryan Dahl c'est qu'elle est tout aussi souple et elle te libère de l'obligation d'utiliser le registre npm (cf le talk à la base de deno).

Vu le nombre de projet maintenu que j'ai et les dépendances associées, je me vois mal me substituer a npm et vérifier quasi quotidiennement si tout est bien a jour.
Tout le monde fonctionne avec un dépôt centralisé (PHP,python,java,c++).
Après sa solution ne veux pas dire que c'est pas possible, c'est d'ailleurs le cas avec la "librairie standard", mais c'est la façon dont il le vend.
D'ailleurs aujourd'hui tu peux tout a fait ne pas utiliser le registre officiel de npm et de faire le tiens en interne si ça te chante
Le gros avantage d'un fichier comme package.json c'est quand même qu'en 1 coup d'oeil tu connais les dépendances nécessaire a un projet.

[Invité]

Tout le monde fonctionne avec un dépôt centralisé (PHP,python,java,c++).

Pour python, j'imagine que c'est pypi (même s'il existe aussi conda) mais pour c++ c'est quoi le dépôt centralisé ?

[Marco46]

Vu le nombre de projet maintenu que j'ai et les dépendances associées, je me vois mal me substituer a npm et vérifier quasi quotidiennement si tout est bien a jour.

Tu veux vérifier que https://unpkg.com/react@16.7.0/umd/react.production.min.js est toujours la version 16.7.0 ? Je comprends pas trop le soucis en fait.

T'as besoin de la dépendance toto@x.y.z ben tu l'as met sur ton serveur web.

Le gros avantage d'un fichier comme package.json c'est quand même qu'en 1 coup d'oeil tu connais les dépendances nécessaire a un projet.

Ça je suis d'accord ça rend plein de services (meta données, url des docs, etc ...) et je suis curieux de voir comment ça va se pratiquer concrètement sur les projets deno mais je vois pas tellement ce qui empêche d'avoir un seul fichier js contenant toutes les urls et les imports pour les réexposer ensuite au reste de ton appli.

[grunk]

Pour python, j'imagine que c'est pypi (même s'il existe aussi conda) mais pour c++ c'est quoi le dépôt centralisé ?

Conan ou vcpkg , y'en a pas un "officiel" où on est sur de tout trouver mais les 2 sont plutôt complet tant qu'on reste dans les lib connues

Tu veux vérifier que https://unpkg.com/react@16.7.0/umd/r...duction.min.js est toujours la version 16.7.0 ? Je comprends pas trop le soucis en fait.

Nonj je veux vérifier que c'est la dernière à jour et qu'il n'existe pas une 16.7.1 par exemple.
Un peu l'équivalent d'un npm audit et/ou npm update.

J'ai pas la chance ,comme beaucoup, d'avoir un projet que je livre et que j'oublie pour toujours. A minima c'est 5 ans de maintenance et plus de 10 pour certains. Je suis donc obligé de les maintenir à jour très régulièrement.

[Marco46]

C'est npm outdated.

Oui effectivement je sais pas comment ce type de problématiques peuvent être automatisées.