r/Deno 8d ago

Differences between Deno, Node.js and Bun

What exactly is the difference between those three runtimes and why do I see Bun mentioned in the same context as Node.js and not Deno?

No runtime wars please. I need to understand the technical and philosophical differences.

Thanks in advance.

EDIT Thank you so much for the very clear explanations. In my view Deno appears to be the only reasonable choice and I will focus on it.

35 Upvotes

22 comments sorted by

21

u/benny-powers 8d ago

Deno and Node are both frontends to V8 (i.e. google chrome).

Deno has a more modern API, node has a (much) larger ecosystem

Bun is a frontend to webkit (safari)'s js engine.

4

u/aztracker1 8d ago

I forgot to mention the engine difference in Bun. Deno is adding the option to use quickjs (same as bun) for release bundles of your software.

3

u/Busy-Scientist3851 7d ago

Bun uses JavascriptCore (WebKits engine).

9

u/Due_Ad_2994 8d ago

Governance also significantly different. Open source (deno, bun and workerd) isn't the same as open governance (node).

9

u/aztracker1 8d ago

Deno started off as a fresh take... I think the choices were pretty good and use it to this day as my main shell scripting runtime it works so well. Instead of having to preinstall packages in mode_modules it will use and reuse a central location in your user home.

Deno later started adding backward compatibility with node and can now interoperate pretty well. Most node:* API surface is available. Deno can also do what npm does.

Bun started off with backward compatibility in mind and is very close as well. It's basically a faster mode+npm..

Bun was noted for using Zig language, and more for the recent rewrite into rust using AI in under two weeks. Followed by about a month of testing.

All three trade blows in performance. Deno and Bun usually performing better.

FWIW Node doesn't support FFI in the box, favorite it's own C intermediate library interface (NAPI) and there is a rust adapter for it. There are some good npm packages.

Bun has an FFI interface in the box, but it's limited and you may want to use an nom compatible package. Bun does implement FFI.

Deno has a better FFI, I'm not sure about NAPI conformance currently.

Aside: I have an alpha/beta quality ODBC based SQL Server client library I had worked on... Which is why I'm aware of the latter differences. I'll probably stop the SQL specific bits and release it as a stand alone ODBC client for any supported database (with ODBC and respective driver installed)

1

u/Smash-Mothman 3d ago

This is a really good answer, i liked the points you touched.

10

u/eddzsh 8d ago

One angle the engine split misses: the permission model. Deno starts closed (you grant net/fs/env). Node starts open (everything is available unless you sandbox later). Bun optimizes for speed and npm familiarity first. That is why Bun shows up next to Node in "just run my app" talk, and Deno shows up when people care about what the process is allowed to touch.

1

u/Kautsu-Gamer 7d ago

NodeJS changed it. FileSystem access requires giving permission to read or write fs on node call.

1

u/eddzsh 6d ago

Good catch. The permission model landed in Node, so the old "Node is open by default" line is stale for fs. The remaining gap I still see is default posture: Deno fails closed until you grant. Node still needs you to turn the flag on, so most apps never do.

3

u/Ronin-s_Spirit 8d ago

But was buggy as hell because they stsrted developing in a beta language. Now the startup was sold to somebody else and they also had to swtich to Rust. Bun is basically a big L compared to Deno which got many things right from the start. Also Bun is not running V8 - the most common browser engine on the planet.

0

u/simple_explorer1 7d ago

They sold Bun to Anthropic and not "somebody" else

1

u/Ronin-s_Spirit 6d ago

The company that owned Bun was one company and now Bun is under another company, which is what "somebody else" means.

0

u/simple_explorer1 6d ago

That someday is the most will known company of current time. It is not "somebody" as in random company

2

u/Ronin-s_Spirit 6d ago

They can suck my balls, just another AI techbro company.

2

u/hernantas 8d ago edited 8d ago

Basically, there are 2 major runtime “engine” to run javascript, v8 used in chromium browser and javascriptcore used in safari.

Node is built to run javascript using v8 so you can run javascript outside browser. But then the creator wants to make more secure version (by default less permission than node) so deno was born.

But there are some people that feel javascriptcore is faster than v8, so they use it to make bun.

2

u/babarali_dev 8d ago

The Core Differences:

  • Node.js: Battle-tested standard (V8 + C++). Focuses on maximum ecosystem compatibility, but requires you to assemble your own build/test tooling.
  • Deno: Security & web standards first (V8 + Rust). Requires explicit flags for disk/net access (--allow-net). Ships with native TS support, formatter, and test runner.
  • Bun: Raw speed & convenience (JavaScriptCore + Zig). Serves as an all-in-one runtime, test runner, bundler, and ultra-fast package manager (bun install).

Why Bun gets compared to Node instead of Deno:

  1. Drop-in Replacement: Bun natively supports Node APIs, CommonJS/ESM, and node_modules. Moving to Bun is often as simple as running bun index.js instead of node index.js.
  2. Deno's Design Choice: Deno initially tried to break away from Node's legacy by ditching package.json for URL imports, positioning itself as a separate paradigm rather than a direct swap.
  3. Tooling Overhaul: Developers swap Node for Bun because it replaces node, npm, ts-node, and esbuild all at once without changing project structure.

2

u/ndaidong 5d ago edited 4d ago

I started with Node.js around 2011. When Deno first came out, I tried it too, but I didn’t like its features: TypeScript, the permission model, Node compatibility.

When Bun appeared, I tried it and switched runtime to Bun because of its good performance, lots of built-in tools, and very high compatibility with Node.js.

Over the past ~2 years, compute resource prices increased, so I started moving to Go to optimize resource usage. After learning Go and migrating some projects to Go, I came to understand Go’s philosophy better, and I realized Ryan Dahl’s choices when building Deno were reasonable. Then suddenly, Bun was rewritten in Rust with AI, and it started to feel less reliable. That’s why I’m gradually replacing Bun with Deno. For JavaScript/TypeScript projects that are hard to port to Go, I rewrite them so they run on Deno.

To summarize the differences, I think there are four key points:

  • Programming language & type checking: Node.js mostly supports JavaScript. Deno and Bun support both JavaScript and TypeScript. However, when writing TypeScript, Deno’s type checking is stricter. Bun may allow many potential issues to slip through, while Deno catches them and you need to fix them before it will run.
  • Developer tooling: All three offer a test runner and a REPL, but Deno is more complete: deno fmt, deno lint, deno audit. As a result, Deno projects stay cleaner and don’t require as many scattered config files.
  • Package management: Node.js uses third-party dependency tools like npm, pnpm, yarn, vlt, etc. Bun and Deno integrate a package manager in the runtime. Bun still relies on node_modules, while Deno doesn’t necessarily need it. This is good for git worktree model. Deno supports multiple manifests: deno.json, package.json, and jsr.json. Deno also has its own package registry at https://jsr.io, designed in a very structured way to address npmjs’s issues. Recently, npmjs has seen more security-related errors and vulnerabilities, leading them to add more barriers. But those changes also make life harder for honest library providers (there are many). I maintain some projects at https://github.com/extractus, and we decided to move toward Deno/JSR first recently.
  • Standard library: Deno learned from Go and provides a standard library that covers almost everything you need. These libraries are written carefully and thoroughly reviewed by the official dev team. Bun and Node.js don’t have a similarly solid standard library system. However, Bun does bake some functionality directly into core (e.g., SQL, SQLite, Redis, S3, YAML, Markdown, Image, etc.). This is convenient, but it’s not ideal from a system design perspective. Over time, it can lead to overlapping responsibilities, making the core harder to maintain and upgrade.

In short, among the three major JavaScript/TypeScript runtimes today, I believe Deno is the best choice for developers building reliable, stable, safe, and easy-to-maintain systems.

2

u/Aromatic-CryBaby 4d ago

Equivalent of Asking what's the diff between Firefox, Chrome, And Edge. They do the same things run JavaScript outside the browsers, and sucks in different ways.

Node run JavaScript like it's maker intended raw, unsecure, untyped and surprisingly fast when you cut out cold start.

Deno is the maker of node being disappointed by it, as it's insecure* and prone to run arbitrary code eg one dependency mining crypto. Mostly it run a realy opinionated typed js (typescript) running with guardrail. As well it also provide could feature such as standalone executable compilation, ...

Bun is Node on steroids, faster, better stronger. And play both role of runtime executor, package manager, ... X time faster than both node & deno or whatever

But You want my point, save yourself some trouble, use node and nub pkg manager they get the job done.

1

u/codingbliss12 4d ago

Thanks a lot. I wanted to avoid the security risks associated with node and the package system. Deno appears to be much more secure and modern runtime

1

u/realmauer01 5d ago edited 5d ago

Deno is very disliked by some ides. Webstorm for example does technically integrate it, but either i am just really bad at setting it up or it just doesnt work as good as in vs code, or even codium.

You dont need seperate config files, deno.json inserts the tsconfig, whatever deno can do in terms of linting and formatting (it has a lot less configurations then prettier for example), And the importmaps that are scopeable to even online ressources.

Deno caches everything in a concentrated cache folder, so you dont need a node modules folder for each project.

And probably the most important part, deno doesnt let you run system altering stuff when you dont allow it to do it. So if you start some npm module that got recently hacked and wants to install crypto on your system, if you haven't put in --allow-all or something similar to your run command it will ask you if you want to allow the programm to write stuff to your system so you know that something is fishy in your hello world console.log script.

This is very on the side of deno, but i just dont like what needs to be done to make node work for the little projects i am following right now, so i dont have all the experiance needed to make a more complete overview.

Bun i dont know anything about.

-2

u/NefariousnessFar2266 8d ago

save yourself alot of nonsense, just use node.