[samwillis]

This post doesn’t link to the original benchmark, or any code to verify what’s being suggested. Along with the click-bate heading, I think it’s fairly irrelevant.

My assumption is that this is a micro benchmark doing just an echo response, that is so far from what Bun/Deno/Node will ever be used for it’s just a farce.

The speed of your application frameworks http server will (almost) never be your bottleneck.

Developer experience, available libs, security model, packaging, deployment story, and to some extent resource usage (within reason) are far more important.

[tyingq]

>This post doesn’t link to the original benchmark

Searching Google for the exact text in the slide doesn't yield any results. So perhaps that was part of the post author's angst...that the numbers were presented in a venue where they wouldn't get much scrutiny?

Edit: I did find that the author has posted previously about Deno, and seems to not be a fan: https://unetworkingab.medium.com/deno-is-slow-and-why-associ...

[dmix]

If you look at that blog post he posted benchmarks (again without posting the source or methodology) and be compared Deno vs Node vs uWebsockets.js which is just a small C library with a thin JS layer on top.

It seems like they are promoting their own library and doing a bit of their own deception by including a small library in their tests. Particularly a library that was designed entirely to perform well at that particular usecase (high throughout for small bits of data).

https://github.com/uNetworking/uWebSockets.js

[samwillis]

I did the same before posting my comment, I wanted to check what actually was going on.

> that the numbers were presented in a venue where they wouldn't get much scrutiny?

The OP has done the same though by not linking to or explaining the context. Or showing the code.