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 9 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.