HN user
Most of companies don't even know that node js npm packages has build scripts which do rely on python c++ build tools. That's y. This saves lots of time. Also binaries once checked and published cannot be edited in npm / all we can do is just remove that version fully if below 300 downloads.
Here you go for the core https://github.com/Shyam20001/brahma-core All npm packages including esbuild publish binaries node Js a Runtime not compiled one. So don't get into a judgement dude. Don't get blindly attached to the topics. Do check the Read Me before commenting.
Dude that's how ultra web sockets binaries are built. Node Js can run build scripts but it hurts the machine and requires appropriate node-gyp builds. Also the source to the code is here https://github.com/Shyam20001/brahma-core
Do refer the READ me for further information.
Tbh I just stole the deno's internal i/o code bases (tokio/hyper) just to make this framework to work faster performing against uws js. Do give a try and share your thoughts and feedbacks.
That's my fukin glue code https://github.com/Shyam20001/brahma-core check here
Every one need node so who gonna migrate all those legacy code bases to some other language just to get extra perf...?
Bro the source is locked and precompiled no body even the author cannot edit with malicious binaries. Thats y people used to publish binary to ensure stability. Instead of pulling from git each time.
Exactly I have attached the src link in Readme file. I'm maintaining independent sources and planning to build the same for python via maturin
That isn't dude not a vibe coded stuff. Its a complex architecture the src code is attached in Read Me file below do check.
If this succeeds then every node Js framework can use this adapter with memory safe ultra fast performance.
All I ever wanted is to make Js devs to write the same code atleast that would run on top of Rust.... A dirty Hack but Really Worth it...
Here you go https://web-frameworks-benchmark.netlify.app/result?f=hono-d...
Also regarding the performance its written using Rust and raw Hyper library unlike deno runtime no overhead coz I just build a complex rust native addon for node js that allows every one to harness the true power of Rust's Tokio and hyper.
Regarding hono it's my fav and edge based. The Framework I created allows you to run true multi thread Fullstack app on a instance like running raw c++ or golang frameworks. My framework gives you true parallelism without Node.js cluster. Just give a try.
I just created a open source Rust based JavaScript framework that allows every JS dev to write existing express js code that runs on Rust's Tokio and hyper.
I created Native Addon that let's you write Js code that runs on top of Rust’s Tokio runtime and hyper http library. Achieves massive throughput.
Brahma-firelight js is a brand new rust based JavaScript framework written using Rust's Tokio Runtime and Hyper http library. Upgrading node Js to next level beast.
Need suggestions and improvements for this project https://www.npmjs.com/package/brahma-firelight
No hate mate it's real that ai can really code anything u need but the brutal fact is you need to be much smarter to validate its code all I can see is skill and xp issue. But as Rust node Js dev I made ultra fast http framework using AI with just 200 lines of code it had beaten fastify hono and express. It's all possible just because of my xp in ffi and Rust with node js Architect lessons.
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.
``` 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
```
For reference, my test case: a 40MB XLSX with ~200k rows.
Parsing with this WASM build: ~16ms (on Chrome, M1 Mac).
Parsing with JS (SheetJS): seconds, often >5s, with UI stutter. So the speed difference is very noticeable on big files.
Curious if anyone here has even larger datasets to try!
Parsing .xlsx in JS with libraries like SheetJS often means:
Loading the whole 100 MB file into memory Blocking the main thread Tabs freezing, fans spinning xlsx-lite does it differently:
Streams ZIP entries (no inflate-to-Vec) Async + cooperative yielding — browser paints while parsing Batch-based parsing (rows in chunks) Memory stays flat, UI stays responsive
Glad you showed interest. It's addon that upgrades node js exiting http module to rust Tokio runtime. There fore all your http part will run in rust thread and you can define your Handlers in Js. It's for the people who crave speed. Give your self a try by
npm i brahma-firelight
Give a try and share your feed back..!! Will be sharing for react and vue ASAP.
Nice what's the main purpose of this?
I built Brahma-JS to bridge the gap between Rust's performance and the ease of JavaScript. It's an ultra-low latency runtime written in Rust on top of Tokio and Hyper.
The idea is to give developers a way to get Rust's speed and memory safety without having to rewrite their application logic. It's a plug-and-play engine that works across Node, Deno, and Bun.
All the heavy lifting—like parsing request bodies and headers—happens in Rust. The benchmarks are promising: on a tiny AWS t2.micro instance, I hit 33.2k requests per second during a load test.
I haven't shared the full codebase yet but will soon. You can find the repo here: