In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.
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.
even with blocking lifecycle scripts, the attacker could have planted it somewhere else or just trick the dev somehow to run it
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.
- 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
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?
A lot of dependencies and frameworks simply did not work with Deno for a long time. In the beginning it didn't even have the ability to install dependencies from npm. (In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things).
So Bun was a better Node with a lot of very nice quality of life features that just worked and it required much less configuration.
I think the Deno team kind of realized they needed to have compatibility with Node to succeed and that has been their focus for the past couple years.
Edit: And Deno is now more compatible with node than bun.
"Probably"? Are you saying there's a chance he wasn't right?
I really think Ryan deserves a lot more credit than a "probably". He put in a lot of effort to do the right thing and improve the security of the entire ecosystem he created.
we nodejs devs were just ignorant/lazy
npmjs should mark libs "deno compatible" and move over to deno gradually for security
Nice to see Deno being maintained. The features listed seem pretty substantial.
and yet Bun's npm compat is much much lower than deno
Seriously, they're both Rust now. They share goals.
But it's possible that all 3 Deno, Node, and Bun could share some code in the future considering they now all require Rust as part of their build process.
1. add 'enhanced security mode' that's actually 'deno-compatible/like' (permissions, etc)
2. mark libs/executables/etc as 'enhanced security compatible'
3. ...merge by buying out deno?
I'd love to see a site comparing the 3 of them in a similar way.
Bun 1.3.14 is at just 40.6% with same compliance test.
This is an annoying to do for exactly two platforms: node.js, and deno.
node.js bcs it requires a workaround whenever something networking comes in: fetch doesn't work the same. So you structure you're code around having a node.js workaround. Same story for some other APIs. But you can test if itn works!
Deno is more annoying, you just can't test your package with deno before publishing. Before we released to npm, we installed a tar file and sent those around for testing. Works in node, in vite (node, for browser), works in bun, like a charm. Doesn't work with deno unless you switch to package.json, and you use exactly the subset of the spec that deno supports. You can't "deno install xyz.tar", you have to use npm for that (inserts a single line into package.json), THEN you can use deno to execute. No docs, no hint, just trial & error.
Even more annoyingly, npm & bun both offer 'link': in package repo, call npm/bun link, in the test repo do npm/bun link @yourpackage, and that's it, it's installed. Creates a dyn link to the source's build dir so you can rebuild without packing or sending tars or anything like that, you just build in your package dir and the test project is immediately updated.
Deno doesn't have that. What's worse, they don't tell you they don't have that. Also basically no error messages. It just fails in weird ways. Spent hours trying to do it. Now I just publish without testing for deno and wait for bug reports.
So out of the three: bun just works. That's it. Better than any platform. It just works, and it has a nicer CLI & nicer error messages, and it's faster on startup. It has the web api and the node api (i think) and its own api that's very nice as well, nicer than e.g. node. And e.g. if you run bun link, it tells you exactly what happened: this is what just happened, this is what you have to do to use it elsewhere. Node doesn't have that!
I think deno recognized bun's strategy of using npm dev's backbone as being the better call - that's why they're now slowly introducing node.js features, even though that goes against their original USP.
So, I switched to Bun and things have been much smoother!
By then bun was already a thing and just ate into its share.
My point was at the time when deno came out it was completely different to node with its imports and that meant a lot of existing packages just didn’t work out of the box. That just slowed its traction.
Personally I would have like deno it stick with url imports and not added the npm support.
Ryan set out to “fix” his mistakes with node only to fully embrace them again.
me for example only use nodejs or bun to run a basic sveltekit server, so it can render the html for the first time. all core functionalities are delegated to backend services written in crystal or rust. I don't need some bloated js runtime that hoard 500MB of ram for that purpose (crystal services only take 20+ MB each).
bun promised a lean runtime, every essential functionality is written in zig to increase the speed and memory footprint. and javascriptcore also uses less memory compare to v8. the only thing we expect is for bun to stabilize and can run 24/7 without memory leaking or crashing.
too bad it is a failed promise now.
(It seems too bad ChakraCore is mostly out to pasture and not keeping up with TC-39 and that there's still no good Node-compatible wrapper for SpiderMonkey, but having one for JavaScriptCore is still a breath of fresh air.)
But Deno's got Node compatibility now, and Node has adopted a lot of the features that make Deno and Bun so usable. So I'm not sure the choice matters so much these days.