Integrierte Funktionen von Bun 1.4, die sharp, Puppeteer, node-pty und ähnliche Tools ersetzen können.

In einem typischen JavaScript-Projekt entsteht für jede benötigte Funktionalität eine Abhängigkeit: sharp für Bilder, ein Markdown-Parser, Playwright oder Puppeteer zur Automatisierung von Browsern, eine Cron-Bibliothek, node-pty für Pseudo-Terminals, concurrently oder npm-run-all für parallele Skripte sowie zahlreiche CI-Konfigurationen, um Tests zu beschleunigen. Bun 1.4 verfolgt einen anderen Ansatz: Viele dieser Aufgaben können direkt im Laufzeitumfeld ausgeführt werden. Dieser Leitfaden zeigt die neuen eingebauten Funktionen mit den notwendigen Beispielen, um jede davon auszuprobieren, und empfiehlt eine risikofreie Methode zur Bewertung derselben.

Laut der Veröffentlichungsmitteilung wurde Bun 1.4 am 20. August 2026 veröffentlicht, wobei mehr als 1.500 Kompatibilitätsprüfungen für Node.js hinzugefügt, über 2.900 Probleme behoben sowie der Leerlaufverbrauch von CPU und Speicher reduziert wurde. Die APIs in dieser neuen Version können sich weiterhin ändern, daher sollten Sie die untenstehenden Angaben als Momentaufnahme betrachten und sie gegen die offizielle Bun 1.4-Mitteilung sowie die aktuellen Dokumentationen überprüfen. Das Thema dieser Version liegt weniger bei der reinen Geschwindigkeit und mehr darin, die Toolchain zu verkleinern.

Installation oder Upgrade

Bun kann mit einem Shell-Skript, npm, Homebrew, PowerShell unter Windows oder als Docker-Image installiert werden. Jede benannte Zeile unten stellt eine Alternative dar; wählen Sie die, die zu Ihrer Umgebung passt:

--curl
curl -fsSL https://bun.sh/install | bash

--npm
npm install -g bun

--brew
brew install oven-sh/bun/bun

--powershell
powershell -c "irm bun.sh/install.ps1 | iex"

--docker
docker pull oven/bun

Falls Bun bereits auf Ihrem Rechner vorhanden ist, führt ein einziger Befehl Sie zur neuesten Version:

bun upgrade

Bildverarbeitung mit Bun.Image

Bun.Image bringt die Dekodierung, Anpassung der Größe, Drehung sowie Kodierung gängiger Formate in die Laufzeit mit, sodass Sie keine Abhängigkeit von nativen Bildformaten mehr benötigen. Die folgende Kette liest ein JPEG, passt es in ein 1024 mal 1024 großes Feld ein, wobei das Seitenverhältnis beibehalten wird, dreht es, kodiert es als WebP mit einer Qualität von 85 und schreibt das Ergebnis aus:

await Bun.file("photo.jpg")
  .image()
  .resize(1024, 1024, { fit: "inside" })
  .rotate(90)
  .webp({ quality: 85 })
  .write("thumb.webp");

Da jeder Schritt denselben Builder zurückgibt, wird ein Pipeline von oben nach unten wie eine Rezeptur abgearbeitet. Typische Anwendungen umfassen das Erstellen von Vorschaubildern bei Hochladen, die Anpassung der Größe von Avataren, die Umwandlung von JPEG in WebP, Bild-APIs sowie die Optimierung von Ressourcen vor deren Speicherung.

Bun gibt an, dass seine Implementierung in mehreren eigenen Benchmarks besser abschneidet als sharp, darunter beim Vergrößern und Kodieren eines 1080p PNG-Failers. Ein weiterer Vorteil ist die Entfernung eines nativen Moduls, das oft die Docker-Kompilationen sowie CI-Caches verkompliziert. Falls Sie auf fortgeschrittene sharp-Funktionen angewiesen sind, überprüfen Sie vor dem Umstieg, ob die von Ihnen verwendeten Operationen vorhanden sind.

Headless-Browser-Automatisierung mit Bun.WebView

Bun.WebView ist eine eingebaute API für Headless-Browser, mit der navigiert, geklickt, gescrollt, JavaScript ausgewertet und Screenshots aufgenommen werden können. Beachten Sie die await using-Deklaration: Sie verbindet die Lebensdauer des View mit dem umschließenden Scope, sodass der Browser automatisch freigegeben wird, wenn der Block beendet wird – auch bei Fehlern.

await using view = new Bun.WebView({
  width: 800,
  height: 600,
});

await view.navigate("https://bun.sh");
await view.click("a[href='/docs']");
const title = await view.evaluate("document.title");
await Bun.write(
  "page.png",
  await view.screenshot()
);

Das Skript öffnet eine Seite, folgt einem Link, liest den Dokumententitel und speichert einen Screenshot. Damit werden viele kleine Aufgaben erledigt, ohne dass ein vollständiges Automatisierungsframework hinzugefügt werden muss – wie Screenshot-Dienste, Smoke-Tests, Scraping-Hilfsmittel, Uptime-Prüfungen, Link-Checker sowie einfache QA-Workflows. Wenn Sie eine tiefere Kontrolle benötigen, bietet Bun.WebView einen Zugang zum Chrome DevTools Protocol. Für umfangreiche End-to-End-Suiten mit Anforderungen an verschiedene Browser ist jedoch vermutlich ein speziell entwickeltes Tool weiterhin die bessere Wahl.

Rendering von Markdown mit Bun.markdown

Bun.markdown wandelt Markdown in verschiedene Formate um. Die einfachste Variante gibt einen HTML-String zurück:

const html = Bun.markdown.html(
  "# Hello **world**"
);

Es kann auch direkt React-Elemente erzeugen, was nützlich ist, wenn eine Komponente eine README- oder Dokumentationsseite darstellt:

export default function Page() {
  return Bun.markdown.react(readme);
}

Die Darstellung kann weiter angepasst werden, beispielsweise um den Ausgabeformat für eine Terminalanzeige zu optimieren. GitHub-ähnliche Markdown-Erweiterungen wie Tabellen, Aufgabenlisten, Strichunterstreichung und Autolinks werden unterstützt. Dies eignet sich für Dokumentationsseiten, Entwicklerportale, Blogs, README-Ansichter, CLI-Hilfen, Wissensbasen sowie Interfaces, die von Modellen generiertes Markdown anzeigen.

Eine Einschränkung ist wichtiger als alle anderen: Die HTML-Ausgabe wird nicht gesäubert. Jedes Markdown von Benutzern, Dritten oder einem LLM muss vor dem Erreichen des Browsers durch einen Säuberungsmechanismus laufen, andernfalls besteht die Gefahr einer Skripteinbettung.

Geplante Aufgaben mit Bun.cron

Bun.cron() arbeitet in zwei Modi. Im ersten registriert es eine Aufgabe beim Scheduler des Betriebssystems: crontab unter Linux, launchd unter macOS sowie der Task Scheduler unter Windows. Die Aufruffunktion nimmt den Pfad zu einem Skript, eine Cron-Expression sowie einen Namen für die Aufgabe entgegen; diese führt jeden Montag um 02:30 einen Worker aus:

await Bun.cron(
  "./worker.ts",
  "30 2 * * MON",
  "weekly-report"
);

Da das Betriebssystem den Zeitplan steuert, wird die Aufgabe auch dann ausgeführt, wenn kein Bun-Prozess aktiv ist. Im zweiten Modus befindet sich der Zeitplan innerhalb des laufenden Prozesses, wodurch die Aufgabe hier alle fünf Minuten ausgelöst wird. Die using-Deklaration beendet die Aufgabe, wenn ihr Gültigkeitsbereich endet:

using job = Bun.cron(
  "*/5 * * * *",
  async () => {
    await cleanupTempFiles();
  }
);

Die Ausführungen überschneiden sich niemals, und explizite Zeitzonen werden unterstützt. Geeignete Anwendungen sind Reinigungsarbeiten, Berichte, Datenbankwartung, Datensynchronisierung, E-Mail-Gruppenversand sowie periodisches Abfragen. Beachten Sie, dass Prozessinterne Aufgaben beim Neustart des Prozesses verschwinden, und wenn Sie mehrere Kopien ausführen, wird jede davon ausgeführt – es sei denn, Sie fügen Koordination hinzu.

Skripte parallel ausführen

bun run --parallel ersetzt concurrently und npm-run-all. Geben Sie mehrere Skriptnamen an, um sie gleichzeitig auszuführen:

bun run --parallel build test

Glob-Patterns wählen eine Gruppe von Skripten aus:

bun run --parallel "build:*"

In Kombination mit --filter führt derselbe Flag ein Skript in jedem Arbeitsbereich aus:

bun run --parallel --filter '*' build

Normalerweise stoppt ein Fehler alles; --no-exit-on-error ermöglicht es den verbleibenden Aufgaben, abzuschließen, was nützlich ist, um alle Testfehler auf einmal zu sammeln:

bun run --parallel --no-exit-on-error --filter '*' test

Jede Ausgabelinie wird mit dem Skript vorangestellt, das sie erzeugt hat, sodass die miteinander verknüpften Protokolle weiterhin lesbar bleiben. In einem Monorepo ersetzt dies eine sequenzielle Abfolge durch Arbeiten, die auf den CPU-Kernen verteilt werden:

package A → build
package B → build
package C → build

Parallel laufende Prozesse verstehen keine Abhängigkeiten zwischen Paketen. Wenn daher ein Paket vor einem anderen gebaut werden muss, ist weiterhin eine bestimmte Reihenfolge oder ein Task-Runner erforderlich, der diese Abhängigkeiten berücksichtigt.

Schnellere Testläufe

bun test verfügt über ein --parallel-Flag:

bun test --parallel

Die Anzahl der Worker-Prozesse kann explizit festgelegt werden:

bun test --parallel=4

Die Dateien werden dynamisch an die Worker weitergeleitet, anstatt im Voraus in feste Gruppen aufgeteilt zu werden. Dadurch verhindert eine langsame Datei, dass andere Worker untätig bleiben. Drei damit verbundene Flags richten sich an CI-Umgebungen. Sharding verteilt die Testsuite auf mehrere Maschinen – hier wird der erste von drei Abschnitten verwendet:

bun test --shard=1/3

Das Ausführen nur der durch Ihre Änderungen betroffenen Tests verkürzt die lokalen Feedbackschleifen:

bun test --changed

Durch das Aufzeichnen der Dauer ermöglicht es spätere Ausführungen, die Arbeit mithilfe echter Zeitdaten auszugleichen:

bun test --timings=timings.json

Die parallele Ausführung bringt Tests zum Vorschein, die denselben Zustand teilen, wie beispielsweise eine gemeinsame Datenbank, feste Ports oder temporäre Dateien. Rechnen Sie damit, dass Sie bei erster Aktivierung einige Isolationsprobleme beheben müssen.

Beseitigung anfälliger Abhängigkeiten

Für die Sicherheitswartung gibt es einen integrierten Befehl:

bun audit fix

Er aktualisiert anfällige Pakete auf behobene Versionen und installiert sie. Wenn eine Behebung einen Major-Upgrade erfordert, meldet Bun dies anstelle der Anwendung; fügen Sie --latest hinzu, um dies zu aktivieren. Prüfen Sie diese Major-Updates genauso wie alle anderen brisanten Änderungen. In CI wird die Abhängigkeitssicherheit in den normalen Installationsvorgang integriert.

Beseitigung doppelter Abhängigkeiten

Große Projekte enthalten oft mehrere nahezu identische Versionen derselben Bibliothek:

esbuild@0.15.10
esbuild@0.15.11

Wenn eine einzige Version alle Anforderungen erfüllt, beseitigt dieser Befehl die Duplikate:

bun dedupe

Die Prüfvariante führt bei verbleibenden Duplikaten zu einem Fehler, was sie zu einer geeigneten CI-Sperre macht:

bun dedupe --check

Weniger Duplikate bedeuten kleinere Abhängigkeitsbäume, schnellere Installationen, geringeren Festplattennutzung, einfachere Wartung und potenziell kleinere Deployments.

Interaktive Programme mit Bun.Terminal steuern

Bun.Terminal ist ein eingebautes Pseudo-Terminal, das es JavaScript ermöglicht, interaktive Programme ohne node-pty zu steuern:

bash
vim
htop

Ein Pseudo-Terminal ist wichtig, weil solche Programme sich anders verhalten, wenn sie ein echtes Terminal erkennen: Sie zeichnen Vollbild-Oberflächen, verwenden Farben und erwarten Tasteneingaben. Dadurch ist Bun.Terminal für Entwicklerwerkzeuge, CLI-Tools, Terminal-Dashboards, Tools für die Fernentwicklung, interaktive Automatisierungsprogramme sowie KI-Code-Agenten relevant – diese arbeiten zunehmend direkt in einer Shell.

Kompatibilität mit Node.js und Next.js

Die Veränderung mit dem größten Einfluss könnte eher in der Kompatibilität liegen als in einer neuen API. Die Veröffentlichung fügt 1.517 Node.js-Tests hinzu und weist Verbesserungen in Modulen wie http, fs, stream, cluster, timers, zlib und vm auf. Zudem wird eine bessere Unterstützung in verschiedenen Kategorien hervorgehoben: Frameworks (Next.js 16, Nuxt, Fastify), Testwerkzeuge (Vitest, Playwright, Testcontainers), Observabilitätslösungen (OpenTelemetry sowie Datadogs dd-trace) sowie Daten- oder Infrastruktur-Clienten (TypeORM, RabbitMQ und AWS S3).

Der Flag --bun zwingt die CLI eines Tools dazu, unter Bun statt unter dem in seinem Shebang angegebenen Node.js-Binärdatei zu laufen. Laut der Veröffentlichung funktioniert dies mit Next.js 16.3, Turbopack und dem React Compiler:

bun --bun next build

Die Einführung hängt letztendlich davon ab, ob Ihre bestehende Anwendung den Umstieg überlebt – daher ist ein erfolgreicher Build Ihres eigenen Projekts wertvoller als jeder veröffentlichte Benchmark.

Leistungsangaben im Kontext

Buns Benchmarks für 1.4 zeigen bis zu fünfmal geringere Leerlauf-CPU-Auslastung, deutlich weniger Speicherverbrauch bei HTTP-Aufgaben sowie schnellere Startzeiten unter Linux und Windows. Es handelt sich dabei um von den Anbietern bereitgestellte Werte, die daher nur als Richtwerte zu verstehen sind. Geringere CPU-Auslastung, Speicherverbrauch und Startzeit können zu günstigeren, reaktiveren Diensten führen – doch nur Ihre eigenen Arbeitslasten können dies bestätigen. Für einen umfassenderen Überblick über die Laufzeit-Kompromisse finden Sie unseren Vergleich von Node.js, Deno und Bun.

Eine risikofreie Methode, um Bun 1.4 zu bewerten

Ein komplettes Produktionsystem umzustellen, ist selten klug. Kleine, rückgängig machbare Experimente funktionieren besser.

Eine neue API starten

Schaffen Sie ein Projekt-Struktur und bauen Sie mit Bun.serve einen kleinen Dienst:

bun init

Einen Bildverarbeitungsweg ersetzen

Übertragen Sie einen einzelnen sharp-Pipeline auf Bun.Image und vergleichen Sie die Ausgabequalität sowie die Laufzeit.

Eine geplante Aufgabe verschieben

Wählen Sie einen einfachen Cron-Job aus und implementieren Sie ihn erneut mit Bun.cron().

Ihre Tests parallelisieren

Führen Sie den vorhandenen Testumfang parallel aus und notieren Sie, welche Tests aufgrund gemeinsamer Zustände fehlschlagen:

bun test --parallel

Abhängigkeiten aufräumen

Probieren Sie die Befehle zur Sicherheitsprüfung und Entduplizierung in einer Branch aus und prüfen Sie den Diff:

bun audit fix
bun dedupe

Ihre Next.js-Anwendung unter Bun kompilieren

Führen Sie die Produktionsversion mit dem Bun-Runtime aus und vergleichen Sie sie mit Ihrem aktuellen Pipeline:

bun --bun next build

In jedem Fall sollten Sie die Ergebnisse selbst messen, anstatt sich auf veröffentlichte Benchmarks zu verlassen.

Der Konsolidierungstrend

Bun 1.4 konzentriert sich weniger auf eine Liste neuer APIs als vielmehr darauf, dass ein einziger Runtime alle Funktionen übernimmt, die früher separaten Paketen zugeordnet waren. Die grobe Struktur besteht aus einer Runtime-Schicht mit Node.js-APIs, einer Tooling-Schicht für Tests, Skripte, Sicherheit, CI und Terminals sowie einer Bibliotheks-Schicht für Bilder, Markdown, Browser und cron:

Bun 1.4
               │
     ┌─────────┼──────────┐
     │         │          │
 Runtime    Tooling    Libraries
     │         │          │
 Node.js     Testing    Image
 APIs        Scripts    Markdown
             Security   Browser
             CI         Cron
             Terminal

Das npm-Ökosystem gewann an Stärke durch die Kombination tausender kleiner Pakete, doch diese Stärke hat ihren Preis in Form von Abhängigkeiten, Konfigurationsaufwand, Kompatibilitätsproblemen, Sicherheitsupdates und fragmentierten Tools. Bun setzt auf das Gegenteil: Nützliche Grundfunktionen werden direkt im Runtime mitgeliefert.

Haupterkenntnisse

• Die wichtige Frage hat sich von „Ist Bun schneller als Node.js?“ auf „Welche Teile meines Technologiestacks könnte Bun ersetzen?“ verlagert.
• Built-ins verringern die Abhängigkeiten von nativen Bibliotheken, doch prüfen Sie vor dem Ersetzen etablierter Bibliotheken wie sharp oder Playwright die Funktionalitätsparität.
• Sanieren Sie die von Bun.markdown erzeugte HTML-Ausgabe immer dann, wenn die Eingabe unzuverlässig ist.
• Parallel laufende Skripte und Tests bringen schnelle Vorteile, doch sie bringen versteckte Probleme bezüglich der Reihenfolge und des gemeinsamen Zustands zum Vorschein.
• Betrachten Sie Hersteller-Benchmarks als Hypothese und überprüfen Sie jede Funktion anhand Ihrer eigenen Arbeitslasten, bevor Sie etwas umsetzen.