Bun, Deno et Node.js en 2026 : trois environnements d'exécution sérieux et leurs atouts respectifs

Pendant la majeure partie de l'histoire de JavaScript côté serveur, la question du runtime était réglée : on utilisait Node.js. La création de Ryan Dahl en 2009 dominait si complètement que « runtime JavaScript » et « Node.js » étaient effectivement synonymes. Cette époque est révolue. D'ici 2026, trois runtimes — Node.js 22, Bun 1.2 et Deno 2.0 — sont tous viables en production et significativement différents les uns des autres. Choisir entre eux n'est plus une question théorique.

Node.js 22 : Toujours dominant, enfin modernisé

Node.js 22, sorti en avril 2024 et actuellement en LTS, est la version la plus importante de Node.js depuis des années. La fonctionnalité phare pour la plupart des développeurs est --experimental-strip-types : exécuter directement des fichiers TypeScript sans étape de build. Il ne s'agit pas d'une compilation TypeScript complète — Node.js supprime les annotations de type et exécute le JavaScript restant, sans vérification de type. Il ne prend pas en charge la syntaxe spécifique à TypeScript comme enum ou les décorateurs sans indicateurs supplémentaires. Mais pour le cas courant du TypeScript que vous transpilez de toute façon, cela élimine l'étape de compilation du cycle de développement.

Node.js 22 est également livré avec un exécuteur de tests intégré mature (node:test), désormais suffisamment performant pour que de nombreux projets puissent abandonner Jest ou Vitest pour les cas simples. Une implémentation intégrée de fetch, WebCrypto et WebStreams est désormais stable. Le runtime n'est pas rapide selon les standards de Bun, mais il est suffisamment rapide pour la plupart des charges de travail en production, et la compatibilité avec l'écosystème est inégalée — tous les packages npm qui existent fonctionnent avec Node.js, car c'est pour cela qu'il a été conçu.

Le cas pour rester sur Node.js est simple : coût de migration nul, compatibilité maximale avec l'écosystème et 15 ans d'expérience en production. Si votre équipe a une base de code Node.js fonctionnelle et que le goulot d'étranglement n'est pas la vitesse d'exécution, changer est un changement pour le changement.

Bun : Vraiment rapide, vraiment prêt pour la production

Bun 1.0 a été lancé en septembre 2023 avec un enthousiasme considérable et un scepticisme légitime — de nombreux runtimes JavaScript rapides ont été lancés sans parvenir à gagner du terrain. Un an plus tard, Bun 1.1 ajoutait le support de Windows. Avec Bun 1.2 (début 2025), le runtime avait résolu les plaintes de stabilité les plus significatives et était déployé en production dans un nombre croissant d'entreprises.

Bun est écrit en Zig et utilise JavaScriptCore — le moteur JavaScript d'Apple, issu de WebKit — plutôt que V8. Ce choix architectural a des conséquences. Le temps de démarrage de Bun est 4 à 8 fois plus rapide que celui de Node.js dans les benchmarks. bun install effectue les installations de packages 20 à 30 fois plus rapidement que npm install, principalement parce que Bun utilise un format de fichier de verrouillage binaire et une mise en cache agressive. Pour l'expérience développeur — exécution de tests, rechargement à chaud, installation de dépendances — la différence de vitesse est immédiatement perceptible.

Bun est également un bundler et un exécuteur de tests prêts à l'emploi. bun test exécute des fichiers de test compatibles Jest sans configuration. bun build regroupe pour le navigateur ou l'edge. Ce ne sont pas des ajouts après coup — ce sont des fonctionnalités de première classe, et elles éliminent plusieurs outils de l'arbre de dépendances d'un projet JavaScript typique.

Le compromis : le comportement de JavaScriptCore diffère de celui de V8 dans les cas limites, et certains packages npm qui dépendent des composants internes de V8 ne fonctionnent pas correctement sous Bun. La surface de compatibilité est vaste et s'améliore — Bun suit les API Node.js de manière agressive et la plupart des packages fonctionnent — mais les cas limites existent. Si vous exécutez une application Node.js riche en packages, testez avant de migrer.

Deno 2.0 : Le problème npm est résolu (en grande partie)

Deno a été annoncé en 2018 par Ryan Dahl — la même personne qui a créé Node.js — explicitement en réponse à ce qu'il a appelé ses « 10 choses que je regrette à propos de Node.js ». Il a été lancé avec un modèle de permissions (pas d'accès au système de fichiers ou au réseau sans autorisation explicite), un support TypeScript intégré, pas de dossier node_modules et des importations basées sur des URL au lieu de npm.

La vision était cohérente, mais le problème pragmatique était réel : npm compte 2,3 millions de packages, et Deno ne pouvait pas les exécuter. Deno 2.0, sorti en octobre 2024, a résolu ce problème. Il prend désormais en charge les packages npm avec des spécificateurs npm:, exécute la plupart du code compatible Node.js prêt à l'emploi et est rétrocompatible avec le code Deno 1.x. Le dossier node_modules reste optionnel — Deno gère les dépendances dans son propre cache — mais vous pouvez l'activer pour la compatibilité si nécessaire.

Deno a également lancé JSR, le JavaScript Registry, comme alternative à npm. JSR est d'abord TypeScript, utilise un versionnement basé sur les URL et impose une documentation d'API. Ce n'est pas un remplacement pour les 2,3 millions de packages de npm, mais il grandit et le signal de qualité des packages est plus élevé car JSR nécessite du code source TypeScript et de la documentation pour publier.

Le modèle de permissions de Deno reste sa caractéristique la plus distinctive. Exécuter deno run script.ts sans indicateurs ne donne au script aucun accès au système de fichiers, au réseau ou à l'environnement — vous accordez chaque capacité explicitement. Il s'agit d'une amélioration de sécurité significative pour les scripts qui exécutent du code non fiable ou traitent des données sensibles. Pour la plupart des cas d'utilisation de serveurs web, vous accordez toutes les permissions de toute façon, mais le modèle vous oblige à être délibéré à ce sujet.

Performances : Les chiffres honnêtes

Les benchmarks de runtime sont notoirement faciles à manipuler, et les partisans de chaque runtime peuvent produire des chiffres qui favorisent leur choix. Le tableau moins contesté ressemble à ceci :

Temps de démarrage : Bun est le plus rapide (4 à 8 fois plus rapide que Node.js), Deno suit de près, Node.js est le plus lent.
Débit HTTP (serveur simple) : Bun mène de 20 à 40 % par rapport à Node.js dans les benchmarks simples. Deno est similaire à Node.js. Sous charge réelle avec des charges de travail intensives en E/S, l'écart se réduit considérablement.
Vitesse d'installation des packages : Bun est 20 à 30 fois plus rapide que npm. Deno (pas de node_modules par défaut) est effectivement instantané. Node.js avec pnpm est une amélioration significative par rapport à npm mais reste plus lent que Bun.
Vitesse de build/bundle : Le bundler natif de Bun est plus rapide qu'esbuild dans la plupart des configurations. Deno utilise esbuild en interne. Node.js nécessite un outil externe.

Pour les processus serveur de longue durée, les différences de temps de démarrage disparaissent. Pour les fonctions serverless, les outils CLI et les outils de développement, l'avantage de démarrage de Bun est réel et visible par l'utilisateur.

Lequel utiliser

La réponse honnête dépend de ce que vous construisez :

Utilisez Node.js 22 si vous maintenez une base de code existante, avez besoin d'une compatibilité maximale avec l'écosystème npm, ou si l'expérience opérationnelle de votre équipe est profondément ancrée dans Node.js. Le nouveau stripping TypeScript est utile pour le développement mais n'est pas une raison pour passer de Deno ou Bun si vous y êtes déjà.

Utilisez Bun pour les nouveaux projets où les performances de démarrage et l'expérience développeur comptent — outils CLI, suites de tests, scripts exécutés dans CI/CD, ou services où le démarrage 4 à 8 fois plus rapide se traduit par des coûts de démarrage à froid plus faibles dans les environnements serverless. La nature tout-en-un de Bun (runtime + bundler + gestionnaire de packages + exécuteur de tests) est également un argument significatif si vous souhaitez réduire la complexité de la chaîne d'outils.

Utilisez Deno si la posture de sécurité est importante — si vous exécutez des scripts qui traitent des données sensibles et que vous voulez les octrois de capacités explicites du modèle de permissions — ou si vous construisez de nouveaux projets où le développement d'abord TypeScript et les normes de qualité des packages JSR sont attrayants. Le support des notebooks Jupyter de Deno le rend également intéressant pour l'exploration de données en TypeScript.

La fragmentation est réelle mais pas paralysante. Les trois runtimes parlent suffisamment le même langage pour que le changement soit réalisable si votre choix initial s'avère erroné. L'investissement décennal de l'écosystème JavaScript dans les packages npm signifie que même Bun et Deno, qui ont été construits pour transcender npm, ont convergé vers la compatibilité npm comme une nécessité pragmatique. Choisissez en fonction de ce dont votre projet a le plus besoin maintenant — performances, sécurité ou stabilité — et réévaluez si les circonstances changent.