4 ms·

To grossly oversimplify, it's a choice between "make things better by starting fresh" (Deno) vs "make things better but don't change anything" (Bun). Bun's appr

To grossly oversimplify, it's a choice between "make things better by starting fresh" (Deno) vs "make things better but don't change anything" (Bun). Bun's approach is easier to adopt, and seems to be "good enough" for many people. Deno made a very deliberate compatibility break from the Node ecosystem. They wanted fresh start, to make smarter choices and ditch historical baggage. They thought people would be motivated to push through the adoption friction. I think that plan has been less successful than hoped, and Deno keeps walking it back. They're more compatible than before, but aren't a drop-in replacement. IMHO they prefer it that way. Bun, on the other hand, explicitly feels that any compatibility gap with Node is a bug. Bun wants to beat Node at its own game, wants adoption to be as easy as running `bun index.js` instead of `node index.js`. Then you opt into their special APIs as-needed. Bun's headline feature is "free speedup", but they also target many of the same DX conveniences Deno does, like trivial TS integration. When Deno came out, the question was "how is Deno better than Node?". Deno had strong answers, give or take the compatibility differences. But today you could instead ask, "why port to Deno instead of just dropping in Bun?", and that's more complicated to decide.

tmikaeld 2y ago
For me, building production software in Deno - it's the sandbox that sets Deno apart. Knowing that even if there's a bad package, it can't call any external server or write/read files from disk. Even generally, I now know that the code I wrote don't do any unauthorized things I didn't explicitly tell it to do.
- alabhyajindal 2y ago
  How common is this scenario really? I rarely find myself using obscure packages. Most of the ones I use are hugely popular and vetted by the developer community.
  - thejazzman 2y ago
    Their dependencies have dependencies which have dependencies and their dependencies dependencies' could be compromised If you think someone is reviewing all the code every time a new release is cut... popularity means it's one of the hottest targets.

tmikaeld 2y ago

For me, building production software in Deno - it's the sandbox that sets Deno apart. Knowing that even if there's a bad package, it can't call any external server or write/read files from disk. Even generally, I now know that the code I wrote don't do any unauthorized things I didn't explicitly tell it to do.

alabhyajindal 2y ago
How common is this scenario really? I rarely find myself using obscure packages. Most of the ones I use are hugely popular and vetted by the developer community.
- thejazzman 2y ago
  Their dependencies have dependencies which have dependencies and their dependencies dependencies' could be compromised If you think someone is reviewing all the code every time a new release is cut... popularity means it's one of the hottest targets.