Bun 1.4, publié le 20 août 2026, signe la plus forte rupture d’architecture du runtime depuis ses débuts : le moteur passe de Zig à Rust, et quinze bibliothèques que l’écosystème JavaScript installait séparément deviennent des API natives. L’annonce met l’accent sur trois axes mesurés : compatibilité Node.js, vitesse d’installation et consommation mémoire.
Un moteur réécrit en Rust
La bascule de Zig vers Rust concerne le cœur du runtime. Elle n’est pas restée théorique avant l’annonce : d’après l’éditeur, Claude Code s’appuyait sur le portage Rust depuis plusieurs mois et Prisma a lancé Prisma Compute dessus. Les gains avancés sont chiffrés. La consommation CPU au repos d’une application « hello world » est divisée par cinq. Les serveurs HTTP voient leur mémoire baisser de 13 % à 48 % : un service Fastify passe de 233 Mo à 120 Mo. Le démarrage est deux fois et demie plus rapide sous Windows (39 ms à 15,5 ms) et deux fois plus rapide sous Linux (10,9 ms à 5,1 ms). Les binaires perdent jusqu’à 17 % de poids sur Linux et Windows, et une build Windows ARM64 fait son entrée, à 75,1 Mo contre 90,2 Mo pour la 1.3.14.
Quinze dépendances passent en natif
Le changement le plus visible au quotidien tient dans le package.json : des tâches jusque-là déléguées à des paquets tiers sont désormais fournies par le runtime. Le tableau ci-dessous récapitule les principales correspondances.
| API native | Remplace |
|---|---|
Bun.Image | sharp |
Bun.WebView | puppeteer / playwright |
Bun.markdown | marked |
Bun.cron() | node-cron |
Bun.Terminal | node-pty |
Bun.JSON5 | json5 |
Bun.JSONL | ndjson |
Bun.XML | fast-xml-parser |
Bun.Archive | tar |
Bun.stringWidth / sliceAnsi / wrapAnsi | string-width, slice-ansi, wrap-ansi |
bun run --parallel | npm-run-all, concurrently |
En pratique, un script de traitement d’images ou une tâche planifiée n’exige plus d’installation externe.
// Redimensionner une image sans installer sharp
const thumb = await Bun.Image("photo.jpg")
.resize({ width: 640 })
.toBuffer({ format: "webp", quality: 80 });
// Planifier une tache sans node-cron
Bun.cron("0 3 * * *", () => {
console.log("Sauvegarde nocturne lancee");
});
Compatibilité Node.js et vitesse d’installation
Côté compatibilité, la version ajoute 1 517 tests de la suite Node.js désormais au vert, portant le total à 3 743 fichiers de tests réussis, contre 1 450 en 1.2.0. Les modules node:quic, node:events, node:trace_events et node:sqlite passent la totalité des tests de Node. Côté installation, bun install est annoncé quinze fois plus rapide que npm au premier passage sur une application Next.js de type T3 d’environ 220 paquets (1,41 s contre 18,1 s). Le nouveau « global virtual store », activé avec le linker isolé, atteint un facteur sept sur les installations à chaud en intégration continue, en créant des liens symboliques au lieu de recopier les paquets.
# Installation a froid : 15x plus rapide que npm sur ce projet
bun install
# Tests repartis sur 4 machines de CI, equilibres par duree
bun test --parallel --shard=1/4 --timings
# Deux scripts en parallele, sortie prefixee
bun run --parallel dev build
Quinze dépendances de moins dans un
package.json, c’est autant de surface de maintenance et d’audit en moins.
Point de vigilance. Le support HTTP/3 dans Bun.serve() reste expérimental, et l’intégration du React Compiler (annoncée vingt fois plus rapide que le plugin Babel) mérite une validation projet par projet. La réécriture Rust est transparente au niveau des API, mais une chaîne d’intégration continue existante gagne à être rejouée entièrement avant tout passage en production.
Ce qu’il faut retenir
Bun 1.4 déplace la frontière entre le runtime et l’écosystème npm : moins de dépendances à installer, des binaires plus légers, une empreinte mémoire réduite et une compatibilité Node.js qui progresse nettement. Les chiffres de démarrage et d’installation renforcent surtout l’argument outillage et intégration continue.
J’ai adopté Bun d’abord là où le risque est faible : scripts de build, tâches de CI, petits utilitaires. Voir Bun.Image ou Bun.cron remplacer des dépendances que je traîne depuis des années me convainc davantage que n’importe quel graphique de benchmark, parce que ça réduit ma dette réelle. Je reste prudent sur un point : concentrer autant de fonctions dans un seul runtime jeune crée une dépendance forte à un unique éditeur. Sur un service critique, je continue de valider chaîne de CI et charge avant de basculer, et je garde Node.js comme plan de repli documenté. — Simon Janvier
Pour aller plus loin
Notes de version complètes de Bun 1.4 : bun.com/blog/bun-v1.4.
