This is cool, and it's a really impressive feat especially for someone with relatively little experience due to your age.
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
Great job with building and releasing a project. The API looks intuitive, almost the same as Express. Documentation site is good! The animated code blocks is nice on front page but too distracting in the docs itself, I think.
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!
Hi! I'm a maintainer of Elysia, the framework you claim to have outperformed.
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.
- 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.
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 :)
- JWT needs to be validated, as it is, your implementation[1] happily accepts anything, you can impersonate anyone you want. I'd argue that it's a bad default choice too [2]
- baking-in resend.com as email provider is unlikely to be useful for most people
- x-forwarded-for [3] is only added by proxy servers, and will often not be present. This means you'll be applying a shared rate limit to most of your users
- the 'ai' helper is missing from the code. If this is vibe-coded, having tests for the examples will help keep it cohesive
Object.defineProperty on every request to set params / query / body is probably slower than regular property assignment.
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.
Considering this is barely any code at all I imagine it doesn't provide anywhere near the feature set other web frameworks do. Also there are no tests. How do you know it even works properly? Why would I trust that it works properly?
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.
This is really interesting, but I'd absolutely love if you could add a light theme to your website. I really can't read on a dark background, it kinda hurts my eyes and when I take my eyes off the screen I see a bunch of horizontal lines for a minute or so.
Congrats for the good and impressive work. You also implemented very fast the remarks like zod and not animated docs.
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 ?
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!!
My favourite question to ask when seeing benchmark results such as this is “how much latency did you have / inject when running the benchmark”. This tends to lead to interesting conversations and learning. :)
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.
The readme and stats remind me of VanillaJS, which should be a sign that you're not making a fair comparison here. Anyhow, I think this can be a very educational experience if you keep adding features and benchmarking — it'll get slower, but you'll know exactly why.
This is pretty impressive, wow! I always wanted to build a toy HTTP requests framework just to better understand the tools I’m working with, and here you are building the full thing.
It’s almost certainly not because of the advance fee scam.
You don’t have to meet many Nigerians before you find one that claims to be some kind of a Prince back home.
Nigeria used to be hundreds/thousands of separate kingdoms and many people have a claim to be chiefs/kings of those historic kingdoms. Male descendants of such leaders will claim the unofficial title of Prince. They may not have any real national standing but such leaders will be respected by their local communities.
It may look like one big country but there’s no official single royal family (unsurprising since it is a Republic). To give an idea of the diversity of Nigeria consider the fact that the country has over 500 native languages that are actively spoken.
Ohhh Nigerian Prince, I thought it was a wrapper for our Prince HTML to PDF formatter, but there is also a JavaScript implementation of Prince of Persia lol.
What is being benchmarked there anyway? Receiving a request from the underlying HTTP library, calling the user's handler function, and passing the response back to the HTTP library? Hono, Elysia, PrinceJS... all these "frameworks" really are just routers, and Bun comes with its own router.
No, you would be benchmarking the overhead of juggling several requests in flight, I/O and memory usage, which is what really distinguishes servers in terms of performance.
This is cool, and it's a really impressive feat especially for someone with relatively little experience due to your age.
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
I'll make sure to implement that
Great job with building and releasing a project. The API looks intuitive, almost the same as Express. Documentation site is good! The animated code blocks is nice on front page but too distracting in the docs itself, I think.
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!
Thank you boss
Hi! I'm a maintainer of Elysia, the framework you claim to have outperformed.
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!
wow the maintainer of elysia.
ummm i realized that. u guys are still up there but i am at top three. Just updated with oha :)
Nice work! Some notes:
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 :)
some more after reading the source:
- JWT needs to be validated, as it is, your implementation[1] happily accepts anything, you can impersonate anyone you want. I'd argue that it's a bad default choice too [2]
- baking-in resend.com as email provider is unlikely to be useful for most people
- x-forwarded-for [3] is only added by proxy servers, and will often not be present. This means you'll be applying a shared rate limit to most of your users
- the 'ai' helper is missing from the code. If this is vibe-coded, having tests for the examples will help keep it cohesive
Sorry if this is a lot, I hope it can help.
[1] https://github.com/MatthewTheCoder1218/princejs/blob/main/sr...
[2] https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba...
[3] https://github.com/MatthewTheCoder1218/princejs/blob/main/sr...
Ok thanks. The ai is missing cause I couldn't fully implement it and I didn't want it half baked so I just took it out.
Ok sure. And my Laptop is almost 8 yrs old so
Ok. Thanks you
Object.defineProperty on every request to set params / query / body is probably slower than regular property assignment.
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.
Considering this is barely any code at all I imagine it doesn't provide anywhere near the feature set other web frameworks do. Also there are no tests. How do you know it even works properly? Why would I trust that it works properly?
I do want to applaud your efforts, especially at your age. Add some tests, and keep making things :)
Ok bro thanks
Congrats! That's a sleek framework.
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.
Agree get rid of the character-by-character animation. It's very annoying.
Ok bro
this is pretty fun, slick to think you can do things like this now and it will be performant: https://github.com/MatthewTheCoder1218/princejs/blob/main/sr...
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).
I thought it was going to have something to do with this:
https://princejs.com/
Is from Nigeria
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!
Thanks bro
The name is interesting, considering it's created by a Nigerian.
This is really interesting, but I'd absolutely love if you could add a light theme to your website. I really can't read on a dark background, it kinda hurts my eyes and when I take my eyes off the screen I see a bunch of horizontal lines for a minute or so.
You asked. We delivered.
Next: tests + security fixes + reproducible benchmarks.
Thank you for making PrinceJS better.
— @Lil_Prince_1218 (13, Nigeria)
Ok bro
Congrats for the good and impressive work. You also implemented very fast the remarks like zod and not animated docs.
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 ?
sure
Rather than requests per second, I prefer 'clock cycles per request'.
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.
How do you measure it?
Ok I'll do that
I think you are misunderstanding "Type-safe"
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!!
My favourite question to ask when seeing benchmark results such as this is “how much latency did you have / inject when running the benchmark”. This tends to lead to interesting conversations and learning. :)
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.
i was initially confused how 19.2K rps is notable when Express typically benchmarks around 15K rps [1].
however, the author is benchmarking a route with an id param here, not a static route.
[1] https://github.com/uNetworking/uWebSockets/discussions/1415
The readme and stats remind me of VanillaJS, which should be a sign that you're not making a fair comparison here. Anyhow, I think this can be a very educational experience if you keep adding features and benchmarking — it'll get slower, but you'll know exactly why.
and im totally fair. I mean its not me that decide what the computer outputs sometimes when i run my code, mine is even bulkier than them
well i am still adding features. And thanks also
Here's the obligatory comment complimenting you on the project given your age too. It's certainly more advanced than anything I tried at that age.
An actual nigerian prince that's not a scam. LOL.
Congrats on this, keep building more stuff!
The github page claims "PrinceJS fits in a tweet," but also that it's 2.8kB after gzip compression.
Are tweets 2800 characters now? (Genuine question, I haven't used the place in years.
People with blue-check accounts get a 25000-char limit. Everyone else is at 280. Have had twitter/x aliased to localhost for a while now myself.
This is pretty impressive, wow! I always wanted to build a toy HTTP requests framework just to better understand the tools I’m working with, and here you are building the full thing.
Damn smart kid. You're going to have a bright future. Stay away from bad influences and you'll be a star.
Impressive stuff! I see you have contributions startins 2023, does that mean you started programming at 11?
At ten actually
Nice job building a thing and putting it out there. It's a great accomplishment.
Prince from Nigeria?
That's some incredible comedic insight for a 13yo.
At that age I couldn't even code. Keep it up, young man :)
Thanks boss
This is amazing! It does everything but make the jollof.
Will you bench against techempower benchmarks?
probably
Looks great.
However, there are no tests yet.
I'll make sure to add that's
Other than that, well done and keep it up.
Inspirational. Can you do a tutorial/blog post describing how it works and your thought process? I'd love to learn more about this kind of stuff.
Mighty impressive
I got emotional thinking about a 13 year old releasing this. No brutal feedback, just proud of you buddy. Keep it going!
Thanks bro
damn! you are just 13yo, impressive. Do you even play with other kids your age?
yh. only when im in school though. But not everyone gets me
I know it's intentional but very amusing name considering the country of origin.
It’s almost certainly not because of the advance fee scam.
You don’t have to meet many Nigerians before you find one that claims to be some kind of a Prince back home.
Nigeria used to be hundreds/thousands of separate kingdoms and many people have a claim to be chiefs/kings of those historic kingdoms. Male descendants of such leaders will claim the unofficial title of Prince. They may not have any real national standing but such leaders will be respected by their local communities.
It may look like one big country but there’s no official single royal family (unsurprising since it is a Republic). To give an idea of the diversity of Nigeria consider the fact that the country has over 500 native languages that are actively spoken.
I never knew of this bro.
Ohhh Nigerian Prince, I thought it was a wrapper for our Prince HTML to PDF formatter, but there is also a JavaScript implementation of Prince of Persia lol.
LoL
Why would you tree-shake your backend?
Any real world app is going to be waiting on, primarily, IO. These benchmarks that just hit an endpoint that returns a simple object are useless.
You would be otherwise just benchmarking the slow service if you benchmarked it any other way
What is being benchmarked there anyway? Receiving a request from the underlying HTTP library, calling the user's handler function, and passing the response back to the HTTP library? Hono, Elysia, PrinceJS... all these "frameworks" really are just routers, and Bun comes with its own router.
No, you would be benchmarking the overhead of juggling several requests in flight, I/O and memory usage, which is what really distinguishes servers in terms of performance.