Precompiled binaries

[mischnic]

... would shorten install time drastically.

[parro-it]

I think I can reuse part of the configuration I wrote to compile libui binaries on travis & appveyor.

[mischnic]

How would different node versions get handled?

[parro-it]

How would different node versions get handled?

I'll install (or hopefully it's already installed) nvm and I'll use that to switch node version and build binaries on every version of the node API we support.

I think there are some tools that can help in the process...

New node versions will be included as they are published, we'll have to trigger the CI build doing some commits...

[mischnic]

N-API (pronounced N as in the letter, followed by API) is an API for building native Addons. It is independent from the underlying JavaScript runtime (ex V8) and is maintained as part of Node.js itself. This API will be Application Binary Interface (ABI) stable across versions of Node.js. It is intended to insulate Addons from changes in the underlying JavaScript engine and allow modules compiled for one version to run on later versions of Node.js without recompilation. (https://nodejs.org/api/n-api.html)

Not sure if nbind allows that or how N-API is supported by older node versions.

[parro-it]

Yes, that would be awesome because it would solve the node version problem, but nbind unfortunately does not support it. We can try to ask for the feature, but I think it would be really a big job.

Also, I started months ago to do some experiments building a tool similar to nbind but that uses NAPI instead of NAN. But the tool is very rough ATM. If you want to give it a look, I can add you to the private repo where I'm keeping it.

This tool could probably be simplified by only implement features needed by libui-node.

Another advantage (but that will add even more work to do) is that using N-API allows to bind directly to C functions, so we can avoid the C++ wrappers at all, and implement a public API directly in JavaScript.

[mischnic]

Related: parro-it/libui-download#3

[parro-it]

I start to experiment with a N-API version of the library here: https://github.com/parro-it/libui-napi

There, I setup prebuilt binaries using Travis & AppVeyor. You could see a first release on the repo.
If you try to install the package, the binaries get download and they should not be compiled every time. The same binaries works on Node 9 & 10, and I tested them only on macOS High Sierra.

There is still a problem on CI: when you push a new tag, the publish phase is triggered, and if the build for other commits trigger to early, it try to download partially built binaries and fails.

I'm also rewriting documentation using same tools as proton-native, and add tests using screenshot-tester.

The idea is to continue the experiment implementing windows, multiline entries and boxes,
and then compare this version with a stripped down version of libui-node that only implement the same widgets. I'll compare them based on:

1. compilation speed
2. binaries size
3. memory consumption
4. easy of development

Until now, I already find some benefits of using N-API

• Compilation is really fast.
• We have full control on memory management.

[mischnic]

The same binaries works on Node 9 & 10, and I tested them only on macOS High Sierra.

Also node 8 & Sierra!