Obviously it's up to everyone how they open source stuff, but I'm not necessarily sure that a massive blob of compiled code is the way to go: https://github.com/Shyam20001/rsjs

Fairly common pattern in NodeJS (to store binary blob in npmjs, not GitHub, but similar pattern anyhow) so you don't trigger builds on download.

Not saying it's the greatest idea, I despise it personally, but I do understand the motivation for it.

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.

Any developers worth their salt has build scripts turned off everywhere at this point, and manually build the packages they need it for, or manually whitelisted. It may save time, but as others mentioned, shipping binary blobs in a opaque way is a great way of making people avoid your project.

Just have a seamless process between author and user for signing and verifying builds.

Agree, would be nice. Feasible options available today?

Usually authors upload those to npm though, and ignore them in the git repository, hence you're getting questions about it.

So I guess the package `brahma-firelight` is the core idea behind this? But why in the repo[0], you uploaded those `.node` files instead of the source code + building scripts? Also your source code `brahma.js` looks like generated from `@napi-rs/cli`. Because recently I'm trying to build rolldown and next.js for msys2 platforms, and I'm certain this line[1] of code won't work in some cases.

[0] https://github.com/Shyam20001/rsjs

[1] https://github.com/Shyam20001/rsjs/blob/a226f62de039ebbd8da0...

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.

> Ideal for micro-service and API use-cases where speed matters

This is a wild mismatch from the HN title, this seems to be backend software?

I wish the author included examples of what it's like to write ReactJS in Rust. Can't get a good idea of how succinct or structured it is to write for example a button handler on an element from what's in the docs currently.

After looking through the author's post history, the title seems incorrect. This does not seem to be "ReactJS in Rust", but more something Express-like in Rust. They've been spamming this project over the past 50 days or so with different conflicting names, seemingly to try to gain traction[0].

[0](https://news.ycombinator.com/item?id=45745876)

I hate this with every fabric of my being.