Asking as someone who has yet to try either.
Asking as someone who has yet to try either.
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.
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.
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.
Surprised I haven't run into any of these incompatibilities.
Sounds like I have some reading to do.
Bun has better speed and great documentation. And they're shipping new features very fast.
(a) With npm, Microsoft is the gatekeeper of everything NodeJS. URLs are the most decentralized way to do dependencies.
(b) Self-hosting can help with some security issues with npm. Makes it easier for private projects to not have to trust npm hosted third party libraries, which is important in many corporate environments.