pier25We replaced Node.js with Bun for 5x throughput
>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?
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.
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
I want to migrate an existing project to Bun but cannot until it has a security permission system in place.
Secure Mode: Deno & Node.js compatible permissions for Bun, but better by kynnyhsap · Pull Request #25911 · oven-sh/bun
Summary Implements a Deno-compatible permissions model for Bun, providing granular control over system resource access. This PR introduces a security sandbox that can restrict file system, network,...
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.
But I think it still doesn't work with ESM, only CommonJS, so while not insurmountable, not as good as bun.
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).
@vercel/ncc
Simple CLI for compiling a Node.js module into a single file, together with all its dependencies, gcc-style.. Latest version: 0.38.4, last published: 7 months ago. Start using @vercel/ncc in your project by running `npm i @vercel/ncc`. There are 154 other projects in the npm registry using @vercel/ncc.
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-produc...
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.
It's not about Bun, but more about sqlite and zod replacements. Why interpret this as "Bun is faster"?
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.