I guess the main difference isn't pointed out anywhere. When targeting Node.js or Electron, C++ code using nbind is compiled to native with your typical GCC, Clang or Visual Studio 2015. Node.js then loads it as a dynamically linked library. Electron is particularly interesting, since it's like a Chrome web browser with the Node.js API, so a web app running in it can call native Node.js plugins directly. The C++ code should run about twice as fast as in the browser, since there's no asm.js in between, and it can allocate at least several gigabytes of memory if needed.
The goal of nbind is that you write C++ libraries and JavaScript apps using them, and they run with the fastest technology the platform will permit, whether it's a browser or not. I'm looking for help to implement this on mobile too, since asm.js is not so fast there. I'd like to write a responsive UI once in TypeScript and the heavy lifting in C++ as natively as possible. nbind then binds them together on all platforms without boilerplate or repetitive code. A user could try out the Emscripten version of an app in the browser and if they like it, download the desktop or mobile app to make it run faster and do things that use a lot more RAM. The programmer shouldn't need to do any additional work to allow this. maanantai 7. syyskuuta 2015 8.03.16 UTC+3 Juha Järvi kirjoitti: > > The goals are a bit different. nbind targets Node.js and Emscripten with > the same syntax, but Node.js bindings only need a C++ interface directly > manipulating JavaScript types. It can be initialized only after Node.js > calls an init function but the binding definitions run from constructors of > static variables before that, so it needs to store the bindings in the C++ > heap for a while. That makes the architecture quite different. > > Unlike embind, nbind won't do run-type type checking on the browser. On > Node.js it's necessary to avoid crashing the engine, but on the browser > nbind can't do anything more dangerous than plain JavaScript could. > Instead, nbind will eventually automatically generate TypeScript definition > files for compile-time type checking also the JavaScript code. Once the > JavaScript code is verified correct, there's no need for run-time checks. > > Node.js could run destructors automatically during garbage collection, but > browsers don't support that, so nbind can't do anything about it. > > In nbind, value objects are instances of a class on both C++ and > JavaScript sides. I suspect that may make them faster because the > JavaScript engine knows their structure instead of treating them as general > hash tables, but that remains to be seen. It's also possible to call > methods on the object without first having to convert between the value > type and another JavaScript type. > > Since the JavaScript class only needs a "fromJS" function added to support > this (and a toJS method in the equivalent C++ class, which calls the > JavaScript object's constructor through a callback), you can take any third > party JavaScript library and add nbind support to its types without > modifying its code, by just adding a single method to each desired type's > prototype. Your own C++ class doesn't have to have the exact same structure > either, as long as you can perform the necessary conversions in toJS and > fromJS. > > nbind supports calling C++ code with a JavaScript function as a callback. > By default, the callback gets invalidated when the C++ function returns so > there should be no lifetime issues. This allows easily creating forEach > style methods for C++ data structures. There might later be support for > "persisting" the pointer to a JavaScript function and keeping it around for > longer on the C++ side. > > There's gyp-based tooling available for nbind that allows defining > required npm packages (that are compatible with nbind, currently only nan) > and have their include paths and source files automatically passed to the > compiler, somewhat like pkg-config on Linux. It remains to be seen how this > will work with the Emscripten target. > > Some embind features are not yet even planned in nbind, such as > allow_subclass() and emval. > > torstai 3. syyskuuta 2015 16.44.44 UTC+3 jj kirjoitti: >> >> Very interesting! >> >> Skimming through the examples, I'm trying to understand what makes this >> different than embind? What kind of C++ class features are you planning to >> support? >> >> I was testing out embind a few years back with the idea of exposing >> MathGeoLib ( http://clb.demon.fi/MathGeoLib/nightly/ ) as a JavaScript >> API. Here is a live demo of that test: >> https://dl.dropboxusercontent.com/u/40949268/emcc/MathGeoLibTest.html >> <https://www.google.com/url?q=https%3A%2F%2Fdl.dropboxusercontent.com%2Fu%2F40949268%2Femcc%2FMathGeoLibTest.html&sa=D&sntz=1&usg=AFQjCNGb_VsQFlFOH-2ZojQUhVSeCFMPPw> >> >> . In that test, I found that value types were a bit difficult to emulate >> cleanly without support for destructors. Btw, if you haven't seen, we have >> a list of embind-related threads at >> https://github.com/kripken/emscripten/labels/embind , I wonder if nbind >> might be able to work on some of those? >> >> 2015-08-31 4:38 GMT+03:00 Juha Järvi <[email protected]>: >> >>> If you like embind, here's the equivalent for Node.js and the Electron >>> framework: >>> >>> https://github.com/charto/nbind >>> >>> It even supports callbacks and value types, but the syntax is a little >>> different from embind, with even less typing. Value objects aren't passed >>> as object literals, but instead they're always initialized through a C++ or >>> JavaScript constructor as they pass between the languages. >>> >>> The next goal is to make it support Emscripten (wrapping embind or >>> otherwise) and automatically produce TypeScript definitions, to allow >>> running a single C++ code base natively on the server (Node.js) and the >>> desktop (Electron) or through Asm.js on browsers (and maybe as a fallback >>> on server and desktop). Unfortunately supporting native mobile with Cordova >>> seems more complicated... Also, here's an article about creating Emscripten >>> libraries in TypeScript: >>> http://blog.charto.net/asm-js/Writing-Emscripten-libraries-in-TypeScript/ >>> >>> Bindings with nbind for a coordinate pair might look like: >>> >>> NBIND_CLASS(Coord) { >>> construct<>(); >>> construct<int, int>(); >>> >>> getset(getX, setX); >>> // etc. >>> >>> method(callWithXY); >>> } >>> >>> >>> To be used from JavaScript as follows: >>> >>> var nbind = require('nbind'); >>> >>> nbind.init(__dirname); >>> >>> var xy = new nbind.module.Coord(12, 34); >>> >>> xy.x = 56; >>> >>> >>> >>> // Prints: 56 34 >>> >>> xy.callWithXY(function(x, y) { console.log(x + ' ' + y); }); >>> >>> >>> >>> The class might be defined as: >>> >>> class Coord { >>> public: >>> >>> Coord(int x = 0, int y = 0) : x(x), y(y) {} >>> >>> int getX() { return(x); } >>> void setX(int xNew) { x = xNew; } >>> >>> // Call a JavaScript callback with x, y as parameters. >>> void callWithXY(nbind::cbFunction &callback) { callback(x, y); } >>> >>> // And others... >>> >>> int x, y; >>> }; >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
