Bun 1.4 : cinq fois moins de CPU au repos

Ce qui se passe

Bun publie sa version 1.4. C'est la première version stable dont le cœur est écrit en Rust et non plus en Zig — un chantier qui inquiétait une partie de la communauté, faute de version stable pendant plusieurs mois.

L'annonce répond en mesures. Elle revendique 2 900 correctifs et 1 517 tests supplémentaires de la suite Node.js depuis la 1.3.

Une précision de lecture : le billet couvre tout ce qui a été livré depuis la 1.3.0. Plusieurs API présentées comme nouvelles sont en réalité arrivées dans les versions intermédiaires — Bun.WebView en 1.3.12, Bun.Image en 1.3.14.

Les chiffres

Le travail de fond porte sur les allocateurs. Jusqu'ici Bun en faisait tourner deux : libpas, celui de JavaScriptCore, et mimalloc. JavaScriptCore utilise désormais mimalloc lui aussi, étendu avec un nettoyage partiel des pages et un fil de récupération qui libère la mémoire pendant que JavaScript est inactif.

Processeur. Sur un « hello world », l'usage au repos est divisé par cinq. Le chiffre le plus parlant vient d'une application réelle : pour Claude Code, construit sur Bun, l'usage processeur en production a été divisé par deux — p99 de 24 % à 10 %, p50 de 5,8 % à 2,5 %.

Mémoire. Les serveurs HTTP gagnent entre 13 et 48 %. Sous une charge d'un million de requêtes, Fastify passe de 233 à 120 Mo — sous les 156 Mo de Node.js 26. En rendu serveur Next.js, un motif App Router qui fuyait sans limite en 1.3 se stabilise à 238 Mo sur 4 000 pages, contre 410 Mo pour Node.

Démarrage. Sur Linux, hello.js passe de 10,9 à 5,1 ms. Sur Windows, de 39 à 15,5 ms. Le binaire maigrit jusqu'à 17 %.

Ce qui entre dans le binaire

Le second axe de la version, c'est l'absorption de quinze dépendances npm directement dans le runtime :

• Bun.Image — redimensionnement, rotation et transcodage, en chaînage fluide jusqu'à l'écriture ou le streaming dans une Response.
• Bun.WebView — automatisation de navigateur sans interface, sans Puppeteer ni Playwright. WebKit système sur macOS, ou un Chrome/Chromium/Edge installé sur les trois plateformes. Navigation, clics et défilements réels, captures d'écran en Blob, et une trappe .cdp() vers le Chrome DevTools Protocol.
• Bun.markdown, Bun.cron(), Bun.Terminal — parseur Markdown avec GFM, tâches planifiées, pseudo-terminal natif.

Côté outillage : bun run --parallel remplace npm-run-all et concurrently, avec sortie préfixée par nom de script, correspondance par glob et diffusion sur les espaces de travail via --filter. S'ajoutent bun test --parallel, bun audit fix, bun dedupe et bun prune.

Sur la compatibilité Node, node:http, node:fs, node:cluster, node:vm et node:stream passent 97 % des tests officiels ; node:events et node:sqlite, 100 %.

Ce que ça change

Le bénéfice est réel, la contrepartie mérite d'être posée. Faire entrer quinze dépendances dans le runtime, c'est déléguer à l'équipe Bun la responsabilité de leurs correctifs de sécurité. On gagne un package.json plus court et une surface d'installation réduite ; on perd la main sur le rythme des mises à jour.

Aucune rupture majeure n'est annoncée. La marche à suivre est classique : bun upgrade sur une branche, mesure de votre propre empreinte mémoire sous charge, puis inventaire des outils que le runtime rend superflus.