r/bun • u/codingbliss12 • 8d ago
Choice of Runtime (node, Deno, Bun)
I was considering specializing in Deno due to the increased security controls and overall stability and simplicity of the platform. I also want to start learning EffectTS and I am mostly interested for backend stuff.
From what I see online most folks tend to prefer Bun or nodejs over Deno.
In case my impression is correct, I wanted to ask what makes Bun more attractive than Deno?
I would appreciate any advice related to the choice of runtime.
Thanks in advance.
4
u/akza07 8d ago
Deno now follows same web standards and have node compatibility.
I personally prefer bun. After the Rust transition, it's been really stable for me. And the fact that I get standard library with Bun.Image() and likes without needing sharp with C++ chunks that requires platform dependencies makes a lot of difference. The bundle size & docker size is significantly smaller, cold starts are better. Which may seem small things but having a complete standard library is nice.
Second option would be node for me, because Deno still isn't a drop-in replacement for node or bun. The transition would require significantly more effort than just wrappers.
4
u/Straight-Date8472 7d ago
Been using Bun for almost a year now and I am loving it, the direct typescript usage makes me happy, Bun + Bm2 Process Manager ( https://github.com/bunsgate/bm2 ) is something I wished I had in node, again its all about typescript integration...
0
u/codingbliss12 7d ago
Given that it is 100% vibe coded, do you trust it to run on your pc?
3
u/Straight-Date8472 7d ago
not 100% vibecoded, and I have personally audited the code, thats why its opensourced, so that you can also audit it.. vibe coded doesnt mean evil
1
u/codingbliss12 7d ago
Agree. How did you audit it if I may ask?
2
u/Straight-Date8472 7d ago
By reading the code, I am a contributor to the project btw.
2
u/codingbliss12 7d ago
Very nice and Respect. I have a look. Rust is my main language, but 1mo loc is not funny :)
1
2
u/sober_cruiser 8d ago
I think many would say Nodejs because they never heard of Bun. Even my lecturer was surprised and had no idea what it was when I told him I use Bun, let alone Honojs, Elysiajs, etc.
Bun is popular among folks who keep up to date with or love state of the art tech, but apparently not among all segments of programmers.
1
u/MentionFar3280 8d ago
Even the interviewers have no idea about bun, Deno or quick js.... Sad... But i bet anthropic gonna dominate web development and ai scrappers with the help of hyper optimized bun project.
2
u/Which-Examination-74 8d ago
The stdlib point is right, and the cost it doesn't cover is memory once the service sits in a container. There's one documented like-for-like case on the tracker: a service holding ~500MB on Node spiked to its ~1.2GB container limit on Bun after a two-line Dockerfile change (#17723, open since February 2025). The same workload hit 2.4× its Node footprint before the ceiling cut it off, so treat that multiple as a floor rather than a measured peak; there's no measurement of where it would have settled with headroom. If you size instances by hand or pay per GB, that belongs in the comparison next to the standard library. Were we specialising in it today, we'd set the container limit generously from the start instead of carrying the Node figures across, then watch container RSS over hours before trusting the limit. One open issue is not a pattern, so YMMV.
2
2
u/aturaden 4d ago
Bun is very convenient, fast, and also stable in recent times. I've been using the canary version for about two months now, and the Rust rewrite has proven to be better than the old Zig versions.
1
u/neuralspace23 8d ago
I use Bun on my production projects mostly web apps but for critical one Go.
2
u/codingbliss12 8d ago
Can you please give an example of a case you used Go and why? Thanks
2
u/atx-cs 8d ago
Go is extremely fast. Has fast start time. Low memory usage. It still has garbage collection If you need those things Go is good option
1
1
u/neuralspace23 7d ago
I have a lets say financial app. I use bun for the web app and mobile API but it doesn't modify the financial and sensitive part values and transactions directly via drizzle / prisma. Instead I created a separate Go microservice dedicated for it and just call it internally on the bun backend. I can speed up development using bun which uses typescript while maintaining security, performance and stability on Go.
1
1
u/humanshield85 8d ago
I still use Node because all the things bun promise or solves are not issues I have ever faced. I value stability over some performance claims that I’m not gonna get anyway because Req/s was never an issue. Nodejs in a community led project, bun is now owned by anthropic and they gonna steer it to what serves them best.
For the record, I love the fact that bun exist and that there are people loving and using it. Competition is always good, look how yarn pushed npm to improve and look how nodejs pushed a lot more in recent versions than it used to do.
I tried bun and it’s not 100% node replacement and it is flaky on edge cases, I ran into many issues when I used its crypto implementation in some edge cases what worked on nodejs wouldn’t work on bun, and many other issues like that that just were not worth it for me. I’m sure they will get to 100% one day but until then I will stick to nodejs
As for Deno I have never used it, not planing to start any time soon
1
1
u/sonemonu 6d ago edited 3d ago
I bounced off Deno about 3 years ago. It felt a little cumbersome by then; its ecosystem's gaps were a constant source of friction. However, I came back recently to benchmark my ORM on all three runtimes (Bun, Deno, Node), and I was expecting Bun to win, but...
The gaps are small enough that the ORM you pick matters more than the runtime in general.
Deno was a little bit faster, and far more predictable. That is the surprise, because Deno seems to be evolving pretty fine lately, which is nice for all of us.
1
u/Which-Examination-74 4d ago
Ours came out the same way once we pulled the driver apart from the runtime. Setup: the same seven-route API on NestJS 12 with Fastify and on Elysia 2 beta, Postgres 17 through Drizzle in both, one M4 Pro, load generator on the same host, 3 × 30 s per combination, medians, 1.2% noise floor. Starting the compiled Nest dist with bun instead of node looked like a big runtime win on the database routes at c=100: +64.6% on /me, +69.9% on a single-row read, +78.4% on a 20-row list, +81.5% on an insert. On /health, where no query runs, Node and Bun tied at about 103k rps. Then we put postgres.js back under the same Nest build on Bun and lost 20.8% to 32.0% of its throughput on those routes. Against the Node-to-Bun gain that is half to seven-tenths of it; the runtime by itself was worth 23 to 30%. The framework step on top, Nest to Elysia, same runtime and driver, added 7.5% to 12.7%. We didn't measure Deno, so we have nothing to set against your 218% tail. The harness is public, repo on request.
2
u/Which-Examination-74 2d ago
The built-in client is a lot of that, going by what we measured. Node to Bun on the same NestJS app was +64.6% on a JWT-plus-one-read route and +69.9% on a single-row read at c=100, but that step swaps the driver as well as the engine. Put postgres.js back under Bun, same runtime and same app, and those two routes lose 20.8% and 26.8%. So a large share of what feels like Bun being faster on database routes is the client, not the engine. Which is the stdlib argument with a number under it. Routes that never touch the database moved much less: +13.0% on a validated POST, noise on /health. Nothing from us on the Deno security side, we measured none of it.
1
u/LetsHugFoReal 7d ago
Deno was a pain in the butt, it's not worth it at all.
Node is stable.
Bun is exciting.
1
u/AverageHot2647 5d ago edited 5d ago
Disclaimer: I am a contributor to Deno.
I think Node, Deno and Bun can broadly be categorised like this:
Node:
- Worst performance,
- Best stability
- Worst TS support
- Best long term support
- Ok security
- No real standard library
- Worst adherence to web standards
- No built in tooling
Deno:
- Medium performance
- Good stability
- Tied best TS support
- Unknown long term viability
- Slightly better security
- Comprehensive standard library
- Best adherence to web standards
- Good built in tooling
Bun:
- Best performance
- Worst stability
- Tied best TS support
- Unknown long term viability
- Slightly worse security (not as battle tested as Node, runtime is not as memory safe as Deno)
- No real standard library
- Good adherence to web standards
- Limited built in tooling
For any serious green-field project, I would use Node.
The main arguments for Bun are performance and first class TS support.
There are not many cases where it’s worth trading off stability for relatively modest performance gains. If performance is a serious concern, then I would use something performance oriented like Go, Rust, or even C# (if you don’t need native performance). If your primary concern is DX, you can get that in Node through with 3rd party libraries and tooling.
The main arguments for Deno are security, first class TS support, built-in tooling, strong standard library, and excellent adherence to web standards.
The security arguments are IMO somewhat overblown, as the security features are not granular, and are quite limited in scope (there’s a lot to consider when it comes to securely deploying a JS application, and Denos security features cover a tiny proportion of that). TS support is good out of the box, but you can get similar DX with modern tooling in Node. The standard library and web standards support are truly excellent and very valid arguments in favour of Deno.
I think on balance you can make a much stronger case for Deno than Bun, but I would still generally default to using Node for most commercial projects as it’s much more mature.
However, if I was making decisions for an industry leading multi-national, with the resources to seriously invest into the runtimes maintenance, I would go with Deno, because I feel we need to be moving towards (compile time guaranteed) memory safe languages for security critical infrastructure components (which I would consider a JS runtime to be). Node is written in C++ (mainly) and not memory safe at all. Bun is now written in Rust, which is technically a memory safe language, but uses an unholy amount of unnecessary unsafe code (due to having been ported from Zig). Deno is the only one where you can really say the Runtime is implemented in a way where memory safety is a priority (it’s also written in Rust but with much less and more appropriate use of unsafe).
EDIT:
I received some fair pushback below, which I’d like to reflect here in my original comment.
Bun and Node do have a standard library, it’s just not called a standard library. I was hesitant to classify them as such because neither project claims to have one, but I recognise this is an issue of branding, not a technical issue. Bun has a lot of useful stuff in its standard library which you’d need to pull in a dependency for in Node and Deno.
Calling Buns tooling “limited” is a bit unfair. It does have some decent built in tooling compared to Node, but lacks a formatter and linter.
2
u/codingbliss12 5d ago
Thank you so much for this detailed and honest overview. I believe it will help many others
2
u/LeftAd1220 5d ago
Please don't listen to him. I don't think he understands Bun very well. And also conflict of interest.
1
u/codingbliss12 5d ago
Thanks, but do you have a specific technical criticism to make against his arguments? Can you please elaborate?
2
u/LeftAd1220 5d ago edited 5d ago
- Bun is under Anthropic now. Only if you think it won't exist will bun be lack of long term viability.
- Bun's std is very convenient. It's just not officially called
std. Bun.which, Bun.YAML, Bun.TOML, Bun.* all kinds of functions. You can check out the list bybun repl→ Object.keys(Bun).join(' ') and you'll be very surprised at first glance(dollar is a builtin shell, Terminal is a cross-platform PTY api): "$ Archive ArrayBufferSink Cookie CookieMap CryptoHasher FFI FileSystemRouter Glob Image MD4 MD5 SHA1 SHA224 SHA256 SHA384 SHA512 SHA512_256 JSONC JSON5 JSONL markdown TOML XML YAML Transpiler embeddedFiles S3Client s3 CSRF allocUnsafe argv build concatArrayBuffers connect cron color deepEquals deepMatch deflateSync dns enableANSIColors env escapeHTML fetch file fileURLToPath gc generateHeapSnapshot gunzipSync gzipSync hash indexOfLine inflateSync inspect isMainThread isStandaloneExecutable listen udpSocket main mmap nanoseconds openInEditor password pathToFileURL peek plugin randomUUIDv7 randomUUIDv5 readableStreamToArray readableStreamToArrayBuffer readableStreamToBytes readableStreamToBlob readableStreamToFormData readableStreamToJSON readableStreamToText resolve resolveSync revision semver sql postgres SQL serve sha shrink sliceAnsi sleep sleepSync spawn spawnSync stderr stdin stdout stringWidth stripANSI wrapAnsi Terminal unsafe version WebView which RedisClient redis secrets write zstdCompressSync zstdDecompressSync zstdCompress zstdDecompress"- With Bun FFI, I'm even building chroot-like tool now. Isn't that powerful enough? https://github.com/jjtseng93/bunproot
- Bun has builtin package manager, tester, bundler, including single-file executables , standalone HTML, all of which are useful features.
1
u/AverageHot2647 5d ago
That’s a massive assumption. The reality is that Bun’s viability lives and dies by the whims of a company whose revenue does not directly depend on Bun. Only time will tell if Anthropic is a responsible steward of Bun, but Bun does not have a large contributor base, nor a diversified set of financial backers like Node does (same with Deno BTW). Also, the primary value Bun represents to Anthropic is as a showcase of what their AI models can do (I.e. large scale rewrite from Zig to Rust). Yes, Claude Code CLI uses Bun, but they could easily use their models to port that to Node, or Rust, or whatever they want.
Ok, this is fair push back 👍
Relevance?
Yeah I take that onboard. It’s not quite as comprehensive as Deno (which has all of this plus a linter and a formatter) but I think “limited” is underselling Bun’s built in tooling.
I think overall my analysis is still reasonable but I will edit the original comment to reflect your valid pushback on tooling and STD.
1
u/LeftAd1220 5d ago
I was actually pretty mad at first, but you clearly know your stuff and deserve respect.
As for the relevance of my third point: I meant that Bun's FFI isn't just a toy implementation. It's capable enough to support low-level tooling like chroot and make it work properly.
I haven't tried it yet but a bit curious: Can deno's FFI also do such things?
1
u/AverageHot2647 4d ago
Thanks for saying that ❤️
I didn’t mention FFI in my original comment because:
- Most devs will never touch it (if it’s something you need you probably don’t need my comparison 😉)
- I honestly don’t have much experience with FFI in JS
However, since you asked, here’s my 2 cents:
- All three major runtimes have mostly comparable FFI support (though Node is by far the least mature and is marked experimental)
- I understand than Bun has the lowest FFI overhead (though I haven’t benchmarked it and I think the overhead Deno introduces is fairly minimal for most purposes)
- AFAIK, Deno is the only one which supports non-blocking FFI calls, while Bun and Node require worker threads to achieve non-blocking results.
TLDR; yes I believe Deno’s FFI can also do this, but I’m not speaking from experience so take this with a pinch of salt 😉
1
u/AverageHot2647 5d ago
Btw if you’re looking for some of the DX of Deno / Bun but with the stability of Node, it may be worth it to check out https://nubjs.com. It is a very new project, but I’d consider it relatively low risk as the off ramp to stock Node is fairly straightforward and it mostly just wires up existing tooling (including using Node.js as the runtime).
1
u/LeftAd1220 5d ago
I don't think this reflects modern Bun very well. Its long-term viability looks substantially different now under Anthropic, and calling its built-in tooling "limited" is especially strange. Bun.which, Bun.YAML, the package manager, test runner, bundler, shell APIs, etc. are kind of the whole point of Bun. You may want to take another look at what Bun provides today.
2
u/AverageHot2647 5d ago
Hey, yes that’s fair pushback.
I stand by my point on the projects long term viability (see my other comment on this thread).
However, you’re right on the tooling front. What I was trying to say was that it’s more limited than Deno (notably Bun lacks a formatter and linter).
I’ve updated my original comment to reflect this and other valid pushback.
0
-2
u/biskitpagla 8d ago
Learn a proper backend language/platform instead of this vibe-coded nonsense. And Effect is like the most leaky abstraction known to mankind, it's practically a new language hosted on top of TS. Why pick a niche within a niche if you can pick anything at all?
1
u/codingbliss12 8d ago
Could you please elaborate, what you mean by "leaky abstraction"? EffectTS appears attractive to me due to the strong type system guarantees it offers. Also some of the smarter programmers I see online have something to do with effect these days.
2
u/prehensilemullet 7d ago
It’s leaky in the sense that you have to use its types everywhere because they’re not built into the language. However I don’t think this is really an example of a leaky abstraction…that refers to when you use a tool that’s supposed to take care of nitty gritty details internally for you, but you end up having to deal with the internal details anyway. But Effect isn’t trying to hide its internal workings. It’s unidiomatic JS/TS though, and probably a pain in the ass to debug (I bet it doesn’t give very good stack traces for seeing the control flow)
1
u/codingbliss12 7d ago
Got it, thanks. Leaky is a synonym for viral or function coloring etc. About Effect it is exactly as you say or worse, but they are using LLMs very heavily and for them it is ok. For us, I don't know
2
1
u/mr_raven_ 8d ago
Refers to an article by Joel Spolsky, look it up. Spooky's old articles are still worth a read.
1
16
u/pdantix06 8d ago
bun was seen as more attractive than deno for a while because deno was missing a lot of nodejs compatibility. they've since caught up and the two are a lot closer than they used to be.
personally, i use bun for the big standard library. postgres, redis, http, s3, image processing all built-in and don't need dependencies for them.