Bun 2.0, Deno 3 und Node.js im Jahr 2026: Benchmarks, Kompatibilität und welche Runtime Sie wählen sollten

Drei Runtimes, ein Ökosystem, echte Trade-offs

Die JavaScript-Runtime-Landschaft hat sich seit 2023 drastisch verändert. Bun brachte 1.0 in jenem Jahr und meldete Benchmark-Siege an, die man kaum ignorieren konnte. Deno schwenkte von seiner ursprünglichen Anti-npm-Haltung um und öffnete sich für die Node.js-Kompatibilitätsschicht. Node.js veröffentlichte große Releases, die in Node 24 gipfelten. Mitte 2026 stellt sich nicht mehr die Frage, welche Runtime theoretisch die beste ist, sondern welche messbare Vorteile für bestimmte Workloads bietet – und welche Sie tatsächlich deployen können, ohne Ihren Stack neu zu schreiben.

Die Kurzantwort: Bun 2.0 ist die schnellste Wahl für I/O-lastige Server-Workloads und Scripting-Aufgaben. Node.js bleibt die kompatibelste und am meisten erprobte Option. Deno 3 ist die beste Wahl für sicherheitsorientierte Deployments und Teams, die moderne Standardeinstellungen von Haus aus wünschen. Keines ist universell überlegen.

Bun 2.0: Was sich tatsächlich geändert hat

Bun 2.0, das Anfang 2026 erschien, baute auf der JavaScriptCore-Engine (der Engine hinter Safari) und einer nativen, auf Zig basierenden Runtime auf. Die Spitzenwerte aus den offiziellen Bun-Benchmarks:

• Startup-Zeit: Bun 2.0 startet einen einfachen HTTP-Server in ~6 ms vs. Node 24 mit ~45 ms und Deno 3 mit ~22 ms
• HTTP-Durchsatz: Buns eingebautes Bun.serve() verarbeitet ~120.000 Requests/Sekunde auf einem einzelnen Kern (M2 MacBook Pro) vs. ~75.000 für Node mit uWS und ~90.000 für Deno
• Datei-I/O: Bun.file()-Reads sind 2–3x schneller als das fs-Modul von Node, dank direkter OS-Level-Aufrufe
• TypeScript-Ausführung: Bun transpiliert und führt .ts-Dateien nativ aus – kein tsc, kein ts-node-Overhead

Bun 2.0 brachte auch einen neu geschriebenen Package Manager. Die Installation von 1.000 npm-Packages dauert in Bun etwa 800 ms vs. ~4 s in npm 10 und ~2,5 s in pnpm. Das Lockfile-Format wurde in 2.0 geändert und ist nun binär für Geschwindigkeit, was einige CI-Pipelines brach, die das alte Textformat parsten.

Der Haken: Buns Node.js-Kompatibilität liegt laut eigenen Schätzungen bei etwa 95 %. Die 5%ige Lücke umfasst Randfälle in node:cluster, einige node:vm-Verhaltensweisen und bestimmte native Addon (napi)-Muster. Für die meisten Apps, die auf Express, Fastify oder Hono basieren, ist die Lücke unsichtbar. Für Enterprise-Apps mit tiefen nativen Modulabhängigkeiten kann sie ein Migrationshindernis sein.

Deno 3: Der pragmatische Richtungswechsel

Deno 3, das Ende 2025 erschien, vollendete den Weg von einer eigenwilligen Alternative zu einem pragmatischen Node.js-Ersatz. Die größten Änderungen:

• npm:-Kompatibilität: Deno 3 führt die meisten npm-Packages ohne Kompatibilitäts-Flag aus und beseitigt damit einen großen Reibungspunkt aus Deno 1.x
• Deno Deploy v2: Engere Integration mit der Edge-Deployment-Plattform, mit V8-Isolate-Cold-Starts unter 5 ms weltweit
• Integrierter Linter und Formatter: deno lint und deno fmt sind jetzt deutlich schneller (3–5x) dank einer Rust-Neufassung
• Berechtigungsmodell: Das explizite Berechtigungssystem (--allow-net, --allow-read) wurde mit feineren Steuerungsmöglichkeiten ausgereift und ist bei vertrauenswürdigen Skripten nun ein Opt-out statt Opt-in

Der HTTP-Durchsatz von Deno 3 liegt zwischen Bun und Node. Was es an Rohgeschwindigkeit einbüßt, holt es in der Sicherheitshaltung wieder auf: Standardmäßig kann ein Deno-Prozess weder Ihr Dateisystem lesen noch Netzwerkaufrufe tätigen, es sei denn, Sie erlauben es explizit. Für compliance-sensitive Umgebungen – Gesundheitswesen, Fintech, Behörden – ist das kein Nice-to-have, sondern eine Deployment-Voraussetzung.

Denos Standardbibliothek (deno.land/std) erreichte 2025 die 1.0-Stabilität, was bedeutet, dass APIs sich nicht mehr zwischen Minor-Versionen ändern. Das war die letzte große Zuverlässigkeitsbeschwerde von Produktionsnutzern.

Node.js im Jahr 2026: Immer noch der Standard

Node 24 (LTS ab 2026) führte mehrere Funktionen ein, die die Lücke zu Wettbewerbern schließen:

• Native fetch: Stabil, nicht länger hinter einem Flag
• Eingebauter Test Runner: node:test ist ausgereift genug, um Jest für die meisten Anwendungsfälle zu ersetzen
• Berechtigungsmodell (experimentell): Node hat Denos Idee mit --experimental-permission-Flags übernommen
• TypeScript-Stripping: Node 24 kann .ts-Dateien ausführen, indem es Typannotationen entfernt (keine vollständige Typprüfung), ähnlich wie Bun, aber ohne Transpilierung

Node.js hält laut der Stack-Overflow-Developer-Survey 2026 etwa 72 % der Produktions-JavaScript-Server-Deployments. Die Tiefe des Ökosystems ist der Grund: 2,3 Millionen Packages auf npm, ausgereifte Monitoring-Integrationen (Datadog, New Relic, OpenTelemetry) und ein Jahrzehnt dokumentierter Produktionsmuster. Der Wechsel von Node zu Bun für ein 10 Jahre altes Fintech-Monolithen ist eine Risiko-Ertrags-Rechnung, die selten für den Wechsel spricht.

Ökosystem-Kompatibilität in der Praxis

Die Kompatibilitätsmatrix, die für Produktionsentscheidungen tatsächlich zählt:

• Express.js: Läuft auf allen drei; Bun ist am schnellsten
• Next.js: Nur Node (Vercel kontrolliert die Runtime); Bun-Support ist experimentell
• Prisma ORM: Node und Bun werden unterstützt; Deno-Support über die npm:-Kompatibilitätsschicht
• Vitest: Alle drei, aber Bun bringt seinen eigenen Test Runner mit (bun:test), der API-kompatibel mit Jest ist
• Native Addons (.node-Dateien): Zuverlässig nur Node; Bun 2.0 verbesserte napi, aber es bleiben Lücken; Deno hat eingeschränkten Support
• AWS Lambda: Node 22 ist die offizielle Runtime; Bun funktioniert über eine Custom Layer; Deno funktioniert über eine Custom Layer

Welche Runtime im Jahr 2026 verwenden?

Verwenden Sie Bun 2.0, wenn: Sie neue Greenfield-APIs, CLI-Tools oder Skripte bauen, bei denen die Startup-Geschwindigkeit zählt; Ihr Team TypeScript schreibt und eine lokale Entwicklung ohne Build-Schritt wünscht; Sie nicht von nativen Addons oder Next.js abhängig sind.

Verwenden Sie Deno 3, wenn: Sicherheit und Auditierbarkeit oberste Priorität haben; Sie eine Batterien-inklusive-Runtime (Formatter, Linter, Test Runner, Deployment-Plattform) ohne Konfigurationsaufwand wünschen; Sie Edge-Deployments über Deno Deploy anstreben.

Bleiben Sie bei Node.js, wenn: Ihre Anwendung tiefe npm-Abhängigkeitsketten mit nativen Modulen hat; Sie zertifizierte LTS-Stabilität für regulierte Branchen benötigen; Die Toolchain Ihres Teams (CI, APM, Deployment-Plattform) Node-spezifisch ist und die Migrationskosten die Leistungsgewinne überwiegen.

Die Benchmark-Falle: Die meisten synthetischen Benchmarks messen den HTTP-Handler-Durchsatz auf einer leeren Route. Reale Anwendungen verbringen den Großteil ihrer Zeit mit dem Warten auf Datenbanken, externe APIs und Speicher – Bereiche, in denen die Runtime weit weniger zählt als die Query-Muster und die Netzwerktopologie. Eine 4x schnellere Startup-Zeit spart Millisekunden bei Lambda-Cold-Starts, nicht Sekunden bei einer Antwortzeit, die von einer 200 ms Postgres-Query dominiert wird.

Was Sie tatsächlich tun sollten

Führen Sie Ihre eigenen Benchmarks mit Ihrem tatsächlichen Workload durch, bevor Sie migrieren. Buns bun run-Kompatibilität bedeutet, dass Sie es in die meisten Node-Projekte einfügen und bun install && bun run start in unter fünf Minuten ausführen können, um zu sehen, ob Ihre Testsuite durchläuft. Denos --compat-Modus senkt ähnlich die Testkosten. Beide sind mittlerweile gut genug in der Node-Kompatibilität, dass die Entdeckungskosten für das Ausprobieren gering sind. Die Migrationskosten für den tatsächlichen Wechsel der Produktionsinfrastruktur sind es nicht.