Why people use Deno and Bun over Node? I think it's neat that there are competitors for JS runtimes, but I really don't understand what advantages I'd get by swapping to one of these over Node. Bun has no REPL and worse JS engine, Deno is just Node with a restrictive, annoying permission system and no sqlite. Both claim better performance, but that only seems true in cherrypicked benchmarks, and in my tests (granted about a year ago at this point) both alternatives under-performed Node in my workloads. What am I missing?
EDIT: Actually I just remembered I delivered a small ERP tool to a business a while back and I did opt to use I think Bun for that because it had the most robust tools to wrap a project into an `*.exe`, that was definitely a better experience than Node. Though since that was dependency-less JS I did the whole thing using Node and then just shipped it with Bun.
I switched to Deno because it is the only option out of the 3 that allow monorepo workflow without building .d.ts files. Bun and Node both do type stripping or compiling of TS, but it only works for the entry package of the running script, not any of the linked dependencies from the same repo.
There are still things I dislike about Deno, but it really does make package development a lot simpler. JSR is a great upgrade from NPM, and Deno makes it so simple to publish to both NPM and JSR. Strict IO permission system and WebGPU support are also nice to have.
> wrap a project into an `*.exe`
Deno makes this simple too. Though that's where it's bundling features stop. Honestly I am okay with that, I'd rather use Rolldown or Vite for web or library bundling.
Deno has been great for wrapping the dozens of REST API's I need to use in the world in MCP. The no compilation thing means that I can push and it's literally deployed in seconds. I run several dozen of the little servers for various use cases, it's a very cheap way to build an automatable life
> Both claim better performance, but that only seems true in cherrypicked benchmarks, and in my tests (granted about a year ago at this point) both alternatives under-performed Node in my workloads.
1) You need to retest again, mainly because Bun's own native tools should be faster than Node's.
2) My experience is the opposite: For the niche uses I'm on, the rendering process is done 2-3x faster with only a few changes to use Bun's tools.
Started using Bun last year for some quick tests and it ended up fully replacing Node for any new projects after using it for over a decade.
I've reduced my dependencies 5-10x. Got full TS and JSX/TSX support with zero setup. Watch mode is instant. You can deploy a single binary.
I kept waiting for all the breaking issues people complain online but my experience has been nothing but positive.
> Bun has no REPL
Bun has a really nice REPL, can recommend https://bun.com/docs/runtime/repl
I am gonna check my sources better next time lmao, sorry!
I like Deno because there is no "install" step for users, you just run it.
Deno has sqlite: https://docs.deno.com/examples/sqlite/
So does node, since v22: https://nodejs.org/api/sqlite.html
They even added sql template string queries like recent popular libraries in v24.
I just built a project using it.
Ah my mistake, this wasn't the case last I used it, thanks for pointing this out, I checked briefly and referenced stale data.
The Bun DX is infinitely better than Node's, especially for Typescript projects
In what particular way? I've been using Typescript a lot more recently (unfortunately XD) and I've found the native experience in Node to be totally fine.
Node's built-in profiler doesn't work with Typescript, which is one part of Node not natively supporting TS. Idk how it is in Bun, cause that made me abandon TS rather than abandoning Node.
Node supports ts natively now though.
even enums? last I tested, it did type-stripping only.
And looking ad docs, it seems it only has partial support still: https://nodejs.org/api/typescript.html
> To use TypeScript with full support for all TypeScript features, including tsconfig.json, you can use a third-party package. These instructions use tsx as an example but there are many other similar libraries available.
Agreed- node/npm are exceptionally well run and designed. Personally I also prefer the non-TypeScriptiness.
> Deno is just Node with a restrictive, annoying permission system
I find Deno's permission system amazing! (although I didn't stick with it until v2)
Everything is closed by default but you're able to write code like normal.
Whenever it needs a permission the code pauses (like `debugger;`) and the terminal asks you "hey, should this script have access to this file/folder"?
- You say yes and the code continues (no need for exceptions).
- You say no and the code stops.
Then after your program has run, you put only the answers you said yes to in a deno.json file and it never has to ask again.
---------------------------------------
I'm currently working on a project that takes in heap of files from one one set of devs, processes them with a heap of files from another set of devs, then compiles and outputs the final product.
The file structure goes like this:
1. Group one devs
2. Group two devs
3. Build output
4. Compiler
So group one only works in their folder, and group two only works in their folder, but needs to see group one's folder.
With Deno it's stupidly easy to do stuff like:
- Scripts in group one only have file read access to group one.
- Scripts in group two only have file read access to group one and two.
- Scripts in the compiler only have file read access to group one and two's folders, only have file write access to build-output folder, and can read the env file in the project's root directory.
- One specific file is only allowed to access a specific URL and port
- Another specific file is only allowed to use the FFI to access a specific shared object.
I don't need to worry about a dev's script accidentally using the wrong file because they messed up the path.
I don't need to worry about a dev accidentally overwriting a file and losing data.
I don't need to worry about a dev blindly going down the wrong road because an LLM convinced them to.
I don't need to worry about a dev using LLMs agents that are trying to make the project do something it's not supposed to do.
I don't need to worry about a dev including a dependency that's doing what it shouldn't be doing.
I don't need to worry about the equivalent of `rm -rf ./$BUILD-OUTPUT` but the env file wasn't set up correctly and $BUILD-OUTPUT is empty/undefined evaluating to `rm -rf ./` and nuking the project's root.
I don't need to worry about supply-chain attacks.
I don't need to worry about namesquatting attacks.
There's so many things I don't need to worry about.
It's such a breath of fresh air.
It's just: you guys read from here, other guys read from here, the compiler writes to here.
Whenever something doesn't fit, the program stops and tells you what file is trying to access what permission.
---------------------------------------
aside: Node added a permission system but it's completely broken by design. Everything's open and you have to manually close each permission yourself. Oh, you don't want this project to have file write permissions? Lets just turn off the file write permissions (and forget to also turn off the subprocess permissions to spawn a shell which rm -rf's the wrong folder).
...try `bun repl` in your terminal
otherwise, bun has a big "batteries included" thing going on.
For instance,
- Bun.$ to run shell commands
- an entire redis client at Bun.redis
There are dozens of other examples like this
For rapid prototyping, complex glue scripts, etc. it's an absolute joy to work with. There is often no reason to pull in any dependencies to accomplish what you want.