Replies: 7 comments 15 replies
-
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 SummaryIf the project focuses on ecology → node |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 ↓ |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
The only "tricks" Bun is pulling is not using V8. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
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. |
Beta Was this translation helpful? Give feedback.
-
Just a nitpick: RegExp is one of the places where V8 outclasses JSC (source: https://bugs.webkit.org/show_bug.cgi?id=258706) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
Being a drop-in replacement comes with a lot of design concessions. It would be nice if interoperability were improved though. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
The main difference is JavaScript Runtime. |
Beta Was this translation helpful? Give feedback.
-
|
What the creator of Deno did?
What the creator of Deno could do if he could go back in time?
Vite team are building a formatter, linter etc. Deno team put so much time and effort on building their own thing, but instead they could just use what they are building. Same with other tools, libraries, registry etc. They could get everyone using Node2 and then just do other things they wanted to improve things even more. Bun is similar... JS ecosystem in short is, everything sucks, people build tools to make it suck less, but these tools also suck, so people build tools to fix this, and you end up trying to build things with sucky suck sucky tech... |
Beta Was this translation helpful? Give feedback.
-
|
This is a very simplistic and naive take. |
Beta Was this translation helpful? Give feedback.
-
|
Javascript engines aren't sucky tech, they are awesome. Agree that some of what has been built on top of it is over-engineered, unstable garbage, luckily writing your own libraries is super-easy. |
Beta Was this translation helpful? Give feedback.
-
If you also consider that the creator of Deno is the creator of NodeJS 😁 |
Beta Was this translation helpful? Give feedback.
-
babakfp here is merely lashing out due to not being able to access Deno's website and such in their country due to sanctions between America and them. |
Beta Was this translation helpful? Give feedback.
-
Bro is so offended by objective cretinisms towards Deno that he can help himself. Stop saying nonsense. People can't respond properly to cretinisms that they do personal attacks. |
Beta Was this translation helpful? Give feedback.
-
|
Bun is still not stable in Windows in my experience. Too much crash and makes development terrible, in the other hand, Deno is most stable runtime after node, with so much support and ecosystem, I would prefer Deno than Bun. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions