As per the title, would be great to include an entry for https://github.com/websockets/ws as it is highly popular with over 70m weekly downloads on NPM.

Hey @SaltyAom!

At first, I'd like to thank you for including my framework, cheetah, in your benchmark. But I noticed that you're on a really old version of it and using (optional!) validation through zod which heavily impacts its performance.

I'll open a PR shortly which should fix this issue.

Elysia may returns only the text or JSON without the header in the test so it is faster than the Bun and Stric implementation.

This variant: https://github.com/uNetworking/uWebSockets.js/blob/master/examples/Benchmarker.cjs

should be about 2x the perf. for the first 2 tests. You could possibly add another test case called "uws with declarative response" or such. Would be interesting to see what results you get from that. I get about 2x.

Requires latest version.

Would be nice to see HatTip in the benchmark, as well.

HatTip is particularly suited for Vite, and is more standards focused than Hono.

Hi there, just sharing some data for comparison. My results are a bit closer to https://web-frameworks-benchmark.netlify.app/ and from https://fastify.dev/benchmarks/ then yours. I think Windows might be a huge bias.

Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
Linux Mint 21.2 kernel 5.15.0-82-generic

node v20.3.1
bun 1.0.0

For reference, I added a simpler Bun

const text = 'Hello, Bench!';

export default {
  port: 3000,
  fetch() {
    return new Response(text);
  }
};

and a vanilla http

const http = require('http');

http.createServer((request, response) => {
    response.writeHead(200, {
        'Content-Type': 'text/plain'
    });

    response.write('Hi');
    response.end();
}).listen(3000);

You may close this whenever you wish ;-)

EDIT: my fastify result was wrong, I fixed it

Would be nice to see HyperExpress in the benchmarks.

Here:

But in benchmark you are expecting it to be text/plain, I think that is the cause why you cannot run tests on Nest.js

You put nestjs into black list with the reason:

Is this supposed to be like this?

https://h3.unjs.io/adapters/bun

According to this, stricjs is scrapped by author, and the same person started a new framework called byte.

• Kingworld is not responding correctly - neither the body is sent back nor it has the correct header
• bun.ts is doubling json.stringify FIXED: #5

Maybe write a TODO app for each framework with some authentications.
See how hard it is to write a simple TODO app and compare the performance (signup/login API and rendering)

Right now, the output table looks like this (which isn't very readable)

What is uws ?

Hi,

bun-bakery is not working correctly now.

You can ignore it from the benchmark.

Hi!

This line seems to be incorrect:

Thank you!

Could these two runs be added to the list please?

Trying to get my own library added to this and I'm stuck re-running the whole benchmark each time with all of the other libraries.

Is there a way around this? I feel this there's something super obvious that I've missed. 😓

Would be nice to see also https://www.fastify.io/ in the benchmarks.

I adjusted the body.json payload to a more realistic response from your current api and got the following results:

maybe it would make sense to add a little bit bigger json payload because it gives totally different result

Ola,
In the latest bun update it seems like they have fixed some bottlenecks from before!

Could you update the results on the readme?

Can you set the number of requests to a high value like 2 millions and the number of connections to 5000?
Or maybe set the request duration to around 30s on each test.

The JIT takes some time to compile and you should delay the process for around 10s for optimizations to work.

Your test is good because the requirements make it impossible to cheat with a simplified parser / hardcoded response. BUT - the requirements for JSON parsing is ambiguous.

If you change the rule from "Server MUST parse body to JSON and serialize back to string" to something like "Server must respond with the value from JSON key "hello", then you have a defined requirement that is never ambiguous in what it means to "parse json".

Because, to parse and serialize JSON is basically "no operation". But taking the "world" from key "hello" makes it defined.

With the "uws framework (node)" entry always being the top performer, why is it only ever run under Node.js and not re-run under Bun also?

I understand uws is used as the built-in web server of Bun and then also ElysiaJS. But there's no vanilla standalone benchmark run for it using Bun? Is it not possible?

For example, Hono on Bun looks like it performs badly. But just go to src/bun/hono.ts and change the export to export default { ...app, host: '127.0.0.1' } (instead of export default app) for an instant 20% speed boost that puts it right up, near the top.

according to hattipjs/hattip#114 (comment)

As per title

Steps to reproduce

1. install bun v0.7.2
2. bun install
3. bun run benchmark

Output

>>> bun run benchmark                                                                       $ node bench.mjs
30 frameworks
- bun/baojs
- bun/bun
- bun/bun-bakery/index
- bun/bun-web-standard
- bun/elysia
- bun/express
- bun/hono
- bun/hyperbun
- bun/koa
- bun/nbit
- bun/nhttp
- bun/stricjs
- bun/vixeny
- deno/abc
- deno/acorn
- deno/cheetah
- deno/fast
- deno/hono
- deno/oak
- node/adonis/index
- node/elysia
- node/express
- node/fastify
- node/h3
- node/hapi
- node/hono
- node/hyper-express
- node/koa
- node/nest/index
- node/uws

Estimate time: 15:30 min

 baojs
 > bun baojs 

NODE_ENV=production ENV=production bun src/bun/baojs.ts

Current size: 80x24. Wanted size: 80x25.

I'm not sure the reason this message is being reported, as my terminal is bigger than 80x24.

You may have never heard about this before, but just add it, it is worth it