Bun statt Node.js: Ein praktischer Einstieg

Bun ist eine JavaScript-Runtime, die Node.js ersetzen will. Das Versprechen: schnellere Starts, schnellere Builds, weniger Tools. Aber wie sieht das in der Praxis aus?

Installation

Bun lässt sich mit einem Befehl installieren:

# macOS, Linux, WSL
curl -fsSL https://bun.sh/install | bash

# Windows (PowerShell)
powershell -c "irm bun.sh/install.ps1 | iex"

# Homebrew
brew install oven-sh/bun/bun

Nach der Installation ist bun im Terminal verfügbar:

bun --version

Erste Schritte

Bun kann Node.js-Projekte direkt ausführen:

bun run index.ts

TypeScript funktioniert ohne Konfiguration. Kein ts-node, kein tsconfig.json für einfache Skripte.

Neues Projekt erstellen:

bun init

Das erzeugt eine minimale Projektstruktur mit package.json, tsconfig.json und einer index.ts.

Befehle im Vergleich

Aktion	Node.js	Bun
Skript ausführen	`node index.js`	`bun index.js`
TypeScript ausführen	`npx ts-node index.ts`	`bun index.ts`
Dependencies installieren	`npm install`	`bun install`
Paket hinzufügen	`npm install express`	`bun add express`
Dev-Dependency	`npm install -D vitest`	`bun add -d vitest`
Skript aus package.json	`npm run dev`	`bun run dev`
Tests ausführen	`npm test`	`bun test`

Die Befehle sind ähnlich genug, dass der Wechsel leicht fällt.

Migration von Node.js

Für die meisten Projekte reicht es, npm durch bun zu ersetzen:

# Statt npm install
bun install

# Statt npm run dev
bun run dev

Bun erstellt eine bun.lockb (Binär-Lockfile) statt package-lock.json. Beide können parallel existieren.

Was funktioniert:

Express, Fastify, Hono
Prisma, Drizzle
React, Vue, Svelte
Die meisten npm-Pakete

Was Probleme machen kann:

Native Node.js-Addons (C++-basiert)
Pakete, die node-gyp brauchen
Sehr alte Pakete mit veralteten APIs

package.json Scripts

Bun führt Scripts schneller aus, weil kein separater Prozess gestartet wird:

{
  "scripts": {
    "dev": "bun --watch src/index.ts",
    "build": "bun build src/index.ts --outdir dist",
    "test": "bun test"
  }
}

Der --watch Flag startet den Server bei Dateiänderungen neu.

Integrierter Test-Runner

Bun bringt einen Jest-kompatiblen Test-Runner mit:

// math.test.ts
import { expect, test } from "bun:test";

test("addition", () => {
  expect(2 + 2).toBe(4);
});

bun test

Die meisten Jest-Matcher funktionieren. Mocking ist eingebaut.

Wann lohnt sich der Wechsel?

Gute Kandidaten:

Neue Projekte ohne Legacy-Abhängigkeiten
TypeScript-Projekte (kein Setup nötig)
Skripte und CLI-Tools
APIs mit modernen Frameworks (Hono, Elysia)

Besser bei Node.js bleiben:

Projekte mit vielen nativen Addons
Enterprise-Umgebungen mit strikten Vorgaben
Wenn das Team Node.js gut kennt und Bun nicht

Hybride Nutzung: Bun für lokale Entwicklung, Node.js für Production – funktioniert oft problemlos.

Performance-Unterschiede

Die oft zitierten “4x schneller”-Zahlen beziehen sich auf Startzeiten und bestimmte Operationen. In der Praxis:

Spürbar schneller: bun install, Skript-Starts, Tests
Ähnlich schnell: HTTP-Server unter Last (I/O-bound)
Manchmal langsamer: Spezielle Node.js-Optimierungen

Für die meisten Projekte ist der Performance-Unterschied angenehm, aber nicht der Hauptgrund für den Wechsel.

Wer Bun von Grund auf strukturiert lernen will – von der Installation bis zum Einsatz in eigenen Projekten – findet auf learn.casoon.dev einen passenden Kurs dazu.

Quellen

Wann sich der Wechsel von Node.js zu Bun lohnt

Aus der Praxis: Bun ist kein universeller Node.js-Ersatz, aber in klar abgegrenzten Bereichen ein echter Produktivitätsgewinn.

Lohnt sich klar:

Bei neuen TypeScript-Projekten: Native TypeScript-Ausführung ohne tsx/ts-node spart Build-Konfiguration und ist messbar schneller (Hot-Reload typisch 40–70 % schneller).
Bei Test-Suite-Performance: bun test ist 2–10x schneller als Jest. Bei großen Codebases mit 1.000+ Tests macht das einen Unterschied von Minuten pro Lauf.
Bei reinen API-Backends ohne tiefe NPM-Dependencies: Hier zeigt Bun seine vollen Geschwindigkeitsvorteile (HTTP-Server-Performance 3–5x höher als Node.js).
Bei Monorepos mit komplexen Build-Pipelines: bun install ist typisch 5–25x schneller als npm install — bei Monorepos mit 50+ Paketen wird das spürbar.

Lohnt sich nicht oder ist riskant:

In Production-Systemen mit strengen LTS-Anforderungen: Bun hat kein klassisches LTS-Modell wie Node.js. Bei regulierten Branchen (Banking, Healthcare) ist Node.js LTS die sicherere Wahl.
Bei Anwendungen mit tiefen Native-Modulen: node-gyp-basierte Pakete (canvas, sharp, sqlite3) funktionieren mit Bun, aber nicht immer mit identischem Verhalten. Edge-Cases können Stunden Debugging kosten.
In Teams ohne Bun-Erfahrung mit kurzen Deadlines: Die ersten 1–2 Wochen sind oft holprig — manche NPM-Pakete verhalten sich unter Bun anders, manche Tooling-Plugins fehlen.

Was bei der Migration konkret zu erwarten ist

Aus realen Migrations-Projekten:

Kleine API mit Express: 1–2 Tage Aufwand. Hauptproblem: einzelne Middlewares oder Logging-Bibliotheken brauchen Workarounds.
Mittlere App mit komplexen Build-Pipelines: 1–2 Wochen. CI/CD-Anpassungen, Docker-Images, Monitoring-Tooling — alles muss neu evaluiert werden.
Große Enterprise-Anwendung: Vorerst meist nicht empfehlenswert. Risiken überwiegen die Geschwindigkeitsvorteile.

Faustregel: Wer neu anfängt, kann Bun ohne große Bedenken nutzen. Wer einen funktionierenden Node.js-Stack hat, sollte nur dann wechseln, wenn die Geschwindigkeitsgewinne (Tests, Builds, Dev-Loop) wirklich Engpass sind — nicht nur “nice to have”.