Jarred-Sumner
commented
2 weeks ago Deno feels slightly more stable (for now)
We’re continuing to work very hard on making Bun more reliable. In the next release we are shipping many improvements to Bun’s HTTP server - like the cancel method in ReadableStream will be called on abort (instead of only the request’s AbortSignal). A memory leak involving accessing the ReadableStream of a Request or Response and then calling a buffering method like .json() is fixed, along with a 50% HTTP request throughput improvement for that scenario. We’re also fixing bugs when using proxies, named imports of CommonJS modules converted to ESM, etc.
This issue is more of a question what it would take running Deno projects out of the box with Bun. Is it enough to shim the Deno namespace? Does Bun need to support jsr?
Shimming the Deno namespace should be enough. You could implement a module loader plugin to support jsr, or you could use npm and not worry about it.
Also from a competitive standpoint this might be interesting to consider maybe?
Bun is at a point now where our monthly downloads are about 2x Deno’s monthly downloads based on all the publicly available numbers I could find. The real compatibility focus for us is very much Node, as we have just under 1.5% of Node’s marketshare and Node compatibility is (and has been) a huge project.
GerbenRampaart
Hi people. I find myself more and more on a crossroads in my company developing cli/apis in selecting runtimes. Deno feels slightly more stable (for now) but Bun is just so much more compatible and faster coming from node.
This issue is more of a question what it would take running Deno projects out of the box with Bun. Is it enough to shim the Deno namespace? Does Bun need to support jsr?
Also from a competitive standpoint this might be interesting to consider maybe?