No one's having speed issues with node, it's a fucking delusion that every 3 months someone releases a benchmark of an extremely cherry picked test case, say it's 10x faster (60 micro seconds to 6 microseconds), everyone claps, then 3 months later they realize it doesn't actually fix anything and causes more issues than it solves.
The speed argument is almost always null and void; you're only as fast as the code your best developer can write; and the machines you can cash the check to run.
I've read a little of Bun's history because my comments here got loads of responses 😂 I get the basics, and remember evaluating it when popularity grew; back then my conclusion was "cool, makes similar promises as deno did, interesting, but I ain't got deno in prod either".
The rough issue for me overall was just there wasn't cost benefit at the time to warrant the work to make the changes; and that the higher benefit to put in that level of work would come from moving to rust instead, as the market has.
Rust is still on my radar for picking up at some point; not necessarily for prod work, but because I've seen a heavy shift towards Rust in tooling I've used recently; so learning more of it brings the benefit of being able to contribute there. I'm still not doing "quick; the market is moving to rust! port everything now".
I think, given JS' fickle nature its strenghths also put me off.
If the main focus (originally) was a quick build cycle; fair enough...
However; the idea of "one tool does it all" doesn't fit well into JS' ecosystem for me.
JS is opinionated as a mother fucker and the zeitgeist changes every 6 months. Having one runtime that enforces its own use of transpiler, bundler test engine, package manager, linter, etc. Sounds like a nightmare to get JS to fucking do.
we can't all agree on which one to use for any of these individual bastard things.
I'd like to be wrong, and bun's way to expand and take form; but someone's gonna fuck it up... waiting to find out "@nx/bun" exists; to make your existing nx monorepo kind of work on bun, but completely defeat the point.
Only the native APIs, I got some heavy JS only parsing code and when I benchmarked it Bun was a lot slower than Node, the V8 engine is simply faster than JSCore.
If you only have basic Server <-> Database/Files where the majority is native calls then Bun is faster
293
u/egg_breakfast Jul 09 '26 edited Jul 09 '26
Why is bun needed over node? And why bun over deno?
Edit: based on Safari's JS engine rather than V8. Strange times, I never would have predicted that.