Hacker News Reader

Comment by caspervonb | Hacker News Reader

It seems to runs on "UI" from andlabs, which is a fairly lightweight C wrapper around the the Windows, Cocoa and Gtk API's.

Sidenote as for why a UI library would wrap another UI wrapping library, Gtk is what is considered "native" on Gnome based distros.

So weight-wise, it's basically comes at the cost of native node module which is not bad compared to Electron's crazy IPC bridge back and forth communication nonsense.

View on HN

>So weight-wise, it's basically comes at the cost of native node module

And now with NAPI [1] it should be easier than ever to make node modules!

[1] https://nodejs.org/api/n-api.html#n_api_n_api

Some days ago I started a N-API version of the bindings: https://github.com/parro-it/libui-napi

Is still really incomplete compared to libui-node, but just in case someone wants to help

Is it a pretty simple re-write or something that requires a lot of c wizardry?

Not a simple rewrite, but neither a task that require a C wizard... The current version of libui-node implements C++ classes that wraps libui C function. They are exposed directly to JS. This experiment implements N-API C functions that wraps libui C function. Then, a set of JS classes wrap them, offering the same public API as libui-node.

Currently, I implemented windows, boxes, and multiline entry. I have to compare this experiment with the curent implementation in terms of erformance, memory consuption etc. before to decide to continue with N-API or not.

FYI, I just wrote the comparison I was speaking above: https://github.com/parro-it/libui-napi/issues/11

Pretty impressive results!

Yes, N-API seems to be superior. And it's a particular good fit because libui itself has a C API

Reply on news.ycombinator.com