I didn't know that. So Bun is basically a whole runtime + framework all in one with little to no deployment headaches?
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.
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.
$ 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
$
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 $ bun build --help | grep Implies
--compile Generate a standalone Bun executable containing your bundled code. Implies --production
$
$ 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
$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.
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.