Deno, Bun et la guerre des runtimes JavaScript — pourquoi Node.js n'est plus la référence par défaut

Ryan Dahl a créé Node.js en 2009 et a changé le développement côté serveur de façon permanente. Pour la première fois, JavaScript — un langage que les développeurs connaissaient déjà depuis le navigateur — pouvait s'exécuter sur des serveurs, permettant le JavaScript full-stack et un écosystème qui est finalement devenu le plus grand registre de paquets de l'histoire avec plus de 2,5 millions de paquets sur npm. Pendant 15 ans, Node.js a été la référence par défaut incontestée pour quiconque voulait exécuter JavaScript en dehors d'un navigateur.

Puis Ryan Dahl a donné une conférence à JSConf EU en 2018 intitulée « 10 choses que je regrette à propos de Node.js », et a annoncé Deno. La conférence était inhabituellement franche pour un auteur critiquant sa propre création : le système de modules était erroné, le modèle de sécurité était absent, package.json et node_modules étaient des erreurs, et la conception originale avait accumulé trop de contraintes pour être corrigée sans repartir de zéro. Trois ans plus tard, une équipe différente a livré Bun — un runtime JavaScript avec la performance comme objectif de conception central, construit à partir de zéro en Zig plutôt qu'en C++.

Node.js : Le poids de l'héritage

Node.js fonctionne sur le moteur V8 JavaScript (le même moteur qui alimente Chrome) et a accumulé 15 ans d'obligations de rétrocompatibilité. Son système de modules — CommonJS (require/module.exports) — est antérieur à la norme ES Modules que les navigateurs utilisent désormais, créant une friction d'interopérabilité chronique qui n'a jamais été résolue proprement. Node.js a ajouté le support des ES Modules dans la version 12 (2019), mais la coexistence de deux systèmes de modules, avec leurs sémantiques différentes concernant le chargement synchrone vs asynchrone, a été une source persistante de confusion pour les développeurs et de fragmentation de l'écosystème.

Le modèle de sécurité est également une faiblesse reconnue. Node.js donne à tout script un accès complet au système de fichiers, au réseau et aux variables d'environnement par défaut. Cela a rendu le développement initial rapide, mais crée un risque significatif dans un monde où les attaques sur la chaîne d'approvisionnement npm sont monnaie courante. Un paquet malveillant installé en tant que dépendance transitive a, par défaut, le même accès à votre système que votre code d'application.

Node.js reste le runtime JavaScript côté serveur le plus largement déployé, avec une avance considérable — l'écosystème npm est construit autour de lui, la plupart des frameworks JavaScript le ciblent en premier, et la plupart des déploiements de production s'exécutent dessus. L'héritage ne disparaît pas. Mais il a créé un espace pour des alternatives.

Deno : TypeScript d'abord, sécurité par défaut

Deno est la tentative de Ryan Dahl de corriger les erreurs qu'il a commises avec Node.js. Il exécute TypeScript nativement — aucune étape de compilation requise, aucun tsconfig.json nécessaire pour une utilisation de base — ce qui adresse l'un des points de friction les plus courants dans le développement JavaScript moderne. Il utilise exclusivement le système ES Modules, éliminant la scission CommonJS/ESM. Et il implémente un modèle de permissions où les scripts doivent demander explicitement l'accès au système de fichiers, au réseau et à l'environnement : `deno run --allow-net --allow-read server.ts`.

La compatibilité avec les Web API de Deno est un choix de conception significatif. Les API standard du navigateur — fetch, WebCrypto, URL, WebSockets, Streams — fonctionnent dans Deno sans aucun polyfill. Le code écrit pour Deno peut souvent s'exécuter dans les navigateurs avec des modifications minimes, ce qui s'aligne avec la direction moderne de JavaScript en tant que langage universel plutôt que de variantes spécifiques à une plateforme. Cloudflare Workers, Vercel Edge Functions et Deno Deploy s'exécutent tous sur des isolates V8 avec des surfaces Web API similaires, rendant le code Deno hautement portable entre les plateformes de déploiement edge.

Le modèle de gestion des paquets est différent de npm : Deno importe les modules directement depuis des URLs (y compris les paquets npm via des spécificateurs `npm:`), sans répertoire node_modules et sans package.json nécessaire pour les cas d'utilisation simples. Le fichier de configuration deno.json gère le verrouillage des dépendances via une import map. Ce modèle est plus propre mais ajoute une courbe d'apprentissage pour les développeurs formés aux workflows npm.

L'adoption de Deno a été substantielle dans le domaine de l'edge computing — Deno Deploy et son intégration avec l'écosystème Deno est un produit compétitif — mais il n'a pas déplacé Node.js dans les applications serveur traditionnelles. La compatibilité avec l'écosystème npm ajoutée dans Deno 1.28 (novembre 2022) a considérablement réduit la friction de migration, mais la plupart des charges de travail de production restent sur Node.js.

Bun : La vitesse comme principe de conception

Bun adopte une approche différente. Là où Deno est une histoire de correction et de sécurité, Bun est une histoire de performance. Construit en Zig (un langage de programmation système conçu pour la performance) et utilisant le moteur JavaScriptCore d'Apple (le même moteur qui alimente Safari, et dans les propres benchmarks d'Apple, plus rapide que V8 pour certaines charges de travail), Bun est conçu pour être le runtime JavaScript le plus rapide disponible.

Les affirmations des benchmarks sont significatives : les benchmarks du serveur HTTP de Bun montrent un débit 2 à 4 fois supérieur à celui de Node.js pour les gestionnaires de requêtes simples. Les benchmarks d'E/S de fichiers montrent des avantages similaires. L'installation de paquets de Bun est plus rapide que npm, yarn ou pnpm — généralement 5 à 30 fois plus rapide selon le scénario — ce qui améliore considérablement l'expérience développeur dans les environnements CI/CD et les workflows conteneurisés.

Bun se positionne également comme une boîte à outils tout-en-un : c'est un runtime, un gestionnaire de paquets (remplaçant npm), un bundler (remplaçant webpack ou esbuild), et un exécuteur de tests (remplaçant Jest ou Vitest). La philosophie de conception est de réduire le nombre d'outils dans la pile de développement JavaScript, qui nécessitait historiquement l'assemblage de 5 à 10 outils séparés pour une configuration prête pour la production.

La compatibilité avec Node.js est une priorité élevée pour Bun — il supporte CommonJS et ES Modules, implémente la plupart des API intégrées de Node.js, et peut exécuter la plupart des paquets npm sans modification. Bun 1.0, sorti en septembre 2023, a été la première version prête pour la production ; les versions ultérieures ont progressivement amélioré la compatibilité avec Node.js au point que la plupart des applications Node.js s'exécutent sur Bun sans changements.

L'avertissement sur la performance

Les avantages de performance de Bun sont réels mais dépendent du contexte. Pour les charges de travail liées aux E/S — serveurs HTTP, requêtes de base de données, opérations sur fichiers — les gains de Bun par rapport à Node.js sont mesurables et significatifs. Pour les charges de travail liées au CPU ou les applications limitées par des systèmes externes (latence de base de données, temps de réponse des API), le runtime JavaScript est rarement le goulot d'étranglement, et changer de runtime apporte un bénéfice minime.

Le compromis entre JavaScriptCore et V8 a aussi des nuances : le compilateur JIT de V8 a été optimisé pendant 15 ans pour les charges de travail web de production. Les caractéristiques de performance de JavaScriptCore diffèrent de V8 de manières qui peuvent produire des résultats différents dans des benchmarks spécifiques par rapport au comportement réel de l'application. Les chiffres de « 2 à 4 fois plus rapide » des benchmarks de Bun reflètent des charges de travail synthétiques ; les accélérations dans les applications de production sont généralement de l'ordre de 10 à 30 %.

Que faut-il utiliser concrètement ?

Les conseils pratiques en 2026 : Node.js pour les projets existants et les équipes avec des workflows npm établis, où le coût de la migration dépasse les améliorations marginales de performance. Deno pour les nouveaux projets où le développement TypeScript-first, le déploiement edge ou la posture de sécurité sont une priorité — en particulier les projets ciblant Cloudflare Workers, Deno Deploy ou des plateformes edge similaires. Bun pour les projets où l'expérience développeur (installations rapides, exécutions de tests rapides) et la latence de démarrage sont importantes, et où l'équipe est à l'aise avec un écosystème plus récent et moins éprouvé en production que Node.js.

La concurrence a également amélioré Node.js. Les temps de démarrage plus rapides dans Node.js 20+, le support amélioré d'ESM, et le modèle de permissions exploré dans la feuille de route de Node.js sont des réponses directes à Deno et Bun. Pour un écosystème linguistique qui n'avait pas de concurrence significative pendant 15 ans, la pression a été productive. Le runtime JavaScript en 2026 est véritablement un choix, et non une référence par défaut.