❌

Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraĂźchir la page.

Deno 2.0 est lĂ 

Le temps oĂč Node.js rĂ©gnait en maĂźtre comme la solution incontournable pour exĂ©cuter du code JavaScript cĂŽtĂ© serveur est-il rĂ©volu ? En tout cas, il a aujourd’hui des challengers de taille comme Bun (qui pourrait lui aussi mĂ©riter une dĂ©pĂȘche) ou Deno. C'est donc de ce dernier qu'il sera question dans cette dĂ©pĂȘche, Ă  l'occasion de la sortie de sa version 2.0

Sommaire

Titre de l'image

Pour rappel

Deno est un runtime JavaScript et TypeScript. Il a vu le jour suite au constat de Ryan Dahl (crĂ©ateur aussi de Node.js), que Node avait des problĂšmes de conceptions, et qu'il Ă©tait nĂ©cessaire de repartir de zĂ©ro en tenant compte de l'expĂ©rience de Node pour ne pas refaire les mĂȘmes erreurs. Il imagine Deno comme un runtime avec un modĂšle de sĂ©curitĂ© par dĂ©faut plus strict. Les programmes Deno n'ont pas accĂšs au systĂšme de fichiers, au rĂ©seau ou Ă  l'environnement, sauf si on leur accorde explicitement ces permissions. Deno est Ă©crit en Rust, et se base sur le moteur JavaScript V8 de Google. Deno se distingue Ă©galement de Node en offrant la possibilitĂ© d'importer les dĂ©pendances via des URL, mettant en cache chaque module lors de l’importation pour amĂ©liorer la vitesse d’exĂ©cution.

La mascotte !

La premiĂšre chose notable quand on passe de Node.js Ă  Deno, c'est sa mascotte ! En effet, mĂȘme si Node.js possĂšde bien une petite tortue comme mascotte, celle-ci n'est utilisĂ©e nulle part ! Personnellement, j'ai toujours trouvĂ© bien plus chouettes les projets qui ont des petites bestioles comme mascotte (Mozilla, Tux 
). Et chez Deno, le dinosaure mascotte est omniprĂ©sent sur tout le site. Et en plus, Ă  l'occasion de la version 2.0, on peut habiller notre dino sur la home page du projet ! Et ça c'est cool ! Voici le mien, qui est en compagnie de Ferris, la mascotte officieuse de Rust !

Mon dino

Bon, comme je ne suis pas sĂ»r que tout le monde partage ma passion pour les mascottes, on va passer au cĂŽtĂ© plus technique ! đŸ€Ł

Deno 1.x, des dĂ©buts difficiles !

La version 1.0 sortie en mai 2020 a du mal Ă  se faire une place et reste dans l'ombre de son grand frĂšre. En effet, mĂȘme si Deno offre un grand lot de nouveautĂ©s et est plus sĂ©curisĂ© par dĂ©faut, la trĂšs large adoption de Node et le fait que les projets dĂ©veloppĂ©s pour Node ne sont pas forcĂ©ment compatibles avec Deno rend l’adoption de ce dernier difficile. De plus, l'utilisation de CDN plutĂŽt que d'installer les dĂ©pendances localement (dans le rĂ©pertoire node_modules) a certes de nombreux avantages, mais cela rend votre projet dĂ©pendant de disponibilitĂ© du rĂ©seau ou peut entraĂźner des problĂšmes de performances si le CDN est Ă©loignĂ© gĂ©ographiquement.

Les nouveautés de la version 2.0

Deno est désormais 100% compatible avec Node.js, et un gestionnaire de paquets officiel a vu le jour. Vous pouvez maintenant utiliser deno add et deno removepour ajouter ou retirer un paquet à votre projet.

Autour du projet Deno, JavaScript Registry (JSR) un dĂ©pĂŽt de paquets JavaScript universel !

Le registre NPM s'est construit autour de Node.js afin de gĂ©rer facilement les dĂ©pendances de nos projets. Il a donc Ă©tĂ© dĂ©veloppĂ© pour Node.js Ă  une Ă©poque oĂč Node Ă©tait la seule solution pour exĂ©cuter du code JavaScript cĂŽtĂ© serveur. En prĂšs de 15 ans, le registre NPM a rassemblĂ© un peu moins de 3 millions de paquets et a trĂšs largement rempli sa mission toutes ces annĂ©es. Mais aujourd'hui, la situation a changĂ©, il existe plusieurs runtimes pouvant exĂ©cuter du code JavaScript (ou TypeScript) cĂŽtĂ© serveur. Et du cĂŽtĂ© front-end, les frameworks se sont multipliĂ©s et sont devenus de plus en plus complexes et nĂ©cessitent aussi l'utilisation d'un gestionnaire de paquets. Un registre de paquets fondĂ© autour de Node.js uniquement est donc beaucoup moins pertinent qu'en 2010.
C'est donc pourquoi, Ă  l'initiative du projet Deno, un nouveau registre de paquets JavaScript et TypeScript universel pointe aujourd'hui le bout de son nez. Il s'agit donc de JSR (JavaScript Registry).

Dans JSR, quand on va sur la page d'un paquet, en haut Ă  droite, on a les logos des environnements compatibles avec le paquet :

Titre de l'image

Performances du runtime

Niveau performance, ça donne quoi ?

On voit souvent l'affirmation que Deno serait plus rapide que Node.js. Mais ça donne quoi en rĂ©alitĂ© ?

J'ai voulu faire un petit test sans prĂ©tentions pour voir ce que ça donne. Je voulais faire des tests plus poussĂ©s sur diffĂ©rents systĂšmes d'exploitation et architectures, mais par manque de temps, le test sera donc fait sur un seul systĂšme et un seul ordinateur et il s'agit d'un Mac
 Un comble pour LinuxFr.org, mais c'est l'ordinateur que j'avais Ă  disposition Ă  ce moment-lĂ . Mais sinon, je ne porte pas spĂ©cialement Apple dans mon cƓur, bien au contraire !

J'ai testĂ© l’exĂ©cution d'une mĂȘme API sur Node. et Deno pour voir les diffĂ©rences de performance entre ces solutions. Pour ce test, j'ai utilisĂ© une API Rest que j'ai dĂ©veloppĂ©e pour le site de la sociĂ©tĂ© AudioSoft. J'ai fait la mĂȘme requĂȘte POST 10 fois sur la mĂȘme route avec les mĂȘmes donnĂ©es. Il est important de prĂ©ciser que c'est la premiĂšre fois que je fais ce genre de tests, et que je ne fais peut-ĂȘtre pas tout dans les rĂšgles de l'art. Il y a des Ă©lĂ©ments extĂ©rieurs Ă  Node et Deno qui peuvent influencer les scores. Notamment, la base de donnĂ©es utilisĂ©e pour le test Ă©tait accessible via Internet, et des diffĂ©rences de dĂ©bit ont pu fausser les tests.

Test sur un MacBook Pro (2,6 GHz Intel Core i7 6 cƓurs, AMD Radeon Pro 5300M 4 Go Intel UHD Graphics 630 1536 Mo, 16 Go 2667 MHz DDR4) sous macOS Sonoma

Node: Le temps moyen pour exécuter le test de 126 millisecondes
Deno: Le temps moyen pour exécuter le test de 93 millisecondes

Performances du gestionnaire de paquets

Comme dit précédemment, Deno c'est aussi un gestionnaire de paquets. J'ai donc trouvé intéressant de tester les principaux gestionnaires de paquets sur différents environnements.
Pour ce test je me base sur la mĂȘme API Rest que pour le test prĂ©cĂ©dant, les dĂ©pendances Ă  installer pour cette API sont : bcrypt, body-parser, dotenv, express, jsonwebtoken, mariadb, multer, mysql2, nodemailer, et sequelize. Le test a Ă©tĂ© fait sur un MacBook Pro. Pour effectuer ce test, le cache des gestionnaires de paquets ont Ă©tĂ© nettoyĂ©s et les fichiers-verrous supprimĂ©s.

Avec NPM, l'installation a mis 10 secondes.

Avec Deno, l'installation a mis 1 seconde.

Avec Bun, l'installation a mis 3 secondes.

On voit trĂšs clairement que NPM est beaucoup plus lent que ses deux concurrents. L'Ă©cart est plus faible entre Deno et Bun. Mais Deno est bien le plus rapide des trois.

Avant de rĂ©aliser ce test, j'en ai effectuĂ© un en oubliant de nettoyer le cache et de supprimer package-lock.json. Les rĂ©sultats Ă©taient alors 8 secondes pour NPM, 5 secondes pour Deno et 4 secondes pour Bun. Il est logique de constater que NPM est plus rapide, en revanche, je trouve surprenant que Deno et Bun aient Ă©tĂ© ralentis. Il est possible que les gestionnaires de paquets aient parcouru package-lock.json pour garder les versions prĂ©sentes dans ce fichier, ce qui les aurait tous les trois ralentis. Et NPM a peut-ĂȘtre pu bĂ©nĂ©ficier de son cache (car je l'utilise bien plus que les deux autres sur mon ordinateur), Deno et Bun eux n'avaient peut-ĂȘtre pas grand-chose dans leurs caches, ont donc Ă©tĂ© ralentis. Il est donc important de supprimer les lockfile en cas de migration d'un projet.

Comme je le disais plus haut, c'est la premiĂšre fois que j'effectue ce genre de test comparatif. Si vous avez des conseils sur les bonnes mĂ©thodes pour faire des tests plus fiables, ça m’intĂ©resse !

Deno 2.1 est lĂ 

Étant donnĂ© que j'ai mis environ un siĂšcle pour rĂ©diger cette dĂ©pĂȘche, Deno 2.1 est sortie entre temps ! đŸ€Ł
Je vous liste donc les principales nouveautĂ©s apportĂ©es Ă  la version 2.1 sans les commenter 😉

  • Support natif de WebAssembly (Wasm) : Il est dĂ©sormais possible d'importer directement des modules Wasm, simplifiant leur utilisation et amĂ©liorant les performances.
  • Version Long Term Support (LTS) : Deno 2.1 inaugure la premiĂšre version LTS, garantissant des correctifs de bugs et des amĂ©liorations de performance pendant
 Six mois
 On n'est pas encore aux 30 mois des versions LTS de Node.js
 Cela viendra peut-ĂȘtre plus tard. 🙂
  • Commande deno init --npm vite : Cette commande simplifie la crĂ©ation de nouveaux projets en utilisant des outils comme Vite, en automatisant l'initialisation et en rĂ©duisant la configuration manuelle.
  • Gestion des dĂ©pendances : Introduction de la commande deno outdated pour gĂ©rer les mises Ă  jour des dĂ©pendances JSR et npm.

Conclusion

Si vous ĂȘtes dĂ©veloppeur Node.js, je vous conseille de vous intĂ©resser Ă  Deno, et mĂȘme Ă  Bun. Je ne sais pas si ces deux runtime sont totalement prĂȘts pour des projets en production (par exemple, Deno 2.1 n'a que 6 mois de durĂ©e de vie, ce qui est plutĂŽt contraignant pour les serveurs.). Mais peut-ĂȘtre que dans un futur proche, il sera cohĂ©rent de migrer vers l'un de ces deux-lĂ .

Commentaires : voir le flux Atom ouvrir dans le navigateur

❌