Performance Comparison: Fact or Propaganda? Node.js vs. Bun

Which runtime performs better when handling dynamic content and template rendering, especially under heavy loads?
To make a fair comparison, we've created two similar applications and put them on separate servers with the same specs.
While performance matters, it's not the only thing to look at.
Project repository: github.com/Moh-Snoussi/nodejs...

[@sammy12337]

Very good, your channel's will soon grow🚀!

[@mom_4life132]

They kick off at 7ms, and Bun edges ahead by ~30ms. But is that enough to make the switch from Node.js? For me, it's not just about the milliseconds - it's the time, effort, and potential compatibility issues.

[@snoussihamza2345]

Awsome content, keep going!

[@code-for-me]

Thanks, will do!

[@ajayshivhare]

Thanks keep it up

[@code-for-me]

Thank you too

[@ashwink4442]

Good Quality

[@code-for-me]

Thank you for your feedback!

[@rizkyadisaputra]

ok then show us how it reliable in the future in term of its security

[@code-for-me]

Bun plans to eliminate potentially unsafe code through static analysis rather than runtime permission checks. Runtime permission checks may be considered in the future: github.com/oven-sh/bun/discussions/725

[@jihedsboui4331]

tounsi el youtuber hedha ?lol

[@code-for-me]

yes, I'm Tunisian! 😄

[@steveoc64]

Micro benchmarks are pretty useless. Bun is a safer bet long term … why ? Codebase. Node’s codebase is a bit of a mess, and is past the point of being able to keep up. Bun’s codebase is lean and mean, with plenty of room to continue to make quantum leaps. It has at least 2 more years of dramatic improvements in the pipeline before it slows down.

[@code-for-me]

We hope that Bun will be a better bet. As for the determination of which codebase is 'better,' I think that can be subjective and context-dependent. Do you consider the current tests I conducted as micro benchmarks?

[@steveoc64]

@@code-for-me Yeah, sry ... my "microbenchmarks" comment was more aimed at general comments floating around the inter webs in the form "OK, so its a bit faster here, and a bit faster there .. but .... compatibility / safety is more important", whilst (IMO), missing a bigger picture. This is a point you made at the end of the video as well (but for possibly different reasons) Your performance tests here are pretty thorough - bit more than microbenchmarks for sure. Appreciate the work you put in to do that + post to github + edit a video... that's still a lot of work, and deserves respect :) Performance numbers .... hmmm. They are close indeed, but both a bit on the slow and memory hungry side ? I would be interested in seeing how far this can be pushed using just JS tooling ... just for fun of course :). Be nice to see either of them handle the loads with sub-millisecond response times. Im keen to have a play with that and see how far each can be pushed. Something to think about ... and it would make great material for a followup video. On codebase "betterness" ... yes that is always going to be subjective, especially when things are close. In this case, the codebases are far from being close. The Node codebase in C++ is understandably quite full of baggage now after all these years. The Deno codebase (in Rust) is pretty much set in concrete, and is a horror to experiment with. The Bun codebase is written in Zig, which is a much nicer language to do tricky system programming with. So just saying that Bun is on a really fast trajectory with adding features because of this current codebase. Deno won't be able to keep up. For example - memory usage ! It's 2 weeks since you posted the video, and in the interim, Jarred has mentioned that they have been able to drop the memory usage way down. You could also try re-running your benchmarks with `bun --smol bun_server.js` which will give less memory, at the cost of a bit of performance. More tuning options should follow soon hopefully.

[@code-for-me]

Thanks, I'll certainly take your suggestions into account, especially regarding the --smol flag. Your input has been very insightful, particularly regarding the codebase differences.