Bun 1.4, veröffentlicht am 20. August 2026, ist der bislang größte Architekturbruch des Runtimes: Die Engine wechselt von Zig zu Rust, und fünfzehn Bibliotheken, die das JavaScript-Ökosystem bisher separat installierte, werden zu eingebauten APIs. Die Ankündigung stützt sich auf drei gemessene Achsen: Node.js-Kompatibilität, Installationsgeschwindigkeit und Speicherverbrauch.
Eine in Rust neu geschriebene Engine
Der Wechsel von Zig zu Rust betrifft den Kern des Runtimes. Er war vor der Ankündigung nicht bloß theoretisch: Laut den Betreuern lief Claude Code seit Monaten auf dem Rust-Port, und Prisma brachte Prisma Compute darauf heraus. Die genannten Verbesserungen sind konkret. Die CPU-Last im Leerlauf einer „Hello World“-Anwendung sinkt um das Fünffache. HTTP-Server senken ihren Speicher um 13 % bis 48 %: ein Fastify-Dienst fällt von 233 MB auf 120 MB. Der Start ist unter Windows 2,5-mal schneller (39 ms auf 15,5 ms) und unter Linux 2-mal schneller (10,9 ms auf 5,1 ms). Die Binärdateien werden unter Linux und Windows bis zu 17 % kleiner, und ein Windows-ARM64-Build kommt mit 75,1 MB gegenüber 90,2 MB in 1.3.14 hinzu.
Fünfzehn Abhängigkeiten werden nativ
Die im Alltag sichtbarste Änderung steckt in der package.json: Aufgaben, die bisher an Drittanbieter-Pakete delegiert wurden, liefert nun das Runtime selbst. Die Tabelle fasst die wichtigsten Entsprechungen zusammen.
| Native API | Ersetzt |
|---|---|
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 |
In der Praxis braucht ein Bildverarbeitungs-Skript oder eine geplante Aufgabe keine externe Installation mehr.
// 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");
});
Node.js-Kompatibilität und Installationsgeschwindigkeit
Bei der Kompatibilität ergänzt die Version 1.517 neu bestandene Tests aus der Node.js-Suite und bringt die Gesamtzahl auf 3.743 bestandene Testdateien, gegenüber 1.450 in 1.2.0. Die Module node:quic, node:events, node:trace_events und node:sqlite bestehen 100 % der Node-Tests. Bei der Installation ist bun install laut Ankündigung beim ersten Durchlauf einer Next.js-App vom Typ T3 mit rund 220 Paketen 15-mal schneller als npm (1,41 s gegenüber 18,1 s). Der neue „global virtual store“ mit isoliertem Linker erreicht bei warmen CI-Installationen den Faktor sieben, indem er Pakete per Symlink verknüpft statt sie zu kopieren.
# 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
Fünfzehn Abhängigkeiten weniger in einer
package.jsonbedeuten ebenso viel weniger Pflege und Audit.
Zu beachten. Die HTTP/3-Unterstützung in Bun.serve() ist weiterhin experimentell, und die eingebaute React-Compiler-Integration (angekündigt als 20-mal schneller als das Babel-Plugin) sollte projektweise geprüft werden. Die Rust-Neufassung ist auf API-Ebene transparent, doch eine bestehende CI-Pipeline sollte vor jedem Produktionswechsel vollständig neu durchlaufen werden.
Was bleibt
Bun 1.4 verschiebt die Grenze zwischen Runtime und npm-Ökosystem: weniger Pakete zu installieren, leichtere Binärdateien, ein geringerer Speicherbedarf und eine deutlich wachsende Node.js-Kompatibilität. Die Start- und Installationswerte stärken vor allem das Argument für Werkzeuge und Continuous Integration.
Ich habe Bun zuerst dort eingesetzt, wo das Risiko gering ist: Build-Skripte, CI-Jobs, kleine Werkzeuge. Zu sehen, wie Bun.Image oder Bun.cron Abhängigkeiten ersetzen, die ich seit Jahren mitschleppe, überzeugt mich mehr als jedes Benchmark-Diagramm, weil es echte Schuld abbaut. Ein Vorbehalt hält mich zurück: so viele Funktionen in einem einzigen jungen Runtime zu bündeln, schafft eine harte Abhängigkeit von einem einzelnen Anbieter. Bei einem kritischen Dienst prüfe ich weiter CI-Pipeline und Last, bevor ich wechsle, und behalte Node.js als dokumentierten Rückfallplan. — Simon Janvier
Zum Weiterlesen
Vollständige Release Notes zu Bun 1.4: bun.com/blog/bun-v1.4.
