| ▲ | ksec 12 hours 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 12 hours ago | parent | next [-] |
| 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 10 hours ago | parent | next [-] | | 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. | |
| ▲ | dsissitka 10 hours ago | parent | prev | next [-] | | 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 8 hours ago | parent [-] | | 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 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 8 hours ago | parent [-] | | 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 10 hours ago | parent | prev [-] | | 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 8 hours ago | parent [-] | | 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 7 hours ago | parent | next [-] | | 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. | |
| ▲ | pjmlp 7 hours ago | parent | prev [-] | | Except we have moved beyond that with SaaS products,agents, AI workflows. The only reason I touch JavaScript on the backend instead of .NET, Java, Go, Rust, OCaml, Haskell,.... are SDKs and customers that don't let other option than JavaScript all over the place. Thus my point of view is that I couldn't care less about competition between JavaScript runtimes. |
|
|
|
|
| ▲ | thewarman 11 hours ago | parent | prev [-] |
| This (single executable) is available in node.js now too as SEA mode. |
| |
| ▲ | claytongulick 11 hours ago | parent [-] | | But I think it still doesn't work with ESM, only CommonJS, so while not insurmountable, not as good as bun. | | |
| ▲ | williamstein 11 hours ago | parent [-] | | 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 |
|
|