Would love to see the benchmarks checked into source control somewhere so folks can reproduce them.

Can't say I'm the biggest fan of the way the sample code types itself out character-by-character. Took a while for the longer samples to finish typing themselves out.

Are tweets 2800 characters now? (Genuine question, I haven't used the place in years.

Congrats on this, keep building more stuff!

https://princejs.com/

Also parsing the body on every request without the ability to change it could hurt performance (if you're going for performance that is as a primary factor).

I wonder if the trie-based routing is actually faster than Elysia in precompile mode set to enabled?

Overall, this is a nice wrapper on top of bun.serve, structured really well. Code is easy to read and understand. All the necessary little things taken care of.

The dev experience of maintaining this is probably a better selling point than performance.

interesting to dig deep into the bun runtime (it's in zig) to see how this remains efficient. it's a heap: https://github.com/oven-sh/bun/blob/509a97a43516fe4f6d4ff400...

of these: https://github.com/oven-sh/bun/blob/509a97a43516fe4f6d4ff400...

pretty cool clean and simple code for the framework (and bun).

A potential user would want to know: why is it faster? What's the compromise, if any. What specific quantifiable technical points make it faster than other libraries. Benchmarks and tests.

Overall the library feels like a polished open-source project, good attention to design and detail. Definitely valuable as part of a portfolio/resume. Keep going!

however, the author is benchmarking a route with an id param here, not a static route.

[1] https://github.com/uNetworking/uWebSockets/discussions/1415

Has "Prince" in his HN nick and framework name

I smell either a rat, or an incredibly meme-savvy kid who leaned into the joke.

Anyways, congrats and keep on hacking!

1. File size is a commonly highlighted metric for JS frameworks because of network transfer cost on the client side. For node/bun/deno frameworks, it isn't very relevant, especially the gzipped size.

2. In the benchmark, the number for all frameworks is quite low - I get closer to 80-100k req/s with Bun on my 3-year old machine. Might be worth using a standard VM size in a cloud provider to make it more meaningful.

3. "Cron" scheduling doesn't seem to belong in the library. This won't be very useful for real-world use cases, as soon as you have >1 node running a server you'll need some form of coordination. More size reduction :)

A few notes:

- it's easy to be faster than other routers when you're doing less, for example it seems wildcards are not supported yet, and there's no tests but I suspect there would be a lot of bugs in the way routes are handled. I wouldn't focus that much on speed

- your code organisation is ok for a personal project, but it could use a bit of structure. things are all over the place, I would try to separate pieces of functionality that can be developed (and, importantly, tested) in isolation. For example, your router could be its own module, that way it would also be easier to get started in writing unit tests. (once you've got some example code you can just offload a lot of the test writing to an LLM, then clean them up manually as it will do stupid things)

- your benchmarks are quite low in general, I don't know how good the node.js tool you're using for it is but I would give them a go with something like oha. also, it's very odd that hono beats elysia in your tests, in my own testing elysia is much faster than hono, but it suffers from the same tradeoffs as any trie based router (more set up time)

- instead of zod, you should use the @standard-schema/spec package, so that it can work with any validation library (including zod) – they have some nice type utilities too that simplify inferring types from schemas

As well as being slightly more hardware independent, it also helps highlight exactly how efficient/inefficient the code must be.

This code is ~100k clock cycles per request.

In traditional development, the backend engineer writes the API and writes the relevant documents. Then, the frontend developer writes the request API function based on the documentation.

However, in type-safe API development, once the backend API is finished, the frontend merely needs to install the API module and import the API function, eliminating the need for any manual wrap code.

But anyway, good job, you are build something, and it's amazing!!

One my favourite instances of this was in a benchmark measuring contest with a Golang enthusiast who was surprised to see that with a bit of latency his server was not 3x faster than Node.js like he thought it would be.

However, there are no tests yet.

That's some incredible comedic insight for a 13yo.

Have you benchmarked again since you added zod and other features ? It's not related to the api in itself, but since I'm mainly a mobile user, can you make your website responsive ?

First of all, I admire you for taking the hard way of learning to build your own stuff, especially at your age.

However, I have a concern to believe that the benchmark result is a false positive, and inaccurate.

From my experience working and maintaining the Bun HTTP framework for 3 years since the first release of Bun 0.1.0. Bun.serve is extremely fast that autocannon (the benchmark tool you're using) cannot keep up with the performance, causing the report to be skewed from hitting the limit of the benchmark tool instead of an actual framework.

This is mentioned in Bun documentation. https://bun.com/docs/project/benchmarking#benchmarking-tools

- For load testing, you must use an HTTP benchmarking tool that is at least as fast as Bun.serve(), or your results will be skewed. Some popular Node.js-based benchmarking tools like autocannon are not fast enough.

It would be nice if you could update the benchmark with the tools that can report is faster than autocannon for the most accurate result.

Other than that, I'd say great job!