I had a side project last winter that was killing me with cold starts. Tiny Node service, deployed to a small VPS, ran in a Docker container, and every restart took about 3.8 seconds before it was answering requests. That’s nothing on a real server, but it was annoying for an internal tool I bounce in and out of all day. So one Friday I spent an evening porting it to Bun. The cold start dropped to 0.4 seconds.<\/p>\n
I’d been hearing the Bun hype for two years and ignoring it. Now I had to take it seriously.<\/p>\n
This post is where I’ve landed after about six months of mixing Bun and Node in real work. Short version: Bun has earned a spot in my toolbox, but it hasn’t replaced Node for the things I most care about being boring.<\/p>\n
Three places, all of them about speed of feedback rather than raw runtime throughput.<\/p>\n
The first is package install. The second is running TypeScript directly. Bun handles Node has been catching up here with The third is bundled testing. For tiny libraries this is wonderful. No jest config, no ts-jest, no A few honest reasons.<\/p>\n Compatibility. The npm ecosystem assumes Node. Most of the time Bun’s compatibility layer is good enough that you won’t notice. Some of the time it isn’t. I hit a real one with a Postgres driver that used a Node-specific socket option, and another with a Sentry middleware that depended on Operational maturity. Node has fifteen years of war stories. Heap snapshots, V8 flame graphs, every PaaS supports it, AWS Lambda has a maintained runtime, Datadog has a tracer that just works, k8s autoscaling samples are all written for Node. Bun has growing support, but you’ll occasionally find yourself opening GitHub issues that nobody has ever opened before. That’s fun on a side project. It’s not fun for the on-call rotation.<\/p>\n Long-term API stability. Node moves slowly on purpose. Bun moves fast and breaks small things between point releases. I’ve had dependencies stop working after a If you read those reasons and felt yourself nodding, you understand why I describe the split as: Bun for my dev loop, Node for the stuff that pays me.<\/p>\n I want to like Deno. The security model is genuinely the right design. Permissions per script ( The blocker for me has been npm interop friction. Deno added npm support in 1.28 and refined it across the 2.x line, but installing certain packages still produces strange errors with peer deps that resolve fine in Node and Bun. Last month I tried to port a small Hono app to Deno and stopped after the third “specifier not found” warning that I couldn’t quickly explain.<\/p>\n Deno 2.x has narrowed the gap a lot, and if I were starting a brand new app with no legacy npm deps, I’d seriously consider it. For now it’s the runtime I keep almost using and not quite picking. If you’re curious, the Deno 2 announcement post<\/a> is worth a read for the npm and Node compatibility story.<\/p>\n Caveat: a tiny benchmark from one app. Take it as a flavor, not a verdict.<\/p>\n I ran a small Hono server doing two things: serving a static JSON config, and doing a Postgres query through a connection pool. Both runtimes used the same Hono version and the same Two reactions. First, on the IO-bound route the gap nearly vanishes, because both runtimes are waiting on Postgres. Most real apps live in that second case. Second, the synthetic JSON test is real but rarely the bottleneck for anything I ship. Don’t migrate a service for these numbers alone.<\/p>\n My current split, today:<\/p>\n If you want a deeper dive on the Next.js side of this, I wrote about how I chose between the App Router and Pages Router<\/a> earlier this year. Bun vs Node is a smaller decision than that one.<\/p>\n Six months ago I’d have called Bun a curiosity. Today, my dotfiles install Bun on every new machine, and I reach for it any time I’m starting fresh. What hasn’t changed is that I still write production services in Node, and I’d encourage anyone running a small business on top of a Node app to do the same for now.<\/p>\n The Bun team has shipped a lot. Their v1.2 announcement<\/a> is a good read if you want a sense of the pace. The Node.js 22 release notes<\/a> are quieter, which I think reflects the right priorities for that project.<\/p>\nbun install<\/code> finishes in seconds for projects where npm install<\/code> makes me get coffee. On a fresh clone of a mid-size Next.js app I have, npm took 47 seconds, pnpm took 12, and bun took 4. The numbers are not the headline. The headline is that the wait is short enough that I stop context-switching, which means I keep working.<\/p>\nbun run src\/index.ts<\/code> with no extra config, no tsx<\/code>, no ts-node<\/code>, no transpile step. Here’s the before-and-after for a one-off script:<\/p>\n# The old Node way\nnpm i -D tsx typescript @types\/node\nnpx tsx .\/script.ts\n\n# Bun\nbun .\/script.ts\n<\/code><\/pre>\n--experimental-strip-types<\/code>, but Bun made this a non-event years earlier and the experience is still smoother for the small stuff.<\/p>\nbun test<\/code> gives you a Jest-flavored runner without installing Jest:<\/p>\n\/\/ math.test.ts\nimport { expect, test } from "bun:test";\n\ntest("adds", () => {\n expect(2 + 2).toBe(4);\n});\n<\/code><\/pre>\nbun test\n# bun test v1.2.x\n# math.test.ts:\n# (pass) adds [0.32ms]\n<\/code><\/pre>\n@types\/jest<\/code>.<\/p>\nWhere Node still wins, and why I keep it on the production server<\/h2>\n
process.binding<\/code>. Both got fixed eventually. Both wasted an afternoon. On a production service for a paying client I don’t want to debug “is this a Bun bug or my bug?” at 11pm.<\/p>\nbun upgrade<\/code> that should have been a no-op. For something I want to redeploy in two years without touching, Node is the safer bet.<\/p>\nDeno is the one I keep almost using<\/h2>\n
--allow-net<\/code>, --allow-read=\/etc<\/code>) is what every runtime should do.<\/p>\nA small, honest benchmark<\/h2>\n
pg<\/code> driver. The host was a 2-vCPU Hetzner instance, hot pool, 30-second wrk run.<\/p>\n# Static JSON route, 200 connections, 30s\nNode 22.11: 41,200 req\/s, p99 11ms\nBun 1.2.4: 58,900 req\/s, p99 8ms\n\n# Postgres query route, 50 connections, 30s\nNode 22.11: 6,800 req\/s, p99 38ms\nBun 1.2.4: 7,300 req\/s, p99 35ms\n<\/code><\/pre>\nWhat I run for what<\/h2>\n
\n
bun install<\/code>, then next dev<\/code> itself runs on Node because that’s what Next.js officially supports. Mixing them doesn’t break anything in practice.<\/li>\nWhat’s actually changed for me<\/h2>\n