Deno's goal was to address Node's design weaknesses, while Bun came out with the promise of faster performance. Especially if you're coming from Node or migrating an existing project, it's easier to justify switching to Bun than to Deno.

Since then, all three runtimes have been gradually converging (adopting Web APIs, first class TypeScript support), so there's little reason to move away from Node's vast ecosystem to Deno; most npm packages weren't made with Deno's security model in mind.

Deno's biggest strength is when you want its security model and don't plan on using npm packages, e.g. if you want to let agents write and run quick scripts on your machine without awaiting your permission.

Mainly DX.

Deno has many of those things now, but my past experience wasn’t good. The first versions of Deno had a lot of friction; Bun however was more or less useful from day 1.

Bun simplified the pain with the ecosystem switch to esm. deno, at the time, made it worse by doing stuff with url based packages that didn’t fully catch on

Deno originally was not Node compatible at all, and required you to do everything in a Deno way:

- Deno plugin in editor, otherwise types dont work

- All imports via absolute URL, like Golang

- No backwards compatibility, so no existing code worked.

Since Deno 2, they've taken Node compatibility much more seriously, hence the 50% to 70% compatibility jump claimed here.

Bun on the other hand, tried to make things Just Work without requiring any thinking for Nodejs / TypeScript developers. It's basically the `node` development experience with all incidental frictions removed (but some segfaults added).

tl;dr: you can use `bun` to write node projects, but `deno` can only be used for deno projects

well benchmarks that's why

if the numbers look good, I pick it up -- though whether the numbers actually hold in reality is... well something I should check... but won't due to laziness...

I should check actual perf numbers... well next week or month?