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.

[axww]

The main difference is JavaScript Runtime.

[babakfp]

What the creator of Deno did?

• Learn Rust.
• Spend a lot of time and effort to create a runtime from scratch.
• Spend a lot of time and effort to create Rust binding for V8.
• Spend a lot of time and effort to reinvent everything from scratch; Like the formatter, linter, vsCode extension and more.
• Lose on all the great tools and what is being done in Node ecosystem.
• Say Deno is not Node and later change your mind about it because you find out no one is using Deno and there are no libraries and tools getting build as fast and as good quality in Node ecosystem.
• Spend a lot of time and effort to get Deno to be somewhat compatible with Node; And it's not even compatible.
• Spend time and effort on building a new registry.
• Say Deno is going to use URL imports and this is what makes Deno great, and they change your mind about it because it sucked.
• Spend time and effort on building a new package manager that for a long time didn't even have the basic features.

What the creator of Deno could do if he could go back in time?

• Fork Node and build on top of it.
• Focus on adding new features and improving the performance.
• Stay 100% compatible with Node and allow people to migrate with no effort.
• Done!

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...

[BlackAsLight]

This is a very simplistic and naive take.

[eldoy]

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.

[KawaiiSelbst]

This is a very simplistic and naive take.

If you also consider that the creator of Deno is the creator of NodeJS 😁

[BlackAsLight]

This is a very simplistic and naive take.

If you also consider that the creator of Deno is the creator of NodeJS 😁

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.

[babakfp]

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.

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.

[GroophyLifefor]

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.

[siddht4]

---

The Evolution of JavaScript: From Browser Script to the Global Standard

For over 15 years, the JavaScript ecosystem has undergone a transformation unlike any other in computing history. What began as a tool for simple browser animations has become the backbone of modern enterprise infrastructure.

1. The Big Bang: Node.js and the V8 Revolution

In 2009, the backend landscape was dominated by Java, C++, PHP, and C#. These languages were powerful but often "heavy," requiring complex threading and high overhead.

Ryan Dahl changed everything by extracting the V8 Engine (the muscle behind Google Chrome) and applying it to the server.

• The Paradigm Shift: It introduced an event-driven, non-blocking I/O model.
• The Unified Stack: For the first time, developers could use one language (JavaScript) for both client-side and server-side code.
• The Result: Node.js became the "chassis"—the base car design upon which the modern web was built.

---

2. The Era of Maturity: TypeScript and Frameworks

For years, "serious" developers viewed JS as a hobbyist scripting language. That changed when Microsoft introduced TypeScript. By adding static types, JS suddenly became as robust and predictable as Java or C#.

This triggered a "boom" in professional tooling:

• React (Meta/Facebook): Revolutionized component-based UI.
• Angular (Google): Brought enterprise-grade structure to the frontend.
• VS Code (Microsoft): Built on JS (Electron), it became the world’s Fix Small Typo: privlaged → privileged #1 code editor.
• Vite/Vue: Redefined how we bundle and build applications with lightning speed.

---

3. The Runtime Wars: Node vs. Bun vs. Deno

As the ecosystem grew, the limitations of the original Node.js design (like the node_modules "black hole") became apparent. This led to the rise of new competitors.

The Engine Room: V8 vs. JavaScriptCore (JSC)

The core difference between these runtimes lies in the engine that executes the code:

Feature	V8 (Node & Deno)	JavaScriptCore (Bun)
Origin	Google (Chrome)	Apple (Safari)
Strengths	Peak Throughput: Optimized for long-running server tasks.	Startup Speed: Optimized for instant "cold starts" and low latency.
Compilation	Uses multiple tiers of JIT (Just-In-Time) compilation.	Uses a 4-tier JIT; generally more memory-efficient.
Language	Built in C++.	Built in C++, but Bun’s "wrapper" is built in Zig.

The Car Analogy

• Node.js (The Reliable Base Car): The foundation. It is the industry's defacto standard and has the largest library of parts (NPM).
• Bun (The Formula 1): Built for raw performance. It includes a bundler, test runner, and package manager that are 10x-100x faster than Node's defaults. It aims for 90%+ compatibility with the "Base Car" design.
• Deno 2.0 (The Refined Sedan): Also built by Ryan Dahl to fix Node's original flaws. While Deno 1.0 was "No-Node," Deno 2.0 embraces the NPM ecosystem while offering a more stable, secure, and "batteries-included" experience.

---

4. The "Holy Grail" of Packages: NPM and JSR

NPM (Node Package Manager) has become the "Holy Grail" library—the standard registry that every JS engine must support to survive. However, the industry is moving toward a "hardened" future:

• JSR (JavaScript Registry): The latest evolution. It is a modern, TypeScript-first registry that works across Node, Deno, and Bun. It aims to solve the security and speed issues of traditional NPM while remaining backward compatible.

---

5. Conclusion: The Defacto Standard

JavaScript is no longer just for websites; it is the defacto standard of web infrastructure. We have reached a point where the "overhead" is gone, the engines are faster than ever, and the developer experience is unmatched.

Whether you are driving the Reliable Chassis (Node), the F1 Racer (Bun), or the Refined Sedan (Deno), you are part of the most vibrant ecosystem in tech history.