Bun vs Deno

A couple of days back I posted about my newfound love for Bun, the JavaScriptCore (JSC) based runtime, that smoked the competition in both their official benchmarks as well as my own semi scientific tests.?

From what I could see it really was faster, like the Bun team said, and an easy drop-in replacement for good old NodeJS. But in my eagerness, I forgot one thing... to test it out with Deno.? ?

I have some experience with Deno from before but never really got round to using it in my day-to-day life. Something did not click. It’s faster and safer but for some I forgot about it after the initial buzz wore of. But how does it stand up to Node and Bun??

Well first of I decided to adopt the old Next.js project, from before, I had lying around. The results were, after some tinkering, as predicted by the Bun benchmarks. Node is lagging behind and was beaten by the others by a substantial margin. Deno handled double the amount of request and was about 80% faster to do so but, was outshined by Bun. Bun was two and a half times faster than Deno and about 450-500% faster than good old Node.? ?

I also decided to but the benchmarks to a test and ran some of the once that Bun supplies.? The result where on par with the results presented by the Bun team and I tested it on several real Windows (WSL) machines as well as some virtual, ran it on proper Linux setups as well as MacOS.? All performed well and within the expected parameters.? ?

But what about something that has not been optimized of for that same reason is even a proper and well thought out solution? Something horribly random and cobbled tougher that would never see the light of day and with no logical purpose. So, for a final test wrote my own benchmark.? ?

Normaly benchmarks test one specific feature to see how they hold up against each other. The result often varies once you use the features tougher and might even have a revers effect on performance. So instead of comparing apples to apples I prepared a fruit salad.? ?

Each request will query an SQLite database (good old Northwind) to get two random products, do some calculations on their price and product info, use that so select a file (the same image reproduced 10k times in the file system), do some simple image processing and save it to disk and lastly return that file to the end user.? ?

All in all, a complete waste of time and with no optimizations or practical use and with garbage performance as a result. But even so, the results where interesting.? ?

NodeJS, struggled with this idiotic task giving it a score of 11.36 request per second (total time to complete 1k request dived by a thousand). Deno took the task as a challenge and took the predicted second place with 24.49 requests, but they were all beat by Bun that did the task with 31.51 request.? ?

So, Bun won but not with the margin I had expected. Deno performed admirably but did use double the amount of CPU and memory that Bun did.? ?

Everyone and their mother are benchmarking right now and when you read up on it the results vary drastically. The only thing that is constant is that NodeJS is lagging behind on every test. Deno or Bun are the winner each and every time. It seems the milage does vary between use cases.

And after this benchmark I will have to purge my computer from this unholy abomination of garbage code.?

Is this the end of NodeJS (and V8 based runtimes)? Well, no or at least not in the long run.? Competition will spur the development and optimization of the others to try to beat Bun and the race is on. And we, as developer and end-users, will reap the rewards. The status quo of the last couple of years is broken and we have a new and exciting tomorrow to look forward to.