I always figured Bun was the "enterprise software" choice, where you'd want to use Bun tools and libraries for everything and not need to bring in much from the broader NPM library ecosystem.

Deno seems like the better replacement for Node, but it'd still be at risk of NPM supply chain attacks which seems to be the greater concern for companies these days.

▲

skybrian 4 hours ago | parent [-]

If you want to download open source libraries to be used in your Bun project then they will come from npm, at least by default. [1].

So it seems odd to say that Bun is less dependent on the npm library ecosystem.

[1] It’s possible to use jsr.io instead: https://jsr.io/docs/using-packages

▲

kenhwang 4 hours ago | parent [-]

Yes, both can pull in open source libraries and I can't imagine either dropping that ability. Though they do seem to have different eagerness and competency on Node compatibility and Bun seems better on that front.

From a long term design philosophy prospective, Bun seems to want to have a sufficiently large core and standard library where you won't need to pull in much from the outside. Code written for Node will run on Bun, but code using Bun specific features won't run on Node. It's the "embrace, extend, ..." approach.

Deno seems much more focused on tooling instead of expanding core JS, and seems to draws the line at integrations. The philosophy seems to be more along the lines of having the tools be better about security when pulling in libraries instead of replacing the need for libraries. Deno also has it's own standard library, but it's just a library and that library can run on Node.

	▲	skybrian 3 hours ago \| parent [-]
		That’s true of some parts of Deno’s standard libraries, but major functionality like Deno.test and Deno.serve are Deno-specific API’s. Here are the Bun API’s: https://bun.com/docs/runtime/bun-apis Here are the Deno API’s: https://docs.deno.com/api/deno/