Deno vient de sortir sa version 2.9, et le contenu est costaud : un mode desktop pour créer des applis natives, une migration quasi automatique depuis npm/pnpm/yarn/Bun, et des perfs qui ont carrément doublé sur certains points. Mais avant de parler de la 2.9, il faut que je t'explique pourquoi j'ai commencé à m'intéresser à Deno en premier lieu — spoiler : non, je n'ai pas largué Node.js, je continue de l'utiliser sur mes projets. Mais Deno a fini par prendre une vraie place à côté.
Il y a quelques mois, je codais tranquillement sur un projet perso avec Node.js, comme d'habitude, comme tout le monde en fait. Et puis à un moment, j'ai eu cette envie assez classique chez un dev : tester autre chose, sortir un peu de ma zone de confort. Je me suis mis à fouiller de mon côté, et je suis tombé sur Deno. Ma réaction sur le moment : "encore un runtime JS de plus, on va me lâcher avec ça". Moi le premier, j'avoue, j'étais sceptique. Sauf que j'ai fini par creuser un peu, et là, gros palier de retournement de veste.
Pourquoi je voulais découvrir Deno, à la base
Soyons honnêtes : au départ, ma curiosité n'avait rien de stratégique. J'avais juste envie de comprendre pourquoi ce runtime, créé par Ryan Dahl (oui, le créateur de Node.js lui-même, excusez du peu), attirait autant de monde alors que Node tourne déjà sur à peu près toute la planète.
Ce qui m'a interpellé au début, c'est le côté "tout est inclus" : TypeScript nativement supporté sans configuration de ouf, un système de permissions explicite (par défaut, un script Deno n'a accès ni au réseau, ni au disque, ni à l'environnement — il faut lui donner l'autorisation), et une compatibilité avec les standards du Web plutôt qu'avec des APIs maison. Bref, une philosophie assez différente de Node, plus proche de ce qu'on ferait tourner directement dans un navigateur.
L'histoire vraie : pourquoi Ryan Dahl a quitté Node.js pour créer Deno
Petite enquête, parce que la légende autour de Deno mérite d'être un peu dépoussiérée avec de vraies sources plutôt qu'avec des raccourcis.
Ryan Dahl a créé Node.js et l'a rendu public le 27 mai 2009. Il l'a porté seul pendant près de trois ans, avant d'annoncer en janvier 2012 qu'il se retirait du projet pour se consacrer à d'autres recherches, laissant les clés à Isaac Z. Schlueter, le créateur de npm. Sa sortie officielle à l'époque, plutôt sobre : il restait employé chez Joyent en tant que conseiller, mais arrêtait de gérer la correction quotidienne des bugs.
Ce qu'on oublie souvent, c'est que ce départ n'avait rien d'un clash ni d'une dispute publique avec la communauté. À l'époque, Dahl formule ça comme un choix de carrière assez classique : passer à autre chose après trois ans intenses sur un même projet.
La suite est plus intéressante. Six ans après avoir quitté Node, en juin 2018, Dahl remonte sur scène à la JSConf EU pour une conférence devenue culte : "10 Things I Regret About Node.js" ("10 choses que je regrette à propos de Node.js"). C'est là, et pas en 2012, qu'il expose vraiment ce qui le dérangeait dans le projet qu'il avait lui-même créé — et c'est cette conférence qui débouche, dans les dernières minutes, sur l'annonce publique de Deno.
Parmi les regrets qu'il détaille, factuellement :
- Les Promises abandonnées trop tôt. Il les avait ajoutées à Node dès juin 2009, avant de les retirer en février 2010. Un choix qu'il juge, avec le recul, avoir freiné l'adoption d'async/await pendant des années.
- La sécurité, son plus gros regret côté conception. Par défaut, un programme Node a un accès total à la machine — disque, réseau, variables d'environnement — sans qu'aucune permission ne soit demandée. Dahl explique qu'il aurait pu s'appuyer sur le bac à sable déjà présent dans V8 pour construire un vrai modèle de permissions, et qu'il ne l'a pas fait à l'époque.
- Le système de build GYP. Node a hérité de cet outil depuis Chrome, qui l'a lui-même abandonné depuis pour un autre système — laissant Node comme quasi seul utilisateur restant d'un outil qu'il qualifie lui-même d'expérience pénible pour les devs.
- package.json et la centralisation de npm. En intégrant npm directement dans la distribution de Node, Dahl estime avoir contribué à créer un registre central et privé qui n'a jamais été strictement nécessaire.
- node_modules, qu'il décrit comme ayant massivement compliqué l'algorithme de résolution des modules, en s'éloignant des standards du navigateur.
Et c'est là que le lien avec Deno devient limpide : chaque regret de cette liste trouve une réponse directe dans la conception de Deno. Le modèle de permissions explicite ? Réponse frontale au regret sécurité. Les imports par URL plutôt qu'un node_modules généré automatiquement ? Réponse au regret module. Le support natif de TypeScript ? Une manière de repartir sur des bases qu'il jugeait plus saines, plutôt que d'empiler les correctifs sur un système qu'il ne pouvait plus changer une fois Node adopté à grande échelle.
Deno n'est donc pas né d'une rupture brutale avec Node.js, mais d'un retour d'expérience assumé, six ans après son départ du projet, sur ce qu'il referait différemment s'il avait la conception à refaire.
Ce qui m'a fait ajouter Deno à côté de Node.js
Pendant longtemps, je restais sur Node par flemme, tout simplement — l'écosystème est énorme, tout le monde l'utilise, pourquoi changer une équipe qui gagne ? Sauf que plusieurs trucs ont fini par faire pencher la balance sur certains projets :
- La sécurité par défaut. Sur Node, un
npm installun peu louche peut lire ton disque ou envoyer des données sans que tu t'en rendes compte. Sur Deno, un script n'a aucun accès tant que tu ne le lui donnes pas explicitement avec des flags comme--allow-netou--allow-read. - Zéro configuration pour TypeScript. Fini les
tsconfig.jsonà rallonge et les build steps juste pour lancer un script. - Un seul binaire. Avec
deno compile, tu obtiens un exécutable autonome, sans avoir à traîner unnode_modulesde 400 Mo derrière toi.
Est-ce que ça veut dire que je jette Node.js à la poubelle ? Absolument pas, je continue de l'utiliser sur pas mal de mes projets, notamment tout ce qui tourne déjà en prod et que je n'ai aucune raison de bousculer. Mais pour certains nouveaux trucs — scripts perso, prototypes, ou même des bouts de projets Workyt — Deno s'est installé naturellement à côté.
deno desktop : la grosse nouveauté de la 2.9
Et c'est là que la version 2.9, sortie fin juin 2026, tombe à pic. La star de cette release, c'est deno desktop, une commande qui permet de créer des applications de bureau natives directement à partir de tes technos web habituelles — sans passer par Electron et sans installer dix mille dépendances.
Concrètement, tu pointes deno desktop vers ton script (ou même vers un projet Next.js, Astro, Remix, SvelteKit...), et Deno se charge de compiler le tout dans une fenêtre native, avec l'interface qui tourne dans une webview et ta logique qui tourne côté Deno. Résultat : un seul binaire distribuable, que ce soit un .exe, un .dmg ou un .AppImage selon la plateforme.
L'appli embarque aussi des APIs natives pour gérer les fenêtres, un système d'icône dans la barre système (Deno.Tray), et même un auto-updater intégré. Alors oui, la fonctionnalité est encore expérimentale à ce stade, mais franchement, ça sent la fin programmée d'Electron pour pas mal de petits projets.
Migrer depuis Node en deux commandes
L'autre gros morceau de cette 2.9, c'est la facilité de migration depuis npm, pnpm, yarn ou Bun. Et là, Deno a clairement écouté les retours : plus besoin de tout réécrire, deno install lit directement ton lockfile existant (package-lock.json, pnpm-lock.yaml, yarn.lock...) et reprend exactement les mêmes versions, sans re-résolution ni mise à jour surprise.
Même les workspaces pnpm, qui posaient problème avant, sont maintenant pris en charge automatiquement. Et pour les outils qui appellent directement le binaire node en interne (coucou Next.js et son Turbopack), Deno place un faux binaire de remplacement sur le PATH qui fait la traduction toute seule. Autant dire que la barrière à l'entrée pour tester Deno sur un projet Node existant vient de s'effondrer.
Des perfs qui donnent presque envie de tout réécrire
Les chiffres de perf de cette version sont assez impressionnants. Un "hello world" démarre environ deux fois plus vite qu'en version 2.8 (17 ms contre 34 ms), et surtout, la consommation mémoire sous charge a été divisée par plus de deux — jusqu'à trois fois moins sur certains scénarios avec de grosses réponses.
Côté débit HTTP, Deno.serve gagne aussi en vitesse, aidé par un nouveau moteur HTTP/1.1 écrit directement en Rust plutôt qu'en JavaScript. Un poil geek comme détail, mais concrètement ça veut dire que tu peux faire tourner plus de serveurs sur la même machine sans qu'elle transpire.
Sécurité, tests, et tout le reste
Cette version pousse aussi le curseur sécurité un cran plus loin, avec un âge minimum de dépendance activé par défaut : toute nouvelle version d'un paquet npm doit attendre 24h avant de pouvoir être installée, histoire de laisser le temps à la communauté de repérer une éventuelle version compromise (ça arrive plus souvent qu'on ne le pense).
Le côté tests n'est pas en reste non plus : snapshot testing intégré, tests paramétrés avec Deno.test.each, retries automatiques pour les tests flaky, et sharding pour répartir une suite de tests sur plusieurs machines en CI. Bref, ce qui obligeait avant à ajouter Vitest ou Jest par-dessus est maintenant nativement dans le runtime.
Sans oublier la compatibilité Node.js qui grimpe jusqu'à la version 26, ce qui ferme encore un peu plus l'écart avec l'écosystème npm classique.
Les limites, parce que faut être honnête
Bon, je vais pas te vendre Deno comme la solution miracle non plus, ce serait malhonnête.
- L'écosystème reste plus petit. Même avec la compatibilité npm qui s'améliore version après version, certains paquets un peu exotiques ou très liés aux internals de Node continuent de mal se comporter. Rien de bloquant en général, mais ça peut te faire perdre une soirée sur un bug bête.
deno desktopest encore expérimental. La doc le dit elle-même : la surface de l'API est encore en train de se stabiliser, et certaines fonctionnalités par plateforme ne sont pas encore toutes là. Sympa pour un side project, un peu tôt pour du prod critique.- Les permissions, ça use un peu à la longue. Sur un gros projet avec plein de dépendances, empiler les
--allow-net,--allow-read,--allow-env... ça peut vite ressembler à une liste de courses. C'est le prix de la sécurité, mais avoue que c'est un poil lourd au quotidien. - Moins de retours d'XP en prod à grande échelle. Node tourne depuis quinze ans dans des infras monstrueuses, avec des années de troubleshooting documentées partout sur le net. Deno, c'est encore relativement récent : moins de Stack Overflow, moins de retours d'expérience "on a eu ce bug en prod et voilà comment on l'a réglé".
- Le tooling autour (CI, monitoring, hébergeurs) est encore en rattrapage. Ça avance vite, mais tu trouveras encore des services ou des intégrations pensés Node par défaut, avec Deno en option de seconde zone.
Rien d'insurmontable, mais c'est le genre de trucs à avoir en tête avant de migrer un projet qui tourne déjà bien.
Alors, Deno ou Node.js ?
Est-ce que je te dis d'aller tout migrer demain matin ? Non, évidemment pas — Node.js reste une base solide, ultra documentée, et le changement a un coût, surtout sur un gros projet en prod. D'ailleurs moi-même je n'ai rien largué : Node reste dans ma stack pour pas mal de choses. Mais est-ce que Deno mérite qu'on s'y intéresse sérieusement en 2026, en complément ? Clairement oui.
Ce qui m'a convaincu, ce n'est pas un seul argument magique, c'est l'accumulation : la sécurité par défaut, le confort de TypeScript sans config, et maintenant cette 2.9 qui rend la cohabitation avec l'écosystème npm encore plus fluide. Est-ce que dans deux ou trois ans, on regardera Node comme on regarde jQuery aujourd'hui ? Je n'irais pas jusque-là. Mais si un dev sceptique comme moi a fini par laisser une vraie place à Deno sur plusieurs projets, sans pour autant renier Node, ça veut peut-être dire quelque chose.
Sources : Deno Blog — Deno 2.9 ; conférence "10 Things I Regret About Node.js", Ryan Dahl, JSConf EU, juin 2018 ; page Wikipédia de Ryan Dahl.