Bun vs Node : où en est-on en 2026

📚 Introduction

Quand Bun est sorti en 2022, beaucoup ont pris la promesse avec scepticisme : un runtime ultra-rapide, un package manager, un bundler et un test runner dans le même binaire, le tout compatible avec Node ? Trop beau pour être vrai.

Quatre ans plus tard, l’histoire a évolué. Bun a comblé la plupart de ses lacunes initiales, Node a accéléré son rythme de release et adopté plusieurs idées de Bun, et la question n’est plus “est-ce que ça marche” mais “à quel moment ça vaut la peine de switcher”.

⚡ Là où Bun continue de dominer

Sur trois axes, Bun reste sans rival sérieux côté Node :

Vitesse de démarrage : un script CLI démarre en quelques millisecondes là où Node prend 50 à 100 ms. Sur des workflows qui exécutent des centaines de tâches courtes, le gain est massif.
Install de dépendances : bun install est plusieurs fois plus rapide que npm install, et significativement plus rapide que pnpm install (qui restait jusqu’ici la référence).
Test runner intégré : bun test exécute des tests Jest-compatible avec un démarrage négligeable. Pour un projet de plusieurs centaines de tests, on passe d’une attente de plusieurs secondes à une exécution quasi-instantanée.

🧩 Là où Node a comblé l’écart

Côté Node, plusieurs évolutions récentes ont rendu le runtime moins frustrant :

Test runner natif (node --test), sans dépendance externe.
Watch mode natif (node --watch), qui remplace nodemon dans la plupart des cas.
Support natif de TypeScript activé par défaut depuis Node 22.18 / 23.6 et stabilisé en v25.2 : type stripping intégré, sans transformation (les enum, namespace avec runtime, paramètres de constructeur restent à compiler via tsx ou tsc).
fetch, WebSocket, URL standardisés, plus besoin de packages tiers.
ESM stabilisé : la guerre CommonJS / ESM est moins douloureuse qu’il y a deux ans.

Le delta entre Node et Bun s’est donc resserré sur la qualité de vie quotidienne, même si Bun garde une longueur d’avance sur la performance brute.

🧰 Quand choisir Bun

Mon arbitrage actuel :

CLI internes et scripts d’automatisation : Bun, sans hésiter. Le démarrage rapide change l’expérience.
Outillage frontend (bundler, dev server) : Bun gagne sur les petits projets, Vite reste imbattable sur les gros projets grâce à son écosystème de plugins.
API serverless ou edge : ça dépend du fournisseur. Vercel et Cloudflare proposent désormais Bun en preview. Si supporté, Bun donne une marge confortable sur le cold start.
APIs Express ou Fastify : Node reste mon défaut pour des raisons d’écosystème, de support à long terme et de compatibilité avec les outils de monitoring.

🔬 Bun pour les tests : un vrai pivot

L’argument qui m’a fait basculer plusieurs projets sur Bun, c’est le test runner. Sur une suite de 800 tests d’une application TypeScript :

Jest : ~38 secondes de cold run, ~12 secondes en watch.
Vitest : ~14 secondes / ~3 secondes.
Bun test : ~4 secondes / ~600 ms.

Pour des projets qui font beaucoup de TDD, ce delta change réellement la façon de travailler. On peut relancer la suite après chaque modification sans casser le flow.

⚠️ Les zones grises

Compatibilité totale avec Node : encore quelques modules natifs qui ne suivent pas (mais ils se comptent sur les doigts d’une main aujourd’hui).
Profilage et debug : Bun progresse, mais l’outillage Node reste plus mûr.
Support des hébergeurs traditionnels : sur AWS Lambda, certaines configurations demandent encore quelques contournements.

🎉 Conclusion

En 2026, la bonne question n’est plus “Bun ou Node ?” mais “Bun pour quoi, Node pour quoi ?”. Côté outillage, CLI et test runner, Bun est devenu mon défaut. Côté serveur applicatif et API critique, Node reste le choix raisonnable à court terme, mais l’écart se réduit chaque semaine.

Si vous n’avez pas réessayé Bun depuis dix-huit mois, c’est probablement le bon moment pour refaire un tour : l’expérience est très différente de la première impression.

🥯 Bun vs Node.js : où en est-on vraiment en 2026