Sortie de Deno 1.0

Posté par (page perso) . Édité par Davy Defaud, ted et Ysabeau. Modéré par ZeroHeure. Licence CC by-sa.
Tags :
31
15
mai
2020
JavaScript

Deno est un possible successeur à Node.js. Ryan Dahl, qui est l’auteur à l’origine de Node.js, a présenté lors d’une conférence il y a deux ans une liste de dix choses qu’il regrette à propos de Node.js. À partir de cette liste, il a voulu créer un nouveau moteur d’exécution de script qui tourne en dehors du navigateur mais qui en reprend les conventions. Le projet s’appelle Deno et il vient d’atteindre la version 1.0.

Logo de Deno

D’un point de vue technique, Deno est codé en Rust et repose toujours sur V8. Le code exécuté est désormais du TypeScript et le fonctionnement est plus proche d’un navigateur Web. Par exemple, il utilise les mêmes API que celles fournies par les navigateurs quand cela fait sens, plutôt que de proposer des API propres (p. ex. fetch plutôt que le http.get de Node.js pour faire des requêtes HTTP).

Avant d’aller plus loin, voici le très attendu exemple de serveur Web qui répond avec un Hello World :

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" });
}

On peut tout de suite remarquer que Deno prend le même chemin que Go pour la gestion des dépendances, à savoir une approche décentralisée et qui ne nécessite pas d’outils tiers comme npm. On peut directement importer un fichier TypeScript venant d’Internet.

Pour celles et ceux que ça ferait bondir sur leur chaise vis‑à‑vis de la sécurité, la réponse tient en deux parties :

  1. Deno a une approche bac à sable par défaut : par défaut, un script ne peut pas accéder au système de fichiers ou à Internet (un peu comme dans un navigateur), et l’utilisateur doit explicitement passer une option comme --allow-net pour donner la permission ;
  2. Deno a un système de cache qui fait que l’on peut faire fonctionner un script en téléchargeant une première fois les dépendances, en les vérifiant, et elles ne bougeront plus ensuite tant que les URL du script ne bougeront pas ; il est également possible de faire du vendoring facilement (il suffit de republier les dépendances sur un serveur Web que l’on contrôle).

Dans les différences avec Node.js, on peut également citer l’utilisation des Promise à la place des callbacks, souvent utilisées via async/await. Cela va notamment régler le problème de back‑pressure qui avait conduit à rendre complexe les API de Node.js (EventEmitter, fonction pause à appeler manuellement, etc.).

Ryan Dahl liste quelques limitations connues de Deno :

  • Deno est encore très jeune (2 ans) et va continuer à évoluer assez rapidement (là où Node.js est beaucoup plus stable) ;
  • Deno fournit un module TypeScript de comptabilité avec les API de Node.js pour aider au portage, mais ce module est encore loin d’être complet et n’est pas suffisant en l’état pour profiter des nombreux paquets npm qui dépendent souvent de ces API ;
  • les performances du serveur HTTP ne dépassent pas celles de Node.js (légèrement moins de requêtes par seconde mais une meilleure latence moyenne) ;
  • le typage statique de TypeScript est très lent (une piste évoquée est de réécrire tsc en Rust) ;
  • il n’y a pas encore d’interface stable pour permettre l’écriture de greffons ou d’extensions ;
  • enfin, les usages et bonnes pratiques autour de Deno restent à découvrir.

Aller plus loin

  • # L'écosystème JavaScript était trop simple

    Posté par . Évalué à 10 (+21/-0).

    Rajoutons encore un nouvel outil incompatible avec les autres !

    Je vois déjà arriver le DenoHub, le DenoPM, les modules node2deno, deno2node, denowebpackfrombabelnodets…

    PS : J'ai le droit on est vendredi :P

    • [^] # Re: L'écosystème JavaScript était trop simple

      Posté par . Évalué à 10 (+11/-0).

      Mauvaise langue, va!
      C'est pas parce que c'était trop simple.
      Tout le monde sait que l'écosystème JS évolue sur la base d'une révolution aux 2ans.

      Node.js avait donc déjà dépassé son espérance de vie hype!

      --------> [ ]

      • [^] # Re: L'écosystème JavaScript était trop simple

        Posté par (page perso) . Évalué à 10 (+13/-0).

        On sait tous que le monde JS n'existe plus car bientôt remplacé par le monde "ES.Next", où les performances et les architectures de pointes associées, vont amener l’écosystème Web à un niveau jamais atteint d'excellence.
        Les dernières études montrent que l'architecture se montrera capable de choses surprenantes et inatteignables pour "l'ancien monde". En effet, sur un cluster de machines virtuelles, chaque fonctionnalité sera déployée en tant que container muni d'un compilateur JIT haute performance. Le tout redondé et auto-configuré par un ordonnanceur de type 4.
        Une telle architecture pourra permettre de gérer jusqu'au 1 million de requêtes HTTP/2 par an avec une garantie de traitement des requêtes porté à 99.9% avec seulement 5 serveurs!

      • [^] # Re: L'écosystème JavaScript était trop simple

        Posté par . Évalué à 3 (+0/-0).

        Tout le monde va passer à WASM exécuté dans des VM à microkernel, comme ça on pourra avoir du code deno et node.js et go en même temps dans le backend et le frontend. Joie.

        "La première sécurité est la liberté"

    • [^] # Re: L'écosystème JavaScript était trop simple

      Posté par (page perso) . Évalué à 10 (+10/-1).

      Pareil, en lisant ça, je venais juste de me dire "et encore une réécriture de plus à prévoir pour notre base de code". Entre les version d'Angular, SVG quelquechose et node, on passe notre temps à réécrire la même chose juste pour rester compatible avec le code actuel… Depuis que j'ai vu le dev javascript, j'aime éperdument C/C++!

      • [^] # Re: L'écosystème JavaScript était trop simple

        Posté par . Évalué à 5 (+5/-1). Dernière modification le 17/05/20 à 16:05.

        En tant que dev Javascript, j'ai du mal à comprendre cette critique.

        Pourquoi est-ce que vous voulez réécrire tous le code actuel dès qu'un nouveau framework sort ? Ou alors pourquoi vous ne le faites pas en C++ ?

        Il y a des tonnes de framework et librairies en C/C++, bien plus qu'en JS. C'est pas parce que Dino existe que soudainement, NodeJs va s'arrêter de fonctionner. De même que les sites utilisant Angular 1, Backbone.js ou même jQuery sans framework, sont toujours fonctionnels.

        • [^] # Re: L'écosystème JavaScript était trop simple

          Posté par (page perso) . Évalué à 9 (+8/-0).

          Pourquoi est-ce que vous voulez réécrire tous le code actuel dès qu'un nouveau framework sort ?

          En fait, on ne veux pas forcément tout réécrire dès qu'un nouveau framework sort, mais plutôt que dès que l'on veux implémenter une nouvelle fonctionnalité (par exemple l'export en PDF), il s'avère que nos framework sont obsolètes, que ce que l'on veut faire va alors dépendre d'une bibliothèque JS qui n'est plus mise à jour, donc qu'il vaudrait mieux commencer par porter notre application vers les frameworks actuels avant d'ajouter la fonctionnalité en question. Et comme faire du javascript n'est pas le cœur de notre métier (pour parler en manager) et que nous ne demandons de nouvelles fonctionnalités que de façon irrégulière (en fait, quand nous trouvons un peu d'argent pour cela, donc au plus une fois par an), nous utilisons toujours un framework obsolète…

          Peut-être un mot sur notre application: nous sommes un institut de recherche sur la neige et les avalanches (www.slf.ch) et nous avons fait développer une application de visualisation des profiles de neige (structure stratigraphique du manteau neigeux, sous forme de couches ayant diverses propriété: densité, forme et taille des grains, température, dureté, etc). Cette application est aussi bien utilisée pour visualiser des résultats de simulation numérique que des mesures sur le terrain et permet maintenant d'entrer des données mesurées sur le terrain. Afin que tous puissent en bénéficier, nous nous basons sur des standards internationaux (représentation graphique standardisée, format XML standardisé) et nous avons choisis de faire cette application en javascript qui tourne entièrement dans le navigateur (le serveur ne fait que servir le JS, donc ceux qui utilisent notre serveur ne risquent pas de le surcharger!) et tout en Open Source (AGPL). L'application et sa forge se trouvent d’ailleurs sur https://niviz.org/.

          En C++ nous aurions moins ce problème, mais comme il s'agit d'un application qui tourne entièrement dans le navigateur (et pas du tout sur le serveur), ce n'est pas possible… Mais je dois bien avouer que depuis que je vois un peu mieux comment l'écosystème JS fonctionne, je me demande si nous n'aurions pas mieux fait de faire une application lourde… (en même temps, avec la version web il suffit aux utilisateurs d'aller sur https://run.niviz.org pour travailler avec leurs données ou entrer de nouveaux profils, sans rien à installer, ce qui est très confortable).

          Mathias

        • [^] # Re: L'écosystème JavaScript était trop simple

          Posté par (page perso) . Évalué à 4 (+2/-1).

          Pourquoi est-ce que vous voulez réécrire tous le code actuel dès qu'un nouveau framework sort ? Ou alors pourquoi vous ne le faites pas en C++ ?

          Parce qu'il a fallu 400jh pour compiler le framework.

          Incubez l'excellence sur https://linuxfr.org/board/

  • # Trolldi, on peut ?

    Posté par (page perso) . Évalué à 9 (+7/-0).

    import { serve } from "https://deno.land/std@0.50.0/http/server.ts";

    et

    par défaut, un script ne peut pas accéder au système de fichiers ou à Internet

    Il n'y aurait pas une petite contradiction, là ?

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: Trolldi, on peut ?

      Posté par . Évalué à 5 (+4/-0).

      C'est coupé de l'article.

      The above example will fail unless the --allow-net command-line flag is provided.

      Il faut utiliser un petit paramètre pour que l'exemple marche.

      • [^] # Re: Trolldi, on peut ?

        Posté par . Évalué à 7 (+5/-0).

        ça va créer de mauvaises pratique.

        Si pour charger des dépendances, et tous les codes ont des dépendances, il faut autoriser l'accès à tout internet, c'est dommage.

        J’espère qu'il y a des droits plus fin, genre --allow-net:domain.net

        • [^] # Re: Trolldi, on peut ?

          Posté par (page perso) . Évalué à 6 (+4/-0).

          J’espère qu'il y a des droits plus fin, genre --allow-net:domain.net

          Il y aura --allow-net:github.com. :)

          Adhérer à l'April, ça vous tente ?

        • [^] # Re: Trolldi, on peut ?

          Posté par . Évalué à 4 (+2/-0).

          J’espère qu'il y a des droits plus fin, genre --allow-net:domain.net

          Tu gère comment la transitivité ? Tu as une bibliothèque sur un domaine A qui tire une dépendance sur le domaine B (et pour le fun dans la version suivante cette dernière passer sur le domaine C ou A).

          • [^] # Re: Trolldi, on peut ?

            Posté par . Évalué à 2 (+0/-0).

            En autorisant A à tirer ses dépendances ? Avec limitation possible de la profondeur (ex : avec une profondeur de 3, A peut tirer B et B peut tirer C. Mais C ne peut rien tirer qui vienne d'ailleurs que A, B ou C. Une profondeur de 0 équivalant à refuser tout ce qui vient d'Internet) ?

  • # un s qui manque

    Posté par . Évalué à 1 (+0/-0).

    Deno a un système de cache qui fait que l’on peut faire fonctionner un script en téléchargeant une première fois les dépendances, en les vérifiant, et elles ne bougeront plus ensuite tant que les URL du script ne bougeront pas ; il est également possible de faire du vendoring facilement (il suffit de republier les dépendances sur un serveur Web que l’on contrôle).

    Surtout, ne pas tout prendre au sérieux !

  • # Regrets

    Posté par . Évalué à 10 (+15/-0).

    «
    10 choses que je regrette à propos de Node.js :
    - Node.js 
    »

  • # Typescript

    Posté par . Évalué à 4 (+3/-0).

    Petite correction. L'usage de Typescript est encouragée, pas obligatoire.

    Deno is a new runtime for executing JavaScript and TypeScript outside of the web browser.

    C'est juste que l'auteur a souhaité avoir un vrai support de Typescript et veut que l'on l'utilise en priorité.

  • # node et deno sont dans un bateau

    Posté par . Évalué à 6 (+5/-0).

    Tout le monde aura remarqué que deno est le verlan de node.

  • # Tout est css...

    Posté par . Évalué à 3 (+2/-0).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.