[HN Gopher] Show HN: PrinceJS - 19,200 req/s Bun framework in 2....
___________________________________________________________________
Show HN: PrinceJS - 19,200 req/s Bun framework in 2.8 kB (built by
a 13yo)
Hey HN, I'm 13, from Nigeria, and I just released PrinceJS -- the
fastest web framework for Bun right now. * 19,200 req/s (beats
Hono/Elysia/Express) * 2.8 kB gzipped * Tree-shakable (cache, AI,
email, cron, SSE, queue, test, static...) * Zero deps. Zero config.
Built in < 1 week. No team. Just me and Bun. Try it: `bun add
princejs` GitHub: https://github.com/MatthewTheCoder1218/princejs
Docs: https://princejs.vercel.app Brutal feedback welcome. What's
missing? - @Lil_Prince_1218
Author : lilprince1218
Score : 101 points
Date : 2025-11-17 19:45 UTC (3 hours ago)
(HTM) web link (princejs.vercel.app)
(TXT) w3m dump (princejs.vercel.app)
| waschl wrote:
| Mighty impressive
| yahoozoo wrote:
| 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.
| tayo42 wrote:
| You would be otherwise just benchmarking the slow service if
| you benchmarked it any other way
| koakuma-chan wrote:
| 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.
| ricardobeat wrote:
| 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.
| dlisboa wrote:
| I know it's intentional but very amusing name considering the
| country of origin.
| alexfoo wrote:
| 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.
| swiftcoder wrote:
| 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.
| jryan49 wrote:
| Agree get rid of the character-by-character animation. It's
| very annoying.
| Uptrenda wrote:
| Damn smart kid. You're going to have a bright future. Stay away
| from bad influences and you'll be a star.
| fwip wrote:
| 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.
| chuckadams wrote:
| 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.
| moralestapia wrote:
| An actual nigerian prince that's not a scam. LOL.
|
| Congrats on this, keep building more stuff!
| jryan49 wrote:
| 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?
| jryan49 wrote:
| I do want to applaud your efforts, especially at your age. Add
| some tests, and keep making things :)
| gwd wrote:
| I thought it was going to have something to do with this:
|
| https://princejs.com/
| lxe wrote:
| 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.
| jasonjmcghee wrote:
| Nice job building a thing and putting it out there. It's a great
| accomplishment.
| super256 wrote:
| At that age I couldn't even code. Keep it up, young man :)
| a-dub wrote:
| 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).
| lioeters wrote:
| 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!
| ramon156 wrote:
| Impressive stuff! I see you have contributions startins 2023,
| does that mean you started programming at 11?
| leeoniya wrote:
| 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
| bitwize wrote:
| 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!
| stevepotter wrote:
| I got emotional thinking about a 13 year old releasing this. No
| brutal feedback, just proud of you buddy. Keep it going!
| silvestreh wrote:
| 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.
| ricardobeat wrote:
| 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 :)
| ricardobeat wrote:
| 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...
| Alex_L_Wood wrote:
| 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.
| altmind wrote:
| Will you bench against techempower benchmarks?
| mikeday wrote:
| 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.
| mpeg wrote:
| 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
| londons_explore wrote:
| 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.
| stevage wrote:
| How do you measure it?
| jeremy_su wrote:
| 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.
___________________________________________________________________
(page generated 2025-11-17 23:00 UTC)