Deno has members in Ecma TC39, so they take part in the development and standardization of JS.
Deno brings a new mentality to development focused on simplifying things, whereas Bun aims to be an improved Node.
Deno aligns with web APIs: you can use the same APIs in the browser and in Deno. Many packages work in both platforms. Deno is even in the compatibility tables in MDN.
Deno simplifies DX greatly. It's very easy to work with Deno. Easy to install things and set up a project, easy to deploy, no config files etc.
Deno is written in Rust, which allows them to move faster and more safely. Contributing to and extending Deno is a breeze. You can add Rust crates to the runtime and use them from JS.
I feel like the Bun team has been too pressured by executives and marketing. They announced 1.0 when Bun was clearly not stable enough, giving lots of segfaults. Even their readme had a huge statement right in the beginning saying that Bun was not production ready yet, despite 1.0 being hyped all over the place.
> Deno is written in Rust, which allows them to move faster and more safely. Contributing to and extending Deno is a breeze. You can add Rust crates to the runtime and use them from JS.
Pick your horse to bet on. They both have great teams behind them. Bun (written in Zig) claims higher performance. It looks promising but independent tests have yet to validate these claims.
They also kinda have different goals. Bun seeks to be more of a drop-in replacement from Node whereas Deno, being spearheaded by the same person who made Node, seeks to move the industry forward and fix mistakes Deno made. However Deno, out of necessity, has also highly valued backwards compatibility with the Node ecosystem
It's a weird scenario. You have node which is entrenched, feature-rich, and stable although not perfect. Then you have two runtimes/ecosystems trying to optimize on that but in slightly different ways. I love it but I feel like there is barely room for even one. It's just incredible there is so much work being put forth into moving the needle maybe an extra 20% on the existing node/npm status quo.
> Deno, being spearheaded by the same person who made Node, seeks to move the industry forward and fix mistakes Deno (I assume you mean Node.js) made.
If they aren't able to evolve Node.js to overcome the mistakes (e.g. because they're technical in nature, or momentum of install base, or they don't have the leadership ability), I am worried that they might repeat the same pattern with Deno, since it isn't possible to NOT make any mistakes.
OTOH, having a clean slate that's learned from mistakes and you can bring a lot of your code along doesn't seem like a major impediment.
Is code written for any of the 3 runtimes generally transferrable? I realize some won't (e.g. Deno has WebGPU support, which is attractive to me), but generally?
The main difference is that Deno was thought to evolve hand in hand with browsers since the beginning. Node followed its own way and fragmented the JS ecosystem. It got to a point where it was basically impossible to realign Node's direction without breaking everyone's codebase. Mistakes will be made in Deno, but the direction of the project now takes into account the ecosystem as a whole.
Deno has members in Ecma TC39, so they take part in the development and standardization of JS.
Deno brings a new mentality to development focused on simplifying things, whereas Bun aims to be an improved Node.
Deno aligns with web APIs: you can use the same APIs in the browser and in Deno. Many packages work in both platforms. Deno is even in the compatibility tables in MDN.
Deno simplifies DX greatly. It's very easy to work with Deno. Easy to install things and set up a project, easy to deploy, no config files etc.
Deno is written in Rust, which allows them to move faster and more safely. Contributing to and extending Deno is a breeze. You can add Rust crates to the runtime and use them from JS.
I feel like the Bun team has been too pressured by executives and marketing. They announced 1.0 when Bun was clearly not stable enough, giving lots of segfaults. Even their readme had a huge statement right in the beginning saying that Bun was not production ready yet, despite 1.0 being hyped all over the place.