TL;DR
- Bun 1.2 franchit un cap : compatibilité Node.js quasi-complète, client S3 natif, driver Postgres intégré, et un bundler qui mûrit.
- Là où Bun gagne : vitesse de démarrage, DX (pas besoin de 5 outils pour un projet), et scripts utilitaires.
- Là où Node.js gagne encore : écosystème mature, support enterprise, debugging avancé, confiance en production.
- Verdict : pour un nouveau side project, teste Bun. Pour un projet en prod avec 50 devs, attends encore un peu.
Bun 1.2, c'est le moment de regarder sérieusement
Chaque release de Bun promet de "remplacer Node.js". Et chaque fois, la communauté se divise entre les early adopters enthousiastes et les sceptiques qui rappellent que Node.js tourne en prod depuis 2009.
Bun 1.2 est différent. Pas parce que c'est révolutionnaire, mais parce que ça commence à être utilisable pour de vrais projets. La compatibilité Node.js a fait un bond massif, les features intégrées réduisent le nombre d'outils nécessaires, et la stabilité s'améliore release après release.
Regardons ça de plus près, sans hype et sans conservatisme aveugle.
Ce que Bun 1.2 apporte concrètement
Compatibilité Node.js : le vrai game changer
La version 1.2 passe le cap des 90% des tests de compatibilité Node.js. Concrètement :
node:httpetnode:httpsfonctionnent correctement, y compris les edge cases (chunked encoding, keep-alive, etc.)node:cryptosupporte la majorité des algorithmes utilisés en prodnode:fsest quasi-complet, y compris les watchersnode:netetnode:tlssont stables
Ça veut dire que la plupart des packages npm "just work". Express, Fastify, Hono -- tu peux les lancer avec bun run sans toucher au code.
Client S3 intégré
Plus besoin d'installer @aws-sdk/client-s3 et ses 47 dépendances transitives. Bun inclut un client S3 natif :
const file = Bun.s3("mon-bucket/document.pdf");
const content = await file.text();
// Upload
await Bun.s3("mon-bucket/output.json").write(
JSON.stringify({ result: "ok" })
);
C'est minimaliste, c'est rapide, et pour 80% des cas d'usage S3 (upload, download, list), ça suffit. Pour les cas avancés (multipart upload, lifecycle policies), il faut toujours le SDK AWS.
Postgres natif
Même logique : un driver Postgres intégré, sans dépendance externe.
import { sql } from "bun";
const users = await sql`
SELECT id, name, email
FROM users
WHERE active = ${true}
`;
L'API est inspirée de postgres.js (tagged template literals), avec des performances proches du driver natif en C. Pour les projets qui n'ont pas besoin d'un ORM complet, c'est suffisant.
Le bundler qui mûrit
Le bundler de Bun est passé de "intéressant mais limité" à "utilisable pour des vrais projets". Il gère :
- Tree-shaking
- Code splitting
- CSS modules
- Les plugins (API compatible avec esbuild)
- Les source maps
Il reste derrière Vite pour les projets frontend complexes (HMR, framework integrations), mais pour un backend ou une bibliothèque, il fait le job.
Là où Bun gagne : la DX unifiée
Le vrai argument de Bun, c'est pas juste la vitesse. C'est le fait qu'un seul outil remplace cinq.
Avant (stack Node.js typique)
Runtime → Node.js
Package mgr → npm / pnpm / yarn
Bundler → esbuild / webpack / Vite
Test runner → Jest / Vitest
TypeScript → tsc + ts-node / tsx
Après (stack Bun)
Runtime → Bun
Package mgr → Bun (compatible package.json)
Bundler → Bun
Test runner → Bun (compatible Jest)
TypeScript → Bun (natif, zéro config)
Tu n'as plus besoin de tsconfig.json pour lancer du TypeScript. Pas besoin de configurer un test runner. Pas besoin d'un bundler séparé. Bun fait tout.
La vitesse d'installation des dépendances est réellement impressionnante. Un bun install sur un projet moyen prend 2-3 secondes là où npm install en prend 15-20. Ce n'est pas un benchmark marketing -- c'est mesurable au quotidien.
Benchmarks honnêtes
Parlons chiffres, mais avec nuance :
| Opération | Node.js 22 | Bun 1.2 | Différence |
|---|---|---|---|
| Démarrage à froid | ~40ms | ~8ms | 5x plus rapide |
install (projet moyen) | ~18s | ~3s | 6x plus rapide |
| Requêtes HTTP/s (simple) | ~45K | ~105K | 2.3x plus rapide |
| Tests Jest (suite moyenne) | ~4.2s | ~1.8s | 2.3x plus rapide |
Mais attention :
- Les benchmarks HTTP sont sur des serveurs "hello world". En prod, le goulot d'étranglement c'est ta base de données, pas ton runtime.
- La différence de démarrage compte pour les serverless functions et les scripts CLI. Pour un serveur qui tourne H24, ça change rien.
- La vitesse des tests est réelle et appréciable au quotidien. C'est là que Bun fait la plus grande différence en DX.
Là où Node.js gagne encore
L'écosystème
Node.js a 15 ans d'écosystème derrière lui. Ça veut dire :
- Chaque package npm a été testé avec Node.js. Pas avec Bun. Les 90% de compatibilité laissent 10% de cas où ça casse. Et c'est souvent dans les cas edge que tu découvres en prod.
- Les ORMs (Prisma, Drizzle, TypeORM) ont des tests CI avec Node.js. Le support Bun est "best effort" pour la plupart.
- Les frameworks full-stack (Next.js, Remix, Nuxt) sont développés et testés sur Node.js. Bun fonctionne souvent, mais c'est pas garanti.
La stabilité en production
Node.js est battle-tested à une échelle que Bun n'a pas encore atteinte :
- Netflix, LinkedIn, Uber, PayPal tournent sur Node.js en prod. Les bugs obscurs ont été trouvés et corrigés sur 15 ans.
- Les memory leaks sont mieux documentés et plus faciles à diagnostiquer avec les outils Node.js (clinic.js, heapdump, etc.).
- Le garbage collector V8 est optimisé pour les workloads serveur long-running. JavaScriptCore (le moteur de Bun) vient du monde des navigateurs (Safari). Les profils de charge sont différents.
Le debugging
Les outils de debugging Node.js sont matures :
- Chrome DevTools via
--inspect - Les profilers CPU et mémoire intégrés
- Les APM (New Relic, Datadog) ont un support Node.js de première classe
Bun progresse sur ce front, mais tu n'as pas encore la même profondeur d'instrumentation.
Le support enterprise
Si tu travailles dans une grande boîte, Node.js a un avantage décisif :
- Support LTS avec des dates claires (Node.js 22 LTS jusqu'en avril 2027)
- Audits de sécurité formels
- Conformité SOC 2 / ISO 27001 documentée
- Équipes DevOps qui savent le déployer
Bun n'a pas encore ce niveau de maturité organisationnelle. Chez Oven (la boîte derrière Bun), l'équipe est petite et le rythme de release est rapide -- ce qui est bien pour l'innovation mais pas rassurant pour un DSI.
Quand utiliser Bun vs Node.js ?
Utilise Bun pour :
- Les scripts CLI et utilitaires : la vitesse de démarrage fait une vraie différence.
- Les side projects et prototypes : la DX unifiée accélère le setup.
- Les serverless functions simples : cold start réduit = meilleure latence.
- Les tests : lancer ta suite de tests en 2s au lieu de 5s, ça motive à les lancer plus souvent.
- Les monorepos avec workspace :
bun installest remarquablement rapide sur les gros workspaces.
Garde Node.js pour :
- Les projets en production avec des utilisateurs réels et des SLA.
- Les stacks qui dépendent de frameworks spécifiques (Next.js, NestJS) pas encore certifiés Bun.
- Les environnements enterprise où la stabilité prime sur la vitesse.
- Les projets avec du Docker complexe : les images Node.js sont mieux supportées et documentées.
Mon verdict
Bun 1.2 est le premier release où je peux dire "c'est viable pour des vrais projets" sans croiser les doigts. La compatibilité Node.js est suffisante pour la majorité des cas, la DX est objectivement meilleure, et les features intégrées (S3, Postgres, bundler) réduisent la complexité de la stack.
Mais "viable" ne veut pas dire "meilleur choix dans tous les cas".
Pour un nouveau projet perso ou un prototype, utilise Bun. Tu gagneras du temps sur le setup, les tests seront plus rapides, et tu n'auras pas besoin de jongler entre cinq outils.
Pour un projet en prod avec une équipe, reste sur Node.js encore un peu. Pas par conservatisme, mais parce que les 10% de cas de compatibilité non couverts tombent toujours au pire moment. Attends Bun 1.3 ou 1.4 pour réévaluer.
Et dans tous les cas, garde un oeil dessus. La trajectoire est clairement ascendante.
Ressources
- Bun 1.2 release notes -- le détail complet des nouveautés
- Bun vs Node.js compatibility -- tableau de compatibilité officiel
- Node.js 22 release -- les nouveautés côté Node.js
- JavaScriptCore vs V8 -- pour comprendre les différences de moteur
- Bun Discord -- communauté active pour les retours de bugs