3 ms·

We replaced Node.js with Bun for 5x throughput

59 points by pier25 7mo ago

ksec 7mo ago
>Next: the runtime itself. Bun has a bun build --compile flag that produces a single self-contained executable. No runtime, no node_modules, no source files needed in the container. I didn't know that. So Bun is basically a whole runtime + framework all in one with little to no deployment headaches?
- jamsinclair 7mo ago
  The bun build creates a large self-contained executable with no optimisations. Almost like a large electron build. Deno also provides the same functionality, but with a smaller optimized binary. Appreciate Bun helping creating healthy competition. I feel like Deno falls under most people's radar often. More security options, faster than Node, built on web standards.
  - matorl 7mo ago
    Deno's security options are very useful for AI sandboxes. Broader than node's permissions. Bun badly needs the same. There's a PR for Bun that gives the same security but it's been sitting for months https://github.com/oven-sh/bun/pull/25911 https://github.com/oven-sh/bun/pull/25911 I want to migrate an existing project to Bun but cannot until it has a security permission system in place.
  - dsissitka 7mo ago
    I was curious: $ cat app.ts console.log("Hello, world!"); $ cat build #!/usr/bin/env bash bun build --compile --outfile bun-darwin-arm64 --target bun-darwin-arm64 app.ts bun build --compile --outfile bun-darwin-x64 --target bun-darwin-x64 app.ts bun build --compile --outfile bun-darwin-x64-baseline --target bun-darwin-x64-baseline app.ts bun build --compile --outfile bun-linux-arm64 --target bun-linux-arm64 app.ts bun build --compile --outfile bun-linux-arm64-musl --target bun-linux-arm64-musl app.ts bun build --compile --outfile bun-linux-x64 --target bun-linux-x64 app.ts bun build --compile --outfile bun-linux-x64-baseline --target bun-linux-x64-baseline app.ts bun build --compile --outfile bun-linux-x64-modern --target bun-linux-x64-modern app.ts bun build --compile --outfile bun-linux-x64-musl --target bun-linux-x64-musl app.ts bun build --compile --outfile bun-windows-arm64 --target bun-windows-arm64 app.ts bun build --compile --outfile bun-windows-x64 --target bun-windows-x64 app.ts bun build --compile --outfile bun-windows-x64-baseline --target bun-windows-x64-baseline app.ts bun build --compile --outfile bun-windows-x64-modern --target bun-windows-x64-modern app.ts deno compile --output deno-x86_64-pc-windows-msvc --target x86_64-pc-windows-msvc app.ts deno compile --output deno-x86_64-apple-darwin --target x86_64-apple-darwin app.ts deno compile --output deno-aarch64-apple-darwin --target aarch64-apple-darwin app.ts deno compile --output deno-x86_64-unknown-linux-gnu --target x86_64-unknown-linux-gnu app.ts deno compile --output deno-aarch64-unknown-linux-gnu --target aarch64-unknown-linux-gnu app.ts $ ls -1hs total 1.6G 4.0K app.ts 4.0K build 59M bun-darwin-arm64 64M bun-darwin-x64 64M bun-darwin-x64-baseline 95M bun-linux-arm64 89M bun-linux-arm64-musl 95M bun-linux-x64 94M bun-linux-x64-baseline 95M bun-linux-x64-modern 90M bun-linux-x64-musl 107M bun-windows-arm64.exe 110M bun-windows-x64-baseline.exe 111M bun-windows-x64.exe 111M bun-windows-x64-modern.exe 77M deno-aarch64-apple-darwin 87M deno-aarch64-unknown-linux-gnu 84M deno-x86_64-apple-darwin 92M deno-x86_64-pc-windows-msvc.exe 93M deno-x86_64-unknown-linux-gnu $ Maybe I'm missing some flags? Bun's docs say --compile implies --production. I don't see anything in Deno's docs.
    - burnt-resistor 7mo ago
      Where? bun's doc site search engine doesn't show it but there's an open PR on the topic. https://github.com/oven-sh/bun/issues/26373 https://github.com/oven-sh/bun/issues/26373 Doc site says: --production sets flag --minify, process.env.NODE_ENV = production, and production-mode JSX import & transform Might try: bun build --compile --production --bytecode --outfile myapp app.ts
      - dsissitka 7mo ago
        D'oh, it wasn't the doc site. I was lazy: $ bun build --help | grep Implies --compile Generate a standalone Bun executable containing your bundled code. Implies --production $ I actually did double check it though because it used to be wrong. For good measure: $ grep bun build bun build --bytecode --compile --outfile bun-darwin-arm64 --production --target bun-darwin-arm64 app.ts bun build --bytecode --compile --outfile bun-darwin-x64 --production --target bun-darwin-x64 app.ts bun build --bytecode --compile --outfile bun-darwin-x64-baseline --production --target bun-darwin-x64-baseline app.ts bun build --bytecode --compile --outfile bun-linux-arm64 --production --target bun-linux-arm64 app.ts bun build --bytecode --compile --outfile bun-linux-arm64-musl --production --target bun-linux-arm64-musl app.ts bun build --bytecode --compile --outfile bun-linux-x64 --production --target bun-linux-x64 app.ts bun build --bytecode --compile --outfile bun-linux-x64-baseline --production --target bun-linux-x64-baseline app.ts bun build --bytecode --compile --outfile bun-linux-x64-modern --production --target bun-linux-x64-modern app.ts bun build --bytecode --compile --outfile bun-linux-x64-musl --production --target bun-linux-x64-musl app.ts bun build --bytecode --compile --outfile bun-windows-arm64 --production --target bun-windows-arm64 app.ts bun build --bytecode --compile --outfile bun-windows-x64 --production --target bun-windows-x64 app.ts bun build --bytecode --compile --outfile bun-windows-x64-baseline --production --target bun-windows-x64-baseline app.ts bun build --bytecode --compile --outfile bun-windows-x64-modern --production --target bun-windows-x64-modern app.ts $ ls -1hs bun* 59M bun-darwin-arm64 64M bun-darwin-x64 64M bun-darwin-x64-baseline 95M bun-linux-arm64 89M bun-linux-arm64-musl 95M bun-linux-x64 94M bun-linux-x64-baseline 95M bun-linux-x64-modern 90M bun-linux-x64-musl 107M bun-windows-arm64.exe 110M bun-windows-x64-baseline.exe 111M bun-windows-x64.exe 111M bun-windows-x64-modern.exe $
  - pjmlp 7mo ago
    Ideally we would still only use JavaScript on the browser, personally I don't care about about the healthy competition, rather that npm actually works when I am stuck writing server side code I didn't ask for.
    - burnt-resistor 7mo ago
      FE-BE standardization is efficient in terms of labor and code migration portability, but I really like the idea of static compilation and optimization of the BE in production.. there's absolutely no need or reason for the BE to do dynamic anything in prod. As long as it retains profiling inspectability when things go wrong.
      - senorrib 7mo ago
        That doesn’t align with my experience. It feels more like a trojan horse. Client and Server rarely (should) share code, and people that are really good at one discipline aren’t that good at the other. Maybe LLMs will change that.
        burnt-resistor 7mo ago
        That's a negative FUD way to judge it. C. 2015 one of my friends was a Django dev but moved to Express/node because that's where the cool kids went, it was one less language, and allowed them to move logic FE->BE and BE->FE much easier. Also, a bunch of Rails people left to Node/FE JS and Rust (BE). JS/TS is still an irreducible requirement for FE. There is no law that either grand unified frameworks must be used nor entirely separate FE and BE must be maintained separately and are somehow mysterious, arcane arts. Not sharing code when/where it is possible and appropriate is duplicating effort.. like client- and server-side input validations doing exactly the same thing.
        aaztehcy 7mo ago
        [flagged]
      - 7mo ago
- thewarman 7mo ago
  This (single executable) is available in node.js now too as SEA mode.
  - claytongulick 7mo ago
    But I think it still doesn't work with ESM, only CommonJS, so while not insurmountable, not as good as bun.
    - williamstein 7mo ago
      SEA with node.js "works" for nearly arbitrarily general node code -- pretty much anything you can run with node. However you may have to put in substantial extra effort, e.g., using [1], and possibly more work (e.g., copying assets out or using a virtual file system). [1] https://www.npmjs.com/package/@vercel/ncc https://www.npmjs.com/package/@vercel/ncc
denys_potapov 7mo ago
tl;dr replace SQLite with Map ~ 2x speed up, replace zod validation with ifs ~ 2x speed up. Bun had a memory leak on unresolved promises - now fixed
LeonTing1010 7mo ago
[flagged]
dcre 7mo ago
I was curious why bun build --compile would be faster. The docs say: “Compiled executables reduce memory usage and improve Bun’s start time. Normally, Bun reads and transpiles JavaScript and TypeScript files on import and require. This is part of what makes so much of Bun “just work”, but it’s not free. It costs time and memory to read files from disk, resolve file paths, parse, transpile, and print source code. With compiled executables, you can move that cost from runtime to build-time.” https://bun.com/docs/bundler/executables#deploying-to-production https://bun.com/docs/bundler/executables#deploying-to-produc...
abustamam 7mo ago
I use bun for everything except for monorepos with isolated deployment targets and shared packages. I use yarn or pnpm for monorepos. Maybe it's changed in the last six months but I could never get docker to properly resolve my dependencies when I only want to build the web app, for example, since the bun lock is deterministic based off of all the packages in the repo so isolating a single leaf makes it error. Maybe I'm doing something wrong but I scoured docs and online and asked multiple AI agents to no avail.
mememememememo 7mo ago
How much would you get by moving to Go, Rust or C++?
- jimbob45 7mo ago
  I wish you were getting replies instead of downvotes. I want to know why people think Bun is preferable here. For cross-platform non-performance-important code, I’ll use Bun all day. Once speed enters the equation, I don’t see why you’d still be using it.
- pjmlp 7mo ago
  A lot, but apparently we cannot get rid of having server side JavaScript code.
azinman2 7mo ago
So is Bun saying that JSC is much better than v8?
- carefree-bob 7mo ago
  It's more that Zig is faster than JS. The speed advantages of Bun come from all the Zig bindings, not the JS interpreter.
  - pjmlp 7mo ago
    C and C++ as well, and nodejs has bindings.
mdavid626 7mo ago
It's not about Bun, but more about sqlite and zod replacements. Why interpret this as "Bun is faster"?
- nikanj 7mo ago
  Gets more reactions that way
fleebee 7mo ago
I'm puzzled by the title of this post. From what I can gather most, if not all, of the performance improvements came from sacking SQLite and Zod. They applied optimizations that cut CPU time by ~40% to the Bun version before comparing it with Node. Claiming 5x throughput from "replacing Node.js with Bun" is a wild misrepresentation of the findings.
- LaSombra 7mo ago
  Don’t let facts get in the way of a catchy headline
  - mannycalavera42 7mo ago
    :love
- whizzter 7mo ago
  And they include "phase 3 opts" in the phase2 benchmark, so the move to Bun also includes improvements from removing "safeParse". So Node might've been at more than 40% of the performance. It's sad since these kinds of numbers are interesting, but when there's blatant misrepresentations it just create a stink.
nlehuen 7mo ago
The SQL query they replaced was extremely cringe and amateurish ("let's sprinkle DISTINCT until all those pesky redundant rows that come from our inefficient KV metadata schema go away"). The fact they did not acknowledge that and somehow blame it on SQlite made me stop reading on the spot, and be very worried for whoever depends on their products.
mordae 7mo ago
I cringed at those "aaa\0bbb\0ccc\0ddd" Map keys. That's much slower than nested maps and requires allocating the strings, giving GC more work to do.
- WASDx 7mo ago
  Creating a custom tuple class to use as key could be faster though. Nested map lookups have less efficient memory access patterns.
aoeusnth1 7mo ago
Why is a map lookup measured in ms instead of us? Something is seriously wrong with these benchmarks.

59 points by pier25 7mo ago

ksec 7mo ago

>Next: the runtime itself. Bun has a bun build --compile flag that produces a single self-contained executable. No runtime, no node_modules, no source files needed in the container. I didn't know that. So Bun is basically a whole runtime + framework all in one with little to no deployment headaches?

jamsinclair 7mo ago
The bun build creates a large self-contained executable with no optimisations. Almost like a large electron build. Deno also provides the same functionality, but with a smaller optimized binary. Appreciate Bun helping creating healthy competition. I feel like Deno falls under most people's radar often. More security options, faster than Node, built on web standards.
- matorl 7mo ago
  Deno's security options are very useful for AI sandboxes. Broader than node's permissions. Bun badly needs the same. There's a PR for Bun that gives the same security but it's been sitting for months https://github.com/oven-sh/bun/pull/25911 https://github.com/oven-sh/bun/pull/25911 I want to migrate an existing project to Bun but cannot until it has a security permission system in place.
- dsissitka 7mo ago
  I was curious: $ cat app.ts console.log("Hello, world!"); $ cat build #!/usr/bin/env bash bun build --compile --outfile bun-darwin-arm64 --target bun-darwin-arm64 app.ts bun build --compile --outfile bun-darwin-x64 --target bun-darwin-x64 app.ts bun build --compile --outfile bun-darwin-x64-baseline --target bun-darwin-x64-baseline app.ts bun build --compile --outfile bun-linux-arm64 --target bun-linux-arm64 app.ts bun build --compile --outfile bun-linux-arm64-musl --target bun-linux-arm64-musl app.ts bun build --compile --outfile bun-linux-x64 --target bun-linux-x64 app.ts bun build --compile --outfile bun-linux-x64-baseline --target bun-linux-x64-baseline app.ts bun build --compile --outfile bun-linux-x64-modern --target bun-linux-x64-modern app.ts bun build --compile --outfile bun-linux-x64-musl --target bun-linux-x64-musl app.ts bun build --compile --outfile bun-windows-arm64 --target bun-windows-arm64 app.ts bun build --compile --outfile bun-windows-x64 --target bun-windows-x64 app.ts bun build --compile --outfile bun-windows-x64-baseline --target bun-windows-x64-baseline app.ts bun build --compile --outfile bun-windows-x64-modern --target bun-windows-x64-modern app.ts deno compile --output deno-x86_64-pc-windows-msvc --target x86_64-pc-windows-msvc app.ts deno compile --output deno-x86_64-apple-darwin --target x86_64-apple-darwin app.ts deno compile --output deno-aarch64-apple-darwin --target aarch64-apple-darwin app.ts deno compile --output deno-x86_64-unknown-linux-gnu --target x86_64-unknown-linux-gnu app.ts deno compile --output deno-aarch64-unknown-linux-gnu --target aarch64-unknown-linux-gnu app.ts $ ls -1hs total 1.6G 4.0K app.ts 4.0K build 59M bun-darwin-arm64 64M bun-darwin-x64 64M bun-darwin-x64-baseline 95M bun-linux-arm64 89M bun-linux-arm64-musl 95M bun-linux-x64 94M bun-linux-x64-baseline 95M bun-linux-x64-modern 90M bun-linux-x64-musl 107M bun-windows-arm64.exe 110M bun-windows-x64-baseline.exe 111M bun-windows-x64.exe 111M bun-windows-x64-modern.exe 77M deno-aarch64-apple-darwin 87M deno-aarch64-unknown-linux-gnu 84M deno-x86_64-apple-darwin 92M deno-x86_64-pc-windows-msvc.exe 93M deno-x86_64-unknown-linux-gnu $ Maybe I'm missing some flags? Bun's docs say --compile implies --production. I don't see anything in Deno's docs.
  - burnt-resistor 7mo ago
    Where? bun's doc site search engine doesn't show it but there's an open PR on the topic. https://github.com/oven-sh/bun/issues/26373 https://github.com/oven-sh/bun/issues/26373 Doc site says: --production sets flag --minify, process.env.NODE_ENV = production, and production-mode JSX import & transform Might try: bun build --compile --production --bytecode --outfile myapp app.ts
    - dsissitka 7mo ago
      D'oh, it wasn't the doc site. I was lazy: $ bun build --help | grep Implies --compile Generate a standalone Bun executable containing your bundled code. Implies --production $ I actually did double check it though because it used to be wrong. For good measure: $ grep bun build bun build --bytecode --compile --outfile bun-darwin-arm64 --production --target bun-darwin-arm64 app.ts bun build --bytecode --compile --outfile bun-darwin-x64 --production --target bun-darwin-x64 app.ts bun build --bytecode --compile --outfile bun-darwin-x64-baseline --production --target bun-darwin-x64-baseline app.ts bun build --bytecode --compile --outfile bun-linux-arm64 --production --target bun-linux-arm64 app.ts bun build --bytecode --compile --outfile bun-linux-arm64-musl --production --target bun-linux-arm64-musl app.ts bun build --bytecode --compile --outfile bun-linux-x64 --production --target bun-linux-x64 app.ts bun build --bytecode --compile --outfile bun-linux-x64-baseline --production --target bun-linux-x64-baseline app.ts bun build --bytecode --compile --outfile bun-linux-x64-modern --production --target bun-linux-x64-modern app.ts bun build --bytecode --compile --outfile bun-linux-x64-musl --production --target bun-linux-x64-musl app.ts bun build --bytecode --compile --outfile bun-windows-arm64 --production --target bun-windows-arm64 app.ts bun build --bytecode --compile --outfile bun-windows-x64 --production --target bun-windows-x64 app.ts bun build --bytecode --compile --outfile bun-windows-x64-baseline --production --target bun-windows-x64-baseline app.ts bun build --bytecode --compile --outfile bun-windows-x64-modern --production --target bun-windows-x64-modern app.ts $ ls -1hs bun* 59M bun-darwin-arm64 64M bun-darwin-x64 64M bun-darwin-x64-baseline 95M bun-linux-arm64 89M bun-linux-arm64-musl 95M bun-linux-x64 94M bun-linux-x64-baseline 95M bun-linux-x64-modern 90M bun-linux-x64-musl 107M bun-windows-arm64.exe 110M bun-windows-x64-baseline.exe 111M bun-windows-x64.exe 111M bun-windows-x64-modern.exe $
- pjmlp 7mo ago
  Ideally we would still only use JavaScript on the browser, personally I don't care about about the healthy competition, rather that npm actually works when I am stuck writing server side code I didn't ask for.
  - burnt-resistor 7mo ago
    FE-BE standardization is efficient in terms of labor and code migration portability, but I really like the idea of static compilation and optimization of the BE in production.. there's absolutely no need or reason for the BE to do dynamic anything in prod. As long as it retains profiling inspectability when things go wrong.
    - senorrib 7mo ago
      That doesn’t align with my experience. It feels more like a trojan horse. Client and Server rarely (should) share code, and people that are really good at one discipline aren’t that good at the other. Maybe LLMs will change that.
      - burnt-resistor 7mo ago
        That's a negative FUD way to judge it. C. 2015 one of my friends was a Django dev but moved to Express/node because that's where the cool kids went, it was one less language, and allowed them to move logic FE->BE and BE->FE much easier. Also, a bunch of Rails people left to Node/FE JS and Rust (BE). JS/TS is still an irreducible requirement for FE. There is no law that either grand unified frameworks must be used nor entirely separate FE and BE must be maintained separately and are somehow mysterious, arcane arts. Not sharing code when/where it is possible and appropriate is duplicating effort.. like client- and server-side input validations doing exactly the same thing.
        aaztehcy 7mo ago
        [flagged]
    - 7mo ago
thewarman 7mo ago
This (single executable) is available in node.js now too as SEA mode.
- claytongulick 7mo ago
  But I think it still doesn't work with ESM, only CommonJS, so while not insurmountable, not as good as bun.
  - williamstein 7mo ago
    SEA with node.js "works" for nearly arbitrarily general node code -- pretty much anything you can run with node. However you may have to put in substantial extra effort, e.g., using [1], and possibly more work (e.g., copying assets out or using a virtual file system). [1] https://www.npmjs.com/package/@vercel/ncc https://www.npmjs.com/package/@vercel/ncc

denys_potapov 7mo ago

tl;dr replace SQLite with Map ~ 2x speed up, replace zod validation with ifs ~ 2x speed up. Bun had a memory leak on unresolved promises - now fixed

LeonTing1010 7mo ago

[flagged]

dcre 7mo ago

I was curious why bun build --compile would be faster. The docs say: “Compiled executables reduce memory usage and improve Bun’s start time. Normally, Bun reads and transpiles JavaScript and TypeScript files on import and require. This is part of what makes so much of Bun “just work”, but it’s not free. It costs time and memory to read files from disk, resolve file paths, parse, transpile, and print source code. With compiled executables, you can move that cost from runtime to build-time.” https://bun.com/docs/bundler/executables#deploying-to-production https://bun.com/docs/bundler/executables#deploying-to-produc...

abustamam 7mo ago

I use bun for everything except for monorepos with isolated deployment targets and shared packages. I use yarn or pnpm for monorepos. Maybe it's changed in the last six months but I could never get docker to properly resolve my dependencies when I only want to build the web app, for example, since the bun lock is deterministic based off of all the packages in the repo so isolating a single leaf makes it error. Maybe I'm doing something wrong but I scoured docs and online and asked multiple AI agents to no avail.

mememememememo 7mo ago

How much would you get by moving to Go, Rust or C++?

jimbob45 7mo ago
I wish you were getting replies instead of downvotes. I want to know why people think Bun is preferable here. For cross-platform non-performance-important code, I’ll use Bun all day. Once speed enters the equation, I don’t see why you’d still be using it.
pjmlp 7mo ago
A lot, but apparently we cannot get rid of having server side JavaScript code.

azinman2 7mo ago

So is Bun saying that JSC is much better than v8?

carefree-bob 7mo ago
It's more that Zig is faster than JS. The speed advantages of Bun come from all the Zig bindings, not the JS interpreter.
- pjmlp 7mo ago
  C and C++ as well, and nodejs has bindings.

mdavid626 7mo ago

It's not about Bun, but more about sqlite and zod replacements. Why interpret this as "Bun is faster"?

nikanj 7mo ago
Gets more reactions that way

fleebee 7mo ago

I'm puzzled by the title of this post. From what I can gather most, if not all, of the performance improvements came from sacking SQLite and Zod. They applied optimizations that cut CPU time by ~40% to the Bun version before comparing it with Node. Claiming 5x throughput from "replacing Node.js with Bun" is a wild misrepresentation of the findings.

LaSombra 7mo ago
Don’t let facts get in the way of a catchy headline
- mannycalavera42 7mo ago
  :love
whizzter 7mo ago
And they include "phase 3 opts" in the phase2 benchmark, so the move to Bun also includes improvements from removing "safeParse". So Node might've been at more than 40% of the performance. It's sad since these kinds of numbers are interesting, but when there's blatant misrepresentations it just create a stink.

nlehuen 7mo ago

The SQL query they replaced was extremely cringe and amateurish ("let's sprinkle DISTINCT until all those pesky redundant rows that come from our inefficient KV metadata schema go away"). The fact they did not acknowledge that and somehow blame it on SQlite made me stop reading on the spot, and be very worried for whoever depends on their products.

mordae 7mo ago

I cringed at those "aaa\0bbb\0ccc\0ddd" Map keys. That's much slower than nested maps and requires allocating the strings, giving GC more work to do.

WASDx 7mo ago
Creating a custom tuple class to use as key could be faster though. Nested map lookups have less efficient memory access patterns.

aoeusnth1 7mo ago

Why is a map lookup measured in ms instead of us? Something is seriously wrong with these benchmarks.