Live data from Hacker News

Deno vs. Bun performance is rigged

unetworkingab.medium.com

131–140 of 196 posts

Re: Deno vs. Bun performance is rigged

#131

I'm surprised to read that "Bun actually sits above a URL router capable of matching methods, URL wildcards and parameters". I thought bun was just a JS runtime, though I guess thinking about it maybe I don't even understand what a JS runtime is . I always figured nodejs is v8 + an stdlib. I think bun is a custom zig-js engine + an extended stdlib (website claims "batteries included")? Isn't the router generally "app…

V8 only provides javascript execution. All the browser APIs need to be implemented by runtime such as fetch, filesystem, console, http, Intl, webgpu, serialization, any global objects, cloning, message passing, etc. Any module system and dependency management is part of runtime (loading scripts, running them before executing code, etc). Any other execution context such as workers or running wasm is also responsibilit…

Yes!

Re: Deno vs. Bun performance is rigged

#132
post #97

Earlier quoted context omitted.

> all else equal All else is never equal. The level of adoption and support is what drives decisions in the end. That's why everyone still uses Node when Bun is probably better in every way.

Also I shouldn’t have to say this but all of the current JavaScript applications have already been written. Switching a large production codebase to a new framework does not dovetail well with modern dev practices, amplifying the pain of doing so.

I don't think application developers are the main target for their product. OTOH, if AWS/GCP/ETC. adopted Bun transparently to run your cloud functions faster and using less resources (thus less $$) that would be a win/win situation for all parties involved.

Re: Deno vs. Bun performance is rigged

#133
post #10

Earlier quoted context omitted.

Exactly. Very few companies will need to reach 1000 reqs/s consistently, let alone 100k reqs/s. StackOverflow peaks at about 6000 reqs/s and it's an extremely popular website.

Except low concurrency is often found alongside slow response time.

Overly complex and feature-filled (or extremely barebones and "fast") frameworks can also have the property of giving no responses for additional months at a time. (i.e., sometimes "it works" is good enough, and our ego in design elegance doesn't need to get in the way of our need to keep existing as a business. If we need to rebuild or refactor later when we really know what we want, we can. :) )

Re: Deno vs. Bun performance is rigged

#134
post #59

Earlier quoted context omitted.

I’m sorry, but I simply don’t buy that. You either measured something unrelated (e.g. framework), or it was a faulty benchmark for some other reason.

I'm afraid it was a while back so I don't have it to hand, but what I do have is the techempower benchmarks [0] which show about a 10x difference between asp.net or go, and all of the js options. I'm not going to claim they're perfect, and would be happy if you could provide some info that supports your argument? [0] https://www.techempower.com/benchmarks/#section=data-r21

JavaScript is ranked 5th on the ranking you linked to.

4 ranks before .Net.

Re: Deno vs. Bun performance is rigged

#135
post #95

Earlier quoted context omitted.

No realistic , decently written, js application would be "orders of magnitude" faster if rewritten in .net.

And until we have a feature parity moderately complex web app written in multiple languages to compare, we'll never know. In the meantime, all we have to go on is basic benchmarks, and I've not ever seen a _single_ benchmark that puts any js, framework or otherwise in the same ballpark as java, .net or go. When I do, I'll happily change my tune, but until then I'll have to stick with what all the numbers I've ever se…

JavaScript ranks higher than C# in your benchmark.

Re: Deno vs. Bun performance is rigged

#136
post #64
post #43

Earlier quoted context omitted.

got a source for this stackoverflow peak? also wondering what peak RPS is for HN. i feel like most (non consumer) startups would be like "ok if its good enough for HN its good enough for me"

>got a source for this stackoverflow peak? It is [1] ( and should be ) pretty well known. 1.3 BILLION page view per month, 6K RPS with 9 ( Fairly Weak ) Servers, Sub 20ms response time with zero caching. >also wondering what peak RPS is for HN. Less than 100 RPS for logged in users. The number were pre 2020 but I doubt the current number is significantly higher. [1] https://stackexchange.com/performance

> Sub 20ms response time with zero caching.

I mean... to be clear, they do tons of caching[0], which is certainly critical for their ability to have a non-cached response time of 20ms. Most of their responses should be coming from a cache, given the type of site they run, otherwise they would need a lot more servers.

[0]: https://nickcraver.com/blog/2019/08/06/stack-overflow-how-we...

Re: Deno vs. Bun performance is rigged

#137
post #108
post #71

Earlier quoted context omitted.

And a real-world deployment of a single-threaded interpreter just runs multiple instances of it, so do and compare that. No need to "handicap" anything.

But then you need twice the initial app memory. This can be substantial for larger apps. There are definitely benefits of using multiple cores at once on a single app.

Sure. not an excuse to not benchmark it that way - if it struggles due to memory it'll show up after all.

Re: Deno vs. Bun performance is rigged

#138

Earlier quoted context omitted.

I'm afraid it was a while back so I don't have it to hand, but what I do have is the techempower benchmarks [0] which show about a 10x difference between asp.net or go, and all of the js options. I'm not going to claim they're perfect, and would be happy if you could provide some info that supports your argument? [0] https://www.techempower.com/benchmarks/#section=data-r21

JavaScript is ranked 5th on the ranking you linked to. 4 ranks before .Net.

I was hesitant as to how much I should go into this because you get into the semantics of the benchmark but this [0] thread goes into why - that particular implementation doesn't behave the same way as the other implementations, it uses a different db driver that doesn't synchronise, which won't be allowed in the next version of the benchmarks. Techempower publish regular snapshots of their benchmarks at [1], and if you look at any of the snapshots that aren't the last published set where the discrepancy was fixed you'll see that all of the js implementations lag far far behind.

[0] https://github.com/TechEmpower/FrameworkBenchmarks/issues/72...

[1] https://tfb-status.techempower.com/

Re: Deno vs. Bun performance is rigged

#139

Earlier quoted context omitted.

Properly supporting async seems like the main reason why it's taken off.

You think no one cares about the convenience of having the type system do a lot of the work for you? Or being able to autogenerate client libraries? I find that position confusing. Proper async support is decently important to me in any language or framework, but in the real world, I haven't often run into other developers who care much about that.

Async in Python is a huge deal as it is in any language, yes. For very real reasons (cutting down on incredible amounts of confusing boilerplate) to very lame reasons (it's been memed into developer consciousness enough that it becomes a primary yes/no gate for development teams).

Re: Deno vs. Bun performance is rigged

#140
post #95

Earlier quoted context omitted.

And until we have a feature parity moderately complex web app written in multiple languages to compare, we'll never know. In the meantime, all we have to go on is basic benchmarks, and I've not ever seen a _single_ benchmark that puts any js, framework or otherwise in the same ballpark as java, .net or go. When I do, I'll happily change my tune, but until then I'll have to stick with what all the numbers I've ever se…

JavaScript ranks higher than C# in your benchmark.

See my other response here https://news.ycombinator.com/item?id=33224873
Post reply on HN