Trois semaines avant de lancer un tableau de bord fintech pour un client dans les paiements l'année dernière, ma développeuse senior Priya est entrée dans notre bureau de Shoreditch et a dit « je veux basculer la couche API sur Bun ». J'ai failli refuser par instinct. Finalement, je n'ai pas refusé. Cette décision m'a appris plus sur les deux runtimes que n'importe quel fil de benchmark sur Hacker News n'aurait pu le faire.
Je construis sur Node depuis 2015. Chez Seahawk Media, nous avons lancé plus de 12 000 sites et applications sur WordPress, Next.js, Remix, Express brut, et plein d'autres choses bizarres. Bun a intégré notre stack sérieusement autour de mi-2023. À présent, j'ai un vrai avis. Pas une prise chaude. Un avis.
Voici ce que j'ai réellement appris.
---
La conversation sur les benchmarks est surtout du bruit
Tous les six mois, quelqu'un publie une nouvelle comparaison montrant Bun traitant 80 000 requêtes par seconde contre 40 000 pour Node sur un test HTTP hello-world synthétique. Et honnêtement ? Ce chiffre est réel. Les propres benchmarks de Bun montrent un débit véritablement impressionnant, surtout sur les charges de travail liées aux I/O.
Mais voilà. Personne ne lance hello-world en production.
À partir du moment où vous ajoutez un vrai ORM, un client Redis, trois couches de middleware, une validation JWT, et un gestionnaire de téléchargement de fichiers, l'écart se resserre considérablement. J'ai lancé des apps compatibles Express identiques (l'une sur Node 22, l'autre sur Bun 1.1) contre une instance Postgres pour le projet fintech et j'ai vu Bun gagner d'environ 18 % en latence p50. Significatif, pas miraculeux.
Là où la vitesse compte vraiment
L'endroit où j'ai remarqué le plus l'avantage de performance de Bun n'est pas le débit HTTP. C'est le temps de démarrage et l'exécution de scripts. Un script de migration de données unique que Node met 1,4 seconde à lancer ? Bun le fait en 180ms. Pour les outils CLI, les scripts de développement local, et les tâches planifiées, cette différence s'accumule en une amélioration réelle de la qualité de vie dans une équipe.
---
L'écosystème Node est toujours un avantage injuste
Je veux être direct à ce sujet parce que je vois trop de gens l'occulter. L'écosystème npm de Node a 15 ans. Bun est compatible avec la plupart, oui, mais « la plupart » fait du lourd levage dans cette phrase.
Début 2024, un projet client avait besoin de sharp pour le traitement d'images côté serveur. Simple assez. Sauf que la version spécifique dont nous avions besoin avait une liaison native que la couche FFI de Bun ne gérait pas proprement à l'époque. Nous avons brûlé une journée dessus avant que je bascule simplement ce service vers Node 20. Pas de drame, pas d'idéologie, juste du pragmatisme.
L'histoire de compatibilité s'est beaucoup améliorée depuis. Mais si votre stack s'appuie lourdement sur les addons Node natifs (pensez canvas, argon2, n'importe quoi avec des liaisons .node), testez à fond avant de vous engager. Ne présumez pas. Vérifiez le suivi de compatibilité de Bun avant de commencer une migration.
La gestion des paquets est une autre histoire
Le gestionnaire de paquets de Bun est véritablement plus rapide que npm, et je l'utilise maintenant même sur les projets Node. bun install sur un projet avec 400 dépendances prend environ 8 secondes sur mon MacBook Pro M2. npm prend 47 secondes sur la même machine. Ce n'est pas un benchmark. C'est moi le chronométrant mardi dernier avec time bun install versus time npm install.
J'utilise Bun comme gestionnaire de paquets avec Node comme runtime sur probablement 60 % de nos projets maintenant. Le meilleur des deux mondes.
---
TypeScript : Bun gagne clairement sur ce point
Je vais être direct. Exécuter TypeScript sur Node nécessite toujours une étape de build, ou ts-node, ou tsx, ou une combinaison de configurations qui me donne envie de m'allonger. Bun exécute les fichiers .ts nativement sans aucune config. Zéro.
Pour les outils internes chez Seahawk, cela a été transformateur. J'écris un script TypeScript, je l'exécute avec bun script.ts, c'est fait. Pas de tsconfig.json acrobatiques, pas de drame esm vs cjs. Pour une équipe qui livre rapidement sur de nombreux projets clients, la réduction des frictions est réelle.
La réserve : Bun utilise son propre transpileur TypeScript, pas le compilateur TypeScript officiel. Donc les erreurs de type n'arrêteront pas l'exécution. Il supprime les types et exécute. Si vous comptez sur le compilateur TypeScript pour les garanties de correction à l'exécution (vous ne devriez pas, mais les gens le font), c'est une limite à comprendre.
---
Ce que j'exécute réellement en production en ce moment
Soyons précis, les généralisations vagues ne servent à personne.
Sur Node 22 :
- Tous les backends WordPress headless utilisant WPGraphQL + Apollo Server
- Tout service avec des dépendances binaires natives
- Les APIs Express de longue durée avec des piles de middleware éprouvées
- Tout ce qui touche à un codebase legacy avec beaucoup de modules CommonJS
Sur Bun 1.1+ :
- Les outils CLI internes et les scripts de développement
- Les nouveaux services API basés sur Hono (Hono sur Bun est vraiment agréable)
- Les tâches cron planifiées et les scripts de migration ponctuels
- Les récepteurs de webhooks et les services légers proches du edge
Le modèle est assez simple. Greenfield et outils internes : Bun. Services de production orientés clients avec des arbres de dépendances complexes : Node, sauf s'il y a une raison spécifique de changer.
---
L'incident SQLite (et ce qu'il m'a enseigné)
Je l'ai mentionné au début. Ça vaut le coup d'expliquer.
Bun est livré avec un pilote SQLite intégré. Rapide, sans dépendances, vraiment utile. Sur un environnement de staging pour un outil de gestion de contenu fin 2023, nous l'avons utilisé pour stocker les données de session. Après une série particulièrement agressive d'écritures concurrentes lors d'un test de charge, le fichier de base de données s'est retrouvé dans un état bizarre. Pas corrompu au-delà de la récupération, mais verrouillé d'une manière qui a nécessité une intervention manuelle à 2h du matin, heure de mon fuseau horaire.
C'était un bug spécifique à Bun ? Honnêtement, je ne suis pas certain. Cela aurait pu être nos motifs d'écriture. Mais sur la même charge de travail, la configuration Node + better-sqlite3 que j'ai testée ensuite n'a pas reproduit le problème.
La leçon n'est pas « Bun SQLite est cassé ». C'est que les APIs intégrées de Bun, aussi pratiques qu'elles soient, ont moins de surface communautaire. Quand quelque chose se passe mal à 2h du matin, vous voulez des threads Stack Overflow et des issues GitHub. Node en a dix-sept ans. Bun en a trois.
---
Compatibilité du déploiement et des outils
Cette section est plus importante que les gens ne l'admettent.
Vercel, Railway, Render et Fly.io supportent tous les déploiements Bun maintenant. Railway en particulier l'a rendu très simple, à peu près aussi facile que Node. AWS Lambda est plus compliqué. Tu dois packager un runtime personnalisé ou utiliser une couche, ce qui ajoute de la complexité.
Docker, c'est correct. oven/bun est l'image de base officielle et elle fonctionne bien. Je l'utilise sur plusieurs services. L'image est plus légère que les équivalents Node si tu tiens compte de ça.
Ce qui est moins mature, c'est la couche d'observabilité. Les outils comme l'agent APM Node.js de Datadog, certains packages d'auto-instrumentation OpenTelemetry et certaines fonctionnalités du SDK Sentry fonctionnent différemment ou pas du tout sur Bun. J'ai perdu environ quatre heures l'année dernière à comprendre pourquoi les traces distribuées perdaient des spans sur un service Bun. Il s'avère que c'était une différence de propagation du contexte asynchrone. Le comportement d'AsyncLocalStorage de Node et l'implémentation de Bun divergent de façons subtiles qui te posent problème en traçage.
Si tu exécutes une observabilité de production sérieuse, teste ta stack de télémétrie entière avant de passer en production sur Bun. Pas après.
---
Ma Position Honnête sur la Question « Dois-je Changer? »
Voici un framework rapide que j'utilise quand un client ou un membre d'équipe pose la question :
- C'est un nouveau projet sans dépendances héritées? Évalue Bun sérieusement.
- Tu écris surtout des outils internes ou des scripts? Utilise Bun. Maintenant.
- Tu as besoin d'addons natifs ou de packages npm très spécifiques? Reste sur Node, teste d'abord.
- Le temps de démarrage ou la vitesse d'exécution des scripts sont un problème? Bun va t'aider notablement.
- Tu es sur AWS Lambda ou une plateforme sans support de première classe pour Bun? Node crée moins de frictions.
- Ton équipe connaît déjà les particularités de l'écosystème Node? Prends en compte la courbe d'apprentissage des différences de Bun.
Et quelques trucs à surveiller:
- Le support Windows de Bun s'est amélioré dramatiquement mais reste en retrait sur macOS et Linux pour les cas limites
- Le runner intégré
bun:testest vraiment bon, mais les plugins Jest sur lesquels tu comptes peuvent ne pas fonctionner - Le hot module reloading avec
--hotest impressionnant mais occasionnellement imprévisible sur les graphes de modules complexes
---
FAQ
Bun est prêt pour la production en 2026?
Pour des cas d'usage spécifiques, absolument oui. Pour un service API greenfield avec dépendances natives minimales, Bun est prêt pour la production depuis un moment. Pour des applications d'entreprise complexes avec des années de dépendances spécifiques à Node, je dirais « prêt pour la production avec des réserves ». Les réserves ne sont pas des dealbreakers mais elles demandent de la diligence.
Dois-je migrer les projets Node existants vers Bun?
Presque certainement non, sauf si tu as un problème spécifique que Bun résout pour ce projet. Les migrations comportent un risque. Si ton app Node fonctionne, le coût de productivité d'une migration vaut rarement le coup comparé à juste utiliser Bun sur les nouveaux projets. Je n'ai migré aucun projet client existant. J'en ai lancé de nouveaux sur Bun.
Bun est plus rapide que Node pour tous les workloads?
Non. Les workloads liés au CPU montrent une différence minimale parce que les deux exécutent finalement V8 (Node) ou JavaScriptCore (Bun). Les gains apparaissent surtout dans les workloads I/O-lourds, le temps de démarrage et tout ce où les implémentations natives de Bun (serveur HTTP, I/O fichier, SQLite) remplacent des équivalents de couche JavaScript. Pour un service lié au calcul intensif, tu ne remarqueras pas grand-chose.
Quel framework fonctionne le mieux avec Bun?
Hono est celui vers lequel je me tourne. C'est léger, TypeScript-first, et conçu avec des runtimes comme Bun en tête. ElysiaJS est l'autre choix populaire et est Bun-native, avec des chiffres de benchmark impressionnants. J'ai utilisé les deux. Hono je lui fais plus confiance en production parce que la communauté est plus grande et les cas limites sont mieux documentés.
Bun finira-t-il par remplacer Node ?
Probablement pas le remplacer. Coexister. Node a trop d'inertie institutionnelle dans les environnements d'entreprise et l'écosystème npm maintiendra les deux pertinents pendant longtemps. Ce que Bun a déjà fait, c'est pousser Node à s'améliorer. Node 22 est sensiblement plus rapide que Node 18, en partie parce que la concurrence existe. C'est bon pour tous ceux qui écrivent du JavaScript côté serveur.
---
Le runtime que vous choisissez importe moins que le code que vous écrivez dessus. Mais choisir le mauvais pour le mauvais projet vous coûte du temps, et le temps est la seule chose que je ne peux pas en acheter davantage. Utilisez Bun où cela a du sens. Faites confiance à Node où il l'a gagné. Et pour l'amour de tout, utilisez bun install sur les deux.