Zurück

Bun ist nicht das schnellere Node.js. Es ist eine andere Plattform.

Werkstatt · Entwurf für teblo.de · Stand: 2. September 2026

Wenn man Bun eine Weile benutzt, entsteht schnell ein ziemlich simples Bild: Bun ist Node.js, nur schneller.

bun install rennt. TypeScript läuft ohne vorgeschalteten Build-Schritt. Kleine Tools starten praktisch sofort. Und auch in vielen Benchmarks sieht Node.js daneben plötzlich ziemlich alt aus.

Ich bin auf dieselbe Erzählung hereingefallen.

Der Auslöser war mein eigener Markdown-Parser Markanto. Als ich ihn gegen marked laufen ließ, sah das Ergebnis zunächst spektakulär aus: Unter Bun war Markanto ungefähr 50-mal schneller. Unter Node.js dagegen nur rund 1,8-mal.

Die erste Reaktion liegt auf der Hand:

Bun macht meinen Parser rasend schnell.

Nur war das nicht die interessanteste Erklärung.

Die interessantere Frage lautete:

Was, wenn Bun meinen Parser gar nicht außergewöhnlich stark beschleunigt – sondern marked außergewöhnlich langsam ausführt?

Damit wird aus einem Benchmark plötzlich eine Architekturfrage.

Und genau dort wird Bun interessant.

Bun ist keine optimierte Ausgabe von Node.js

Bun will für viele Anwendungen ein Drop-in-Ersatz für Node.js sein. Das heißt aber nicht, dass darunter dieselbe Maschine arbeitet.

Node.js basiert auf V8, der JavaScript-Engine aus dem Chromium-Umfeld.

Bun basiert auf JavaScriptCore, kurz JSC, der JavaScript-Engine aus WebKit.

Darüber baut Bun sehr viel selbst: Runtime, Package Manager, Bundler, Test Runner, TypeScript-Ausführung, I/O-APIs und inzwischen eine ganze Reihe nativer APIs.

Für die Praxis hilft deshalb ein einfaches Zwei-Schichten-Modell:

Die Bun-kontrollierte Schicht

Hier kann das Bun-Team Architektur und Implementierung weitgehend selbst bestimmen. Dazu gehören zum Beispiel Package Manager, Bundler, viele Runtime-APIs, Startup-Verhalten oder TypeScript-Integration.

Die von JavaScriptCore geerbte Schicht

Hier bringt Bun die Eigenschaften der verwendeten JavaScript-Engine mit: JIT-Verhalten, Teile der Sprachimplementierung, Garbage Collection – und eben auch die Regex-Engine.

Diese Trennung erklärt erstaunlich viel.

Sie erklärt einige der spektakulärsten Stärken von Bun.

Und einige seiner überraschendsten Schwächen.

Die unsichtbare Regex-Falle

Bei meinem Markdown-Test führte die Spur ziemlich schnell zu regulären Ausdrücken.

marked arbeitet stark mit Regex. Markanto wesentlich weniger.

V8 und JavaScriptCore verwenden dafür unterschiedliche Implementierungen. In JavaScriptCore steckt die Regex-Engine Yarr, V8 verwendet Irregexp.

Dass sich diese beiden Engines bei bestimmten Mustern drastisch unterschiedlich verhalten können, ist kein theoretisches Problem.

Im Juni 2023 meldete ein Bun-Nutzer, dass marked mit Bun 0.6.11 rund 1,5 Sekunden für ein Dokument benötigte, Node.js dagegen etwa 70 Millisekunden. Das Bun-Projekt versah das Issue mit den Labels jsc und performance. Der Reporter konnte den Effekt außerdem in einer anderen WebKit-basierten Umgebung reproduzieren.

Ein paar Monate später folgte ein noch extremerer Fall: Ein Regex aus isbot benötigte unter Bun 1.0.1 für denselben Test rund 65 Sekunden, Node.js etwa 200 Millisekunden.

Mehr als Faktor 300.

Das waren reale Probleme. Aber beide Befunde stammen aus dem Jahr 2023.

Und genau hier wird es journalistisch interessant.

Denn Copy-Paste-Journalismus funktioniert bei Benchmarks besonders gut. Eine spektakuläre Zahl wird veröffentlicht, abgeschrieben, weiterzitiert und irgendwann vom Messergebnis zur vermeintlichen Produkteigenschaft.

Nur altern Software und JavaScript-Engines schneller als viele Artikel.

Deshalb reicht es 2026 nicht, einen drei Jahre alten 300×-Benchmark hervorzuholen und daraus eine heutige Schwäche von Bun abzuleiten.

Also messen wir selbst.

Der Gegencheck 2026: Markanto, marked, Node und Bun

Dieser Abschnitt wird nach Durchführung des reproduzierbaren Benchmarks finalisiert.

Geplant ist eine 2×2-Messung mit derselben Eingabe und denselben Parser-Versionen:

Parser Node 26 Bun 1.4 Bun/Node
Markanto TODO TODO TODO
marked.lexer() TODO TODO TODO
marked.parse() TODO TODO TODO

Zusätzlich wird der historische isbot-/Regex-Fall von 2023 mit heutigen Runtime-Versionen erneut ausgeführt.

Falls der Effekt weiterhin deutlich sichtbar ist

Dann kann dieser Abschnitt sinngemäß so enden:

Der interessante Wert ist nicht der Abstand zwischen Markanto und marked, sondern die Bewegung beim Wechsel der Runtime. Markanto wird unter Bun schneller, marked bewegt sich in die entgegengesetzte Richtung. Derselbe Runtime-Wechsel wirkt auf zwei JavaScript-Parser also völlig unterschiedlich. Genau das ist der Punkt: „Bun ist schneller“ beschreibt keine allgemeine Eigenschaft von JavaScript-Code.

Falls der historische Effekt weitgehend verschwunden ist

Dann lautet die interessantere Pointe:

Das Problem war real – aber es war kein Naturgesetz. JavaScriptCore hat sich weiterentwickelt. Wer heute nur die spektakulären Zahlen von 2023 abschreibt, misst nicht Bun 1.4, sondern Softwaregeschichte. Auch das bestätigt die eigentliche These: Performance hängt hier an der Engine und ihrer konkreten Version, nicht an einem ewigen Etikett „Bun schnell“ oder „Bun langsam“.

Temporal zeigt dieselbe Grenze – ganz ohne Benchmark

Regex könnte man noch als Performance-Sonderfall abtun.

Temporal macht die zugrunde liegende Architektur deutlicher.

Node.js 26 aktivierte die neue Temporal-API im Mai 2026 standardmäßig. Die eigentliche Arbeit steckte zu diesem Zeitpunkt längst in V8; für Node war die Aktivierung im Wesentlichen ein Umschalten des vorhandenen Features.

Bei Bun sah es zunächst anders aus.

Das Feature-Issue für Temporal war seit Ende 2024 offen und als JavaScriptCore-Thema markiert. Anfang 2025 lag die Test262-Konformität der JSC-Implementierung laut Bun noch grob bei 40 Prozent.

Dann entwickelte sich JavaScriptCore weiter.

Am 5. August 2026 wurde in Bun der Pull Request „Enable Temporal by default“ gemergt. Bemerkenswert ist, was dieser PR tatsächlich tat: Er aktivierte die bereits vorhandene Temporal-Implementierung von JavaScriptCore standardmäßig.

Zu diesem Zeitpunkt bestand die Core-Suite von Test262 laut den im PR dokumentierten Messungen vollständig. Die verbliebenen Abweichungen lagen bei nicht-ISO-Kalendern – und wurden im PR ausdrücklich als upstream JavaScriptCore beschrieben.

Bun 1.4 liefert Temporal deshalb inzwischen standardmäßig aus.

Das ist kein Makel. Im Gegenteil: Genau dafür verwendet man eine vorhandene JavaScript-Engine.

Aber es zeigt die Grenze der Plattform sehr sauber.

Das Bun-Team kann JSC patchen, WebKit aktualisieren, upstream beitragen und eigene Integrationsentscheidungen treffen. Es kontrolliert die Entwicklungsrichtung von JavaScriptCore aber nicht so, wie es seinen eigenen Package Manager oder seine eigenen Runtime-APIs kontrolliert.

Dasselbe gilt übrigens für Node.js und V8. Auch Node bestimmt nicht allein über V8.

Der Unterschied liegt nicht in „Kontrolle“ versus „keine Kontrolle“.

Der Unterschied liegt darin, welche Teile der Plattform das jeweilige Projekt selbst baut und welche Eigenschaften es von seiner Engine erbt.

Warum sich Bun trotzdem so viel schneller anfühlt

Damit wären wir bei der anderen Hälfte der Geschichte.

Denn Bun ist an vielen Stellen bemerkenswert schnell.

Nur sind die Gründe konkreter als „Bun führt JavaScript schneller aus“.

Nehmen wir bun install.

Auf der aktuellen Bun-Seite wird für einen T3-Stack bei warmem Cache ein Median von 0,21 Sekunden angegeben. npm 12 benötigt im selben veröffentlichten Test 4,45 Sekunden.

Das ist kein Unterschied, über den man philosophieren muss.

Den merkt man.

Oder Startup-Zeiten. Kleine CLI-Tools und Skripte profitieren davon unmittelbar. TypeScript kann ohne separate Konfigurations- und Transpilationsrunde ausgeführt werden. Bundler, Test Runner und Package Manager gehören zur selben Toolchain.

Auch das merkt man.

Und genau darin steckt ein Wahrnehmungseffekt:

Was wir als Entwickler täglich sehen, prägt unser Bild einer Runtime stärker als das, was tief in einer Dependency passiert.

Ein bun install, das sofort fertig ist, erzeugt jedes Mal ein kleines positives Feedback.

Ein Regex, der tief in einer Bibliothek auf JavaScriptCore schlecht läuft, erzeugt dagegen nur ein diffuses „Warum ist das hier eigentlich langsam?“.

Das eine ist sichtbar.

Das andere versteckt sich.

Benchmarks beantworten meistens eine kleinere Frage, als ihre Überschrift behauptet

Bun veröffentlicht beeindruckende Benchmarks.

Das ist legitim. Node.js, Datenbanken, Compiler und praktisch jede andere Performance-orientierte Software tun dasselbe.

Problematisch wird es erst, wenn aus

Bun verarbeitet diesen HTTP-Hello-World-Test schneller

die Aussage

Bun-Anwendungen sind schneller als Node-Anwendungen

wird.

Das folgt nicht daraus.

Ein Microbenchmark isoliert bewusst einen kleinen Ausschnitt. Genau dafür ist er nützlich.

Eine reale Anwendung besteht aber aus Datenbankzugriffen, Netzwerk, Dateisystem, Serialisierung, Framework-Code, Dependencies und eigener Architektur.

Je größer der Anteil dieser Komponenten wird, desto kleiner kann der Anteil der JavaScript-Runtime an der Gesamtzeit werden.

Andererseits gibt es Workloads, bei denen genau Runtime, Startup oder I/O entscheidend sind.

Deshalb ist auch das Gegenklischee falsch:

Die Runtime spielt in Produktion sowieso keine Rolle.

Natürlich kann sie eine Rolle spielen.

Nur beantwortet ein Benchmark immer zuerst die Frage, die tatsächlich gemessen wurde – nicht die größere Behauptung in der Überschrift.

Und dann kam Anthropic

Seit Dezember 2025 gehört Bun zu Anthropic.

Das verändert die Risikobetrachtung durchaus.

Ein kleines Runtime-Projekt kann verschwinden, Finanzierung verlieren oder seine Prioritäten ändern. Mit Anthropic steht hinter Bun heute ein Unternehmen, das Bun selbst intensiv nutzt und öffentlich angekündigt hat, weiter in Runtime, Bundler, Package Manager und Test Runner zu investieren.

Das ist ein erhebliches Signal für Kontinuität.

Aber eine Firmenübernahme verwandelt JavaScriptCore nicht in eine Anthropic-Engine.

Auch mit mehr Geld, Entwicklern und Einfluss bleibt die grundlegende Architektur dieselbe: Bun baut auf JSC auf.

Und das ist weder gut noch schlecht.

Es ist eine technische Eigenschaft, die man bei einer Plattformentscheidung kennen sollte.

Also: Wann Bun, wann Node?

Ich würde die Entscheidung nicht nach Projektgröße treffen.

Nicht „Einzelentwickler = Bun“ und „Unternehmen = Node“.

Sondern nach Workload und Anforderungen.

Für Tooling, CLI-Programme, CI, Skripte und kurze Prozesse ist Bun ausgesprochen attraktiv. Startup, integriertes TypeScript und die schnelle Toolchain sind dort keine synthetischen Benchmarkwerte, sondern Teil der täglichen Arbeit.

Für Serverless und kurzlebige Worker können Startup-Zeit und Speicherverbrauch ebenfalls direkt relevant sein.

Bei klassischen datenbanklastigen Webanwendungen sagt dagegen ein HTTP-Microbenchmark erstaunlich wenig. Dort sollte die eigene Anwendung gemessen werden.

Bei dependency-lastigen Projekten lohnt ein zusätzlicher Blick auf Kompatibilität und Engine-Eigenheiten. Dass ein npm-Paket unter Node hervorragend läuft, garantiert noch keine identische Performancecharakteristik unter JavaScriptCore.

Und wer eine Plattform für viele Jahre standardisieren möchte, sollte neben Geschwindigkeit auch Release-Modell, Kompatibilität, Governance und eigene Abhängigkeiten betrachten.

Eine andere Plattform

Bun ist schnell.

Manchmal spektakulär schnell.

Aber nicht deshalb, weil jemand Node.js genommen, ein paar Schrauben angezogen und das Ergebnis neu kompiliert hätte.

Bun kombiniert eine eigene Runtime und eine eng integrierte Toolchain mit JavaScriptCore. Dort, wo Bun selbst gestaltet, entstehen einige seiner größten Vorteile. Dort, wo Verhalten und Performance aus JSC kommen, erbt Bun auch dessen Stärken, Eigenheiten und Grenzen.

Das macht Bun nicht schlechter.

Es macht die Gleichung

Bun = schnelleres Node.js

nur ziemlich unbrauchbar.

Die bessere Frage lautet:

Welche Plattform passt zu meinem Code – und was messe ich eigentlich, wenn ich behaupte, sie sei schneller?

Mein eigener Parser hat mich ausgerechnet deshalb auf diese Frage gebracht, weil ein 50×-Benchmark zunächst so wunderbar eindeutig aussah.

War er nur nicht.

Und genau deshalb lohnt sich das Nachmessen.

Quellen und Hinweise

Kommentar schreiben