It’s been a long time since 2023, when Bun.js arrived and disrupted the JavaScript world. During that time, I was working on something unusual—something that encourages all JS developers to write API code that actually runs on top of Rust.
I gave it my best and eventually published this framework on npm. Many people asked for async support, and after countless sleepless nights, I finally achieved it. Meet Brahma-JS (brahma-firelight) one of my finest creations that replaces Node.js tcp / http module with Rust’s Tokio and Hyper library inspired from Deno runtime. Also I tested against the fastest rust frame work may-mini-http.
May-MiniHTTP Benchmarks
Running 10s test @ http://127.0.0.1:8080/
1 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.70ms 812.42us 20.17ms 97.94%
Req/Sec 117.65k 7.52k 123.40k 88.00%
1171118 requests in 10.08s, 115.04MB read
Requests/sec: 116181.73
Transfer/sec: 11.41MB
Brahma-JS Benchmarks
Running 10s test @ [http://127.0.0.1:2000/hi](http://127.0.0.1:2000/hi)
1 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.51ms 479.16us 7.89ms 78.17%
Req/Sec 131.57k 9.13k 146.78k 79.00%
1309338 requests in 10.00s, 186.05MB read
Requests/sec: 130899.58
Transfer/sec: 18.60MB
Oh sure, just another framework casually doing 130k+ requests/sec. No big deal. Totally normal. Definitely not powered by a Rust beast disguised as friendly JavaScript.
Now I have released v1.5 A stable release with support for Mac, Linux and Windows too. You can give a try by starting
npm i brahma-firelight
If you find this framework useful plz do share your thoughts and feedbacks.
How much overhead does a simple request handler have with Brhama and with Express in ms?
It matters because most of my endpoints are IO heavy. I assume the framework cost is negligible compared to that, and if it is negligible for typical use-case, then what use-cases do you see where it matters most?
If you take any Node.js framework like Express, Fastify, or Hono, they run on a single core by default. That’s the biggest overhead unless you explicitly use clustering.
BrahmaJS, on the other hand, provides upgraded I/O and TCP modules built on top of Rust’s Tokio runtime, which is far more efficient than Node.js. By default, BrahmaJS runs in a multithreaded mode, utilizing all available CPU cores without needing Node.js clustering.
Another key advantage is that heavy tasks like body parsing are handled by Hyper. This means your Node.js handlers receive a cleaned request and you can simply return your response using async/await.
The only overhead comes from the N-API thread-safe function, which manages data transfer between the Node.js world and the Rust world—but this overhead is minimal.
Since all your endpoints are io heavy brahma Js can offer you quick body parsing and micro milliseconds perf compared to express undoubtebly.