Verdict
Bun started 1.7× faster, ran a TypeScript file 3× faster and finished the same test suite 5× faster. Node won the tight number-crunching loop. The HTTP test hit a limit of this machine, not of either runtime.
Tested on
- Node
- 24.14.0
- Bun
- 1.4.2
- Machine
- i3-1115G4, 2 cores, 12 GB, NVMe SSD
- OS
- Windows 11 Pro 26200
Contents
Same machine, same files, and wherever possible the exact same code on both runtimes. Every number below is a median of repeated runs, and both runtimes had to produce the identical result (checksum 864579) for the CPU test to count.
The results
- Bun34.5 msbest
- Node58.7 ms
- Bun36.8 msbest
- Node114.0 ms
- Bun76 msbest
- Node381 ms
- Bun578 msbest
- Node1372 ms
- Bun245 msbest
- Node331 ms
- Node113 msbest
- Bun125 ms
What that means in practice
- Scripts, CLIs and dev tooling feel faster on Bun. It starts about 1.7× faster. For anything you run many times a day (scripts, git hooks, one-off tools), that adds up.
- Running TypeScript without a build: both can now do it, but Bun was about 3× faster here (37 ms vs 114 ms). Node 24 strips types natively, which is convenient, but it doesn’t match Bun’s startup.
- Tests:
bun testran the same 300node:testtests about 5× faster thannode --test, partly becausenode --testruns each test file in its own child process, so even this single file paid for a second Node startup. - Raw computation is closer than the headlines suggest. Bun sorted about 2.4× faster and did JSON about 1.35× faster, but Node won the tight loop (the prime sieve) by about 10%. If your app is mostly number-crunching, don’t switch for speed alone.
- Node is still the safe default for compatibility: every npm package and tool is built for it first. Bun is worth it where its speed shows up directly: scripts, tests and TypeScript tooling.
The HTTP test didn’t count, and why
I also load-tested an identical node:http server on both runtimes, plus Bun’s own Bun.serve. All three landed at about 600–700 requests per second, suspiciously equal and far too low for a “hello world” server.
To compare HTTP throughput, run it on Linux or on separate client and server machines.
How this was measured
- Same code on both runtimes: the CPU test, the TypeScript file and the 300 tests were byte-for-byte identical. The test file uses
node:testandnode:assert, which Bun supports. - Repeated runs, median reported: startup 30 runs, TypeScript 20, CPU 5 (timed inside the process), tests 7.
- Startup and TypeScript timings include creating the process, measured from Node’s
spawnSync. That’s the time you actually wait when you run a command. - The CPU tasks had to agree: both runtimes produced the same checksum, so neither was skipping work.
Limits of this test
- One Windows laptop with 2 cores. Results on Linux, macOS or a big server can differ, especially for the test runner and HTTP.
- Micro-benchmarks, not your app. Real apps spend time on I/O, databases and dependencies. Measure your own workload before switching.
- Bun’s compatibility wasn’t tested here, only speed. Some Node packages and APIs still behave differently on Bun.
— N.K., end of entry No.012