Deno team and their take on Bun

[eldoy]

Bun went 1.0 yesterday and seems to do most of what Deno does, and more. It apparently crushes Deno in performance, and they really made a smart move making it a drop in replacement for Node, and allowing mixing of ESM and CJS. Did Bun just make Deno obsolete? Why would I choose Deno instead of Bun right now? Any qualified opinions?

[markthree]

Bun went 1.0 yesterday and seems to do most of what Deno does, and more. It apparently crushes Deno in performance, and they really made a smart move making it a drop in replacement for Node, and allowing mixing of ESM and CJS. Did Bun just make Deno obsolete? Why would I choose Deno instead of Bun right now? Any qualified opinions?

nodejs, bun and deno are all server-side js runtimes, but they have completely different goals.

As far as I know, the nodejs ecosystem is currently the best, and the other two runtimes are also compatible with the nodejs ecosystem, so they will converge in the future, but some nodejs libraries use magic that is unique to nodejs, which may be difficult to do in terms of compatibility.

bun is more concerned with performance, so it is much better than the other two runtimes in terms of performance right now.

deno is synonymous with safety in my opinion, I can safely use packages from the community without worrying about them doing things to my system that I don't know about.

node is now starting to make a big push on performance and security, too.

Competition is good, js runtime is starting to evolve

Summary

If the project focuses on ecology → node
If the project focuses on performance → bun
If the project focuses on security → deno

[eldoy]

So you're saying if Bun implements all of Deno's security features, then Deno has no reason to live?

They don't really have "completely different goals" though, they are almost the same thing except a few differences in features. Some of Deno's seem to be more ethical than practical. To not be designed as a drop in replacement for Node requires a parallel ecosystem, which doesn't make it worth the switch from Node to Deno. But to switch from Node to Bun is almost a no-brainer if they deliver on what they promise.

[markthree]

I apologize that my description caused you to misunderstand.

It's ok to understand it as different characteristics.

As I described at the end, it depends on what our project is more focused on.

They can actually coexist, users have different needs to focus on, and it's up to them to choose which runtime to use for different projects.

For example, I chose all runtimes, just in different project scenarios

[markthree]

Also to add another competitive advantage I know about deno -> edge runtime

deno is doing very well in the edge space, not only deno deploy, but also supabase edge and netlify edge are using deno as edge runtime.

In addition to the edge aspect, there are also innovative products such as deno kv that provide competitiveness in the database.

This is all I know about the deno product line, others are welcome to add other runtimes ↓

[jcarres-mdsol]

From what I've seen in other communities Bun will have a lot of traction. performance == money so that's a huge incentive right there.

As soon as that is evident I think Deno and Nodejs projects will look at what tricks Bun is pulling and copy them where possible. As long as Deno has ways to improve itself I would not rush to declare it dead.
This is all going to be for the best of the community, great times.

[NeoVance]

The only "tricks" Bun is pulling is not using V8.

[raythurnvoid]

but how V8 is slower than JavaScriptCore when we all see that the amount of effort in V8 from MS and Google is much higher than what Apple puts in JavaScriptCore. I don't think it's only a matter of js engine.

I have the feeling that Bun will get slower over time while fixing the issues they have at this moment.

[NeoVance]

It's a mistake to assume that because there was a lot of effort and money put into something that will just automatically translate into better performance. It’s worth noting that React Native also chose JSC over V8 years ago because it was faster for their use case.

There are other things to consider, like where they focused the effort. Also, when we’re talking about speed, we’re actually talking about different types of speed since there are lots of tradeoffs to consider.

• JSC prioritizes faster start times, while V8 prioritizes fast execution
• JSC has 3 optimizing compilers (more complex, but faster), while V8 has 2 optimizing compilers (less complex and easier to use, but not as fast)
• JSC’s architecture uses less memory but it executes code a little bit slower, V8 does more runtime optimization, but that takes more memory and slows startup time
• JSC outperforms V8 at regexp, setting properties, and some strings-related tasks whereas V8 tends to outperform at typed array access & promises.

But you are half right, it's not just about the performance of the underlying engine, but about the wrapping code, the FFI, and possibly a half-dozen other variables related to the architectural decision that each project made. Deno picked the heavier runtime engine, with a simpler, easier to use interface, and that decision most likely plays the single largest role in the outcome of the benchmarks that have been published.

It's not just some particular trick or optimization that they are doing to get more performance out of their underlying engine. It's just as simple as the engine choice to a large degree.

[aapoalas]

JSC outperforms V8 at regexp

Just a nitpick: RegExp is one of the places where V8 outclasses JSC (source: https://bugs.webkit.org/show_bug.cgi?id=258706)

[NeoVance]

A bug report about some specific case where regular expression compilation isn't JITed only proves that there are some specific cases where V8 can outperform JSC on regular expressions. It doesn't invalidate my claim, or give much weight to your own. There are some patterns that JSC doesn't have support for in the YARR JIT, but for the majority of commonly used patterns, JSC will be faster.

[raythurnvoid]

Coming here after a couple of months and looks like bun is growing very rapidly. They claim to support playwright and Grpc. I haven't tried yet but I will soon.

The only thing that concerns me about bun is windows compatibility that they are addressing, debugging experience (I haven't checked recently but was horrible at the time) and the fact that every patch fix fatal crashes (it means that they are working hard but also that bun is not exactly production ready).

Deno exists since a lot of years already and seems incredible that bun is catching up this fast.

Without considering the cloud features and security that are specific to deno, at the current pace I wouldn't be surprised if bun will catch up on deno in terms of maturity, features and node compatibility in 1/2 years.

[deadcoder0904]

i saw this thread on reddit -> https://www.reddit.com/r/rust/comments/172d3qx/zig_is_3x_faster_than_rust_can_rust_be_more_faster/

and saw the comments & thought to myself, if rust can be as fast as zig, why isn't the deno team optimizing rust code like bun did with zig.

why not hire rust performance experts & beat bun out of the water. competition is good. and deno is ahead of the competition. bun will take time to catch up. deno can just copy bun's best ideas like providing node compatibility, being a drop-in replacement, not needing permissions by explicitly specificying a property in package.json, faster cli, better ux/dx, etc...

curious if the rust code in deno is as optimized as it should be? idk anything about systems language but reading the comments in that thread makes it seem like rust can be as fast as zig so its probably the code you've written more than the language or runtime used.

[NeoVance]

Being a drop-in replacement comes with a lot of design concessions. It would be nice if interoperability were improved though.

[deadcoder0904]

@NeoVance that is true but if you wanna beat node, that's how you should do it. reason why bun got all the adulation than deno did despite having more done. deno's roadmap makes it clear that it is definitely working on more node.js compatibility.