Closed kurtextrem closed 2 years ago
Don't think it's necessary, and likely wouldn't fly to them anyways All the libraries in fastify/benchmarks are pure Node.js solutions built on top of the Node.js HTTP module uWebSockets.js-based solutions would dominate the charts, simply because at that point you no longer build on top of the Node.js HTTP module, but native bindings (in the case of uWebSockets, native bindings written in C/C++) You could say it's no longer fair to compare At least until if for some reason they accept the PR that wants to add uWebSockets.js itself https://github.com/fastify/benchmarks/pull/234
Yep, as @BobbyWibowo mentioned above, I almost always try to only submit hyper-express to benchmarks that aren't strictly restricted to Node.js HTTP module based solutions as uWebsockets.js will have a clear upper hand in just pure throughput. While one can make the case that the developer experience/API from a webserver is really the only thing that should matter for being benchmark candidates, this would just lead to arugmentative discussions in said PRs/Issues.
Hi,
the benchmarks in the README are impressive, maybe it would be worth to submit hyper-express to the fastify benchmark repo? https://github.com/fastify/benchmarks