Bun shipped 1.0 last week. We've been watching it for a year, partly out of curiosity and partly because the JavaScript runtime story has been weirdly static since Node's early days. Bun is interesting. It is not yet our production answer.

## What's good

- 01 Speed. Cold starts and dev server boots are dramatically faster than Node.
- 02 Built-in TypeScript without a separate tool.
- 03 A bundler, test runner, package manager and runtime in one binary.
- 04 Native fetch, native WebSocket, sensible defaults across the surface.

## Bun vs Node, side by side

| Capability | Node.js | Bun |
| --- | --- | --- |
| Runtime engine | V8 | JavaScriptCore |
| TypeScript | Via tsx / ts-node | Built in |
| Bundler | External (esbuild, Vite, Webpack) | Built in |
| Test runner | External (Vitest, Jest) | Built in |
| Package manager | npm / pnpm / yarn | bun install (much faster) |
| Native fetch / WebSocket | Native (recent versions) | Native |
| Maturity | Battle-tested since 2009 | New, less proven |

Node.js vs Bun, feature parity in late 2023.

## What we're cautious about

- 01 Compatibility edges with the long tail of npm packages. Most things work; some don't.
- 02 Production deployment story is less battle-tested than Node's.
- 03 When 'fast' becomes 'fast in this specific benchmark', it's worth checking against your actual workload.

> "
> Twelve months from now, Bun is either a quiet daily tool we've forgotten was ever new, or a footnote. We think it's the first.

## Where we are using it

- 01 Local scripts and ad-hoc tooling — Bun's start time is genuinely a quality-of-life win.
- 02 Test suites where the dev loop matters more than the production runtime.
- 03 Internal CLIs that don't ship to clients.

Twelve months from now, Bun is either a quiet daily tool we've forgotten was ever new, or a footnote. We think it's the first. We're keeping our production stack on Node until we've watched another year.