En 2026, trois runtimes JavaScript se disputent la dominance côté serveur : Node.js (dominant à 90% d'utilisation), Bun (le plus rapide selon chaque benchmark, souvent 2-3× plus rapide en throughput HTTP) et Deno (l'outsider axé sur la sécurité à 11% d'utilisation). Des benchmarks indépendants à travers le throughput HTTP, les cold starts et la performance asynchrone racontent désormais une histoire cohérente.
Le marketing de chaque camp est bruyant. Les benchmarks sont partout. Et pour une fois, les chiffres sont suffisamment cohérents pour tirer de vraies conclusions.
Le TL;DR
- Bun est le plus rapide en throughput brut et cold starts
- Node.js reste le pari le plus sûr pour la compatibilité avec l'écosystème
- Deno gagne sur la posture de sécurité mais est à la traîne sur la performance
- Si vous démarrez un nouveau projet aujourd'hui, Bun est le choix le plus convaincant pour le travail sensible à la performance
La Réalité Des Benchmarks
Des tests indépendants à travers un profil matériel cohérent racontent une histoire assez claire. Voici ce que les données montrent :
Throughput HTTP
Bun mène systématiquement dans les benchmarks de throughput de serveur HTTP, souvent 2-3x plus rapide que Node.js sur le même matériel. L'écart se rétrécit sous forte charge concurrente mais ne se ferme jamais entièrement. Deno se situe quelque part au milieu, dépassant généralement Node.js mais bien derrière Bun.
La raison est l'architecture : Bun utilise JavaScriptCore (le moteur de Safari) avec une bibliothèque standard basée sur Zig. Zig donne à Bun un contrôle beaucoup plus serré sur l'allocation mémoire et la surcharge syscall que les runtimes basés sur V8. Pour les derniers benchmarks de performance et les nouvelles fonctionnalités Bun des versions récentes, voir notre analyse de Bun v1.3.11.
Temps de Cold Start
C'est là que Bun domine de la manière la plus décisive. Les cold starts, critiques pour les workloads serverless et conteneurisés, se mesurent en millisecondes pour Bun contre des centaines de millisecondes pour Node.js sur des workloads équivalents. Une fonction Lambda avec un runtime Bun démarre environ 3-4x plus vite que la même fonction avec Node.
// Bun: cold start ~30ms
Bun.serve({
port: 3000,
fetch(request) {
return new Response("fast");
},
});
// Équivalent Node.js cold start typiquement 80-150ms
Performance Asynchrone
Pour les workloads liés aux E/S, requêtes de base de données, appels HTTP, opérations fichiers, les différences se réduisent considérablement. Les trois runtimes utilisent des E/S non-bloquantes sous le capot. La surcharge de la event loop est comparable entre Node.js et Deno. L'avantage de Bun ici est plus modeste que dans les scénarios liés au CPU.
La Question De L'Écosystème
La performance c'est une chose. L'écosystème npm c'est autre chose.
Node.js exécute npm, yarn et pnpm nativement. Chaque package dont vous pourriez avoir besoin fonctionne. L'histoire de compatibilité c'est 15 ans de confiance accumulée.
Bun se positionne comme un « remplacement drop-in » pour Node.js. En pratique, cela signifie qu'il exécute la plupart des packages npm sans modification. Le taux de compatibilité tourne autour de 95% pour les packages populaires, impressionnant, mais ces 5% restants peuvent être une surprise douloureuse. (La surface de sécurité de l'écosystème npm est une préoccupation connexe : une attaque de supply chain axios récente a souligné que même les packages les plus largement utilisés comportent des risques.)
# Bun installe les packages 3-10x plus vite que npm
bun install
# Et peut exécuter les scripts npm
bun run dev
Deno prend une approche différente : pas de npm, pas de node_modules. Deno importe les packages directement depuis des URLs. C'est élégant en théorie et fastidieux en pratique. Le Deno Registry aide, mais vous travaillez fréquemment autour d'une résolution de module qui « fonctionnerait juste » dans Node.
L'Angle Sécurité
Le différenciateur principal de Deno est la sécurité. Par défaut, Deno exécute le code dans un sandbox sans accès au système de fichiers, réseau ou environnement, sauf autorisation explicite.
// Deno requiert des permissions explicites
deno run --allow-net=api.stripe.com --allow-read ./server.ts
// Node.js et Bun s'exécutent avec un accès système complet
Pour les déploiements axés sur la sécurité, SaaS multi-tenant, plugins de sources non fiables, tout scénario où le code s'exécute dans le même processus que des données sensibles, le modèle de Deno est significativement plus sûr. Les autres vous demandent de faire confiance au code que vous exécutez.
Que Choisir
Choisissez Bun si : La performance est une priorité, vous êtes à l'aise avec un debugging de compatibilité occasionnel et vous voulez une toolchain moderne avec le bundling, les tests et la gestion de packages intégrés. (La dernière version Bun v1.3.11 a ajouté la planification cron au niveau OS et une réduction de taille binaire de 4 Mo, renforçant davantage son cas comme runtime tout-en-un.)
Choisissez Node.js si : Vous avez besoin d'une compatibilité maximale avec l'écosystème, vous travaillez avec des outils enterprise établis ou vous êtes déjà investi dans l'écosystème Node et n'avez pas de problème de performance spécifique à résoudre.
Choisissez Deno si : La sécurité est primordiale, vous préférez le modèle d'import par URL et l'écart de performance par rapport à Bun est acceptable pour votre cas d'utilisation.
L'Évaluation Honête
Le paysage des runtimes en 2026 est plus sain qu'en 2020. Node.js ne va nulle part, il est trop ancré dans l'infrastructure de production. Mais les chiffres de Bun sont réels et les améliorations d'expérience développeur (installations plus rapides, tests plus rapides, TypeScript intégré sans config) s'additionnent dans le workflow quotidien.
Le vrai gagnant pourrait être JavaScript lui-même. La compétition entre ces runtimes pousse une exécution plus rapide, de meilleurs outils et le support TypeScript natif à travers les trois, ce qui bénéficie les développeurs quel que soit le runtime qu'ils choisissent.
