Node is actually the worst case here: V8 being in C++ makes this harder than Ruby or Python, being implemented in C.
The line you cited is automatically locating the .node file, loading it, and returning the module object associated with it.
On IRC a couple people have been questioning this part of the API, suggesting that just using the standard npm module `bindings` might be better. It's a reasonable idea and I'll probably open a discussion in a GitHub issue.
My question is/was, given two or more modules written in Rust, how do I address and require them by name? Due to its naming I assumed "neon-bridge" would be the glue that handles this. Given the fact that you can require .node files directly, it was not clear to me that "neon-bridge" is just the name of an example module (or is it?).
So neon-bridge is a utility npm package I published that automates loading your Neon project (so it's not the name of an example module). And the expectation is that you only have one Rust package ("crate" in Rust parlance) per Node package, which is why you don't need to pass it the name of anything -- it's looking for _the_ native module in the package, as opposed to _a_ native module.
However, that single Rust crate may have multiple modules in its implementation. They live in the src/ directory of your Neon project and are picked up by the Rust compiler and build tool.
And yes, deeeeefinitely need to get some docs going... :P
- There may be JS libraries you want to use.
I could go on.
What would be the reason to do that?
- DOM manipulation for AJAX states so they can be reached directly from the server without needing client side JS to do anything
- Calculate discounts for products (obviously clients just POST the product they want, but the discounts should be applied on the server consistently to how they were shown to the user)
- Your code is something generic, like recursively checking for a keypath on an object, and totally useful for JS anywhere it runs.
All kinds of other reasons.
It also enabled me to move functionality freely around.
Calculating report data on the front-end, so it gets ready tomorrow and later moving it into the back-end, for performance reasons.
I think that the situation is a lot better than that site indicates.
Passing off to rust? Count me in! I'll be taking a look at this when linux is supported (would also love windows support but mac os x and linux are necessary for me).
> I'll be taking a look at this when linux is supported
Damn people work fast. I hadn't even looked into what it would take to support Linux (and honestly my rust knowledge at the moment is so limited I probably wouldn't have figured it out in a reasonable time frame).
Rather than trying to go whole-hog on linking the two worlds together at a process level, I've just embedded an Erlang release into the Electron package, which decompresses itself to the user's Library/APPDATA dir on Electron startup, transparently registers as a service (so it can continue to run for things like server sync when the app is quit), and then communicates with the app using Unix domain sockets.
It's a bit like the feeling of having a Service Worker, but one that just happens to be able to embed things like physics engines inside of it.
It made it out into the regular release and I think it's fixed but TBH I haven't tested for a few months.
My work is all on GH here as well: https://github.com/orbitaljs There might be some synergy here between the projects.
line.split(' ').filter(|word| matches(word, search)).count()
node-ffi seems to be for adding a bridge between an existing non-Node module dynamic library and node, which at the very least seems to incur some non-negligible overhead; see the "Call Overhead" section of your link.
Also, can I use Neon for async callbacks?
The possibilities of rustc (which has an LLVM backend) and Emscripten (which consumes LLVM IR) are really interesting.
Always bet on JS!
But that uses a shell command. There's also this way to do so using FFI (article is about C++, but I'm pretty sure you could do the same with Rust):