Bun vs Deno
Bun (Zig-Runtime, dreimal so schnell) vs Deno (Rust-Runtime, TypeScript-first) — Vergleich moderner Node.js-Alternativen. Performance, Kompatibilität, Ökosystem.
Content-addressable Store, strikte Isolation, ausgereifte Lieferketten-Kontrolle
Rust-Kern, schnell, die Installationskomponente der All-in-One-Runtime Bun
Es gibt keinen eindeutigen Sieger; beide Tools optimieren auf unterschiedliche Prioritäten. Wenn du runtime-unabhängig bleiben und die Richtlinie bei jedem lockfile-ändernden Befehl durchsetzen willst, wähle pnpm. Wenn du Bun bereits als Runtime einsetzt und der Disk-/Geschwindigkeitsgewinn des globalen Virtual Store entscheidend ist, ist bun install attraktiv. Beide blockieren postinstall standardmäßig; der Unterschied liegt darin, wo die Kontrollpunkte sitzen. Mische beide nicht im selben Repo — eine Lockfile, eine Quelle der Wahrheit.
| Kategorie | pnpm | bun install |
|---|---|---|
| Performance | 8/10 | 9/10 |
| Erlernbarkeit | 7/10 | 8/10 |
| Ökosystem | 9/10 | 6/10 |
| Community | 8/10 | 7/10 |
| Arbeitsmarkt | 7/10 | 6/10 |
| Zukunftssicherheit | 8/10 | 8/10 |
// pnpm 12.3 — kontrollierte Installation mit allowBuilds und Workspace-Filterung
// package.json (Root)
{
"name": "monorepo-root",
"private": true,
"packageManager": "[email protected]"
}
// pnpm-workspace.yaml — allowBuilds kam in v10.26.0; v11 entfernte die alten Namen (onlyBuiltDependencies usw.)
packages:
- "apps/*"
- "packages/*"
allowBuilds:
esbuild: true
sharp: true
core-js: false
catalog:
react: ^19.2.3
typescript: ^5.7.0
// CI-Installationsschritt (GitHub Actions)
- name: Install dependencies
run: pnpm install --frozen-lockfile --trust-policy=no-downgrade
// Beim Entfernen eines Pakets wird die gesamte Lockfile erneut gegen die aktiven Richtlinien validiert
pnpm remove left-pad --filter ./apps/web --trust-lockfile
// Installation nur für geänderte Workspace-Pakete
pnpm install --filter "...[origin/main]"
// Store-Pfad zum CI-Cache-Schlüssel hinzufügen
pnpm store path// Bun 1.4 — Isolated Installs + globaler Virtual Store + Offline-Installation
// bunfig.toml (Root)
[install]
linker = "isolated"
globalStore = true
exact = false
// package.json
{
"name": "monorepo-root",
"private": true,
"workspaces": ["apps/*", "packages/*"],
"trustedDependencies": [
"esbuild",
"sharp",
"@prisma/client"
]
}
// CI-Installationsschritt (GitHub Actions) — gesperrt und offline-kompatibel
- name: Install dependencies
run: bun install --frozen-lockfile --prefer-offline
// Blockierte Postinstall-Skripte anzeigen
bun pm untrusted
// Ein Paket als vertrauenswürdig markieren
bun pm trust sharp
// Installation für bestimmte Workspace-Pakete
bun install --filter "./apps/web"
// Komplett offline installieren (kein Netzwerkzugriff)
bun install --offlineEs gibt keinen eindeutigen Sieger; beide Tools optimieren auf unterschiedliche Prioritäten. Wenn du runtime-unabhängig bleiben und die Richtlinie bei jedem lockfile-ändernden Befehl durchsetzen willst, wähle pnpm. Wenn du Bun bereits als Runtime einsetzt und der Disk-/Geschwindigkeitsgewinn des globalen Virtual Store entscheidend ist, ist bun install attraktiv. Beide blockieren postinstall standardmäßig; der Unterschied liegt darin, wo die Kontrollpunkte sitzen. Mische beide nicht im selben Repo — eine Lockfile, eine Quelle der Wahrheit.
Kostenlose Beratung erhaltenDas hängt vom Szenario ab. Die von Bun veröffentlichten Messungen vergleichen die eigenen Linker miteinander: Bei einem 1.400-Pakete-Fixture (React/webpack/Babel/jest) liegt die Warm-Installation beim hoisted Linker bei 823,9 ms, beim isolated Linker + globalem Store bei 124,8 ms (Apple Silicon macOS, hyperfine). Auch pnpms content-addressable Store setzt bei Warm-Installationen auf das Lesen von der Festplatte, sodass beide unter den richtigen Bedingungen schnell sind. Den Unterschied zwischen beiden Tools solltest du an deiner eigenen Repo-Größe und CI-Cache-Strategie messen — übertrage kein einzelnes Fixture-Ergebnis auf dein Monorepo.