6 ms·

This is super cool. Are there any demonstrations comparing performance between electron and your app?

kusti8 8y ago
Currently no. That's one thing that I want to test sometime, but right now I'm busy improving it.
caspervonb 8y ago
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.
- zengid 8y ago
  >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 https://nodejs.org/api/n-api.html#n_api_n_api
  - parro-it 8y ago
    Some days ago I started a N-API version of the bindings: https://github.com/parro-it/libui-napi https://github.com/parro-it/libui-napi Is still really incomplete compared to libui-node, but just in case someone wants to help
    - zengid 8y ago
      Is it a pretty simple re-write or something that requires a lot of c wizardry?
      - parro-it 8y ago
        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.
        parro-it 8y ago
        FYI, I just wrote the comparison I was speaking above: https://github.com/parro-it/libui-napi/issues/11 https://github.com/parro-it/libui-napi/issues/11
        zengid 8y ago
        Pretty impressive results!
        parro-it 8y ago
        Yes, N-API seems to be superior. And it's a particular good fit because libui itself has a C API
wilonth 8y ago
I dont think that'd be very useful. Proton is pretty much native C with just a JS runtime on top, it might even be faster than Qt. So a benchmark against Qt maybe?
- jcelerier 8y ago
  Qt's event loop is much faster than node's though ; see for instance benchmarks of web servers using either : look at the scores of Cutelyst vs the score of Node servers here : https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=fortune https://www.techempower.com/benchmarks/#section=data-r15&hw=...

Currently no. That's one thing that I want to test sometime, but right now I'm busy improving it.

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.

zengid 8y ago
>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 https://nodejs.org/api/n-api.html#n_api_n_api
- parro-it 8y ago
  Some days ago I started a N-API version of the bindings: https://github.com/parro-it/libui-napi https://github.com/parro-it/libui-napi Is still really incomplete compared to libui-node, but just in case someone wants to help
  - zengid 8y ago
    Is it a pretty simple re-write or something that requires a lot of c wizardry?
    - parro-it 8y ago
      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.
      - parro-it 8y ago
        FYI, I just wrote the comparison I was speaking above: https://github.com/parro-it/libui-napi/issues/11 https://github.com/parro-it/libui-napi/issues/11
        zengid 8y ago
        Pretty impressive results!
        parro-it 8y ago
        Yes, N-API seems to be superior. And it's a particular good fit because libui itself has a C API

wilonth 8y ago

I dont think that'd be very useful. Proton is pretty much native C with just a JS runtime on top, it might even be faster than Qt. So a benchmark against Qt maybe?

jcelerier 8y ago
Qt's event loop is much faster than node's though ; see for instance benchmarks of web servers using either : look at the scores of Cutelyst vs the score of Node servers here : https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=fortune https://www.techempower.com/benchmarks/#section=data-r15&hw=...