Welcome to node-gtk discussions!

[romgrk]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[baybal]

Hi,

What about moving to es6 imports, and syntax? I can help you with that if agree to move.

[romgrk]

Qode is a lightly modified fork of Node.js that merges Node's event loop with Qt's event loop.

from https://github.com/nodegui/nodegui/blob/master/website/docs/guides/nodegui-architecture.md

Seems like they provide a modified Nodejs that merges the loops outside of the javascript context. That has advantages and disadvantages. One advantage is that they won't get weird corruptions of the async contexts, like when an async action is started before the GLib's loop is started but completes after. That either doesn't work, or crashes, or in some cases works, with node-gtk. Disadvantages: maintaining a fork of nodejs, plus incompatible native modules.

I'll repeat here the comment in src/loop.cc:

/* The way that this works is that we take uv's loop and nest it inside GLib's
 * mainloop, since nesting GLib inside uv seems to be fairly impossible until
 * either uv allows external sources to drive prepare/check, or until GLib
 * exposes an epoll fd to wait on... */

To work around those limitations, I've been thinking about using a monkey-patched libuv version. GLib seems too monumental to modify, libuv's code is fairly readable. Or maybe submit a patch to GLib based on previous work, but I'm not super confident on that one.

Edit: I'm gonna read up a bit on the Qode thing, maybe it's usable for node-gtk, as it allows injecting a custom event loop.

[baybal]

I also want to see how EFL manages to run its node bindings.

Second to that, throwing a hello to @bnoordhuis would be a good thing.

[romgrk]

What is EFL?

[baybal]

https://www.enlightenment.org/develop/legacy/tutorial/javascript_tutorial

[romgrk]

Their bindings seem to be here, but they're in beta state with no activity in 3 years. Their mainloop implementation seems fine but they're using their own event-loop, not GLib's, so they have more liberty to get it right (if they do get it right).

[baybal]

Saying ahead, named exports may require changing the naming convention a bit (you can't export 'require')

[guesant]

Hi! First of all thanks for this amazing project, I wish contribute with node-gtk sometime in the future. My question is:

With your experience with this project and the gobject-introspection world, which tips you can say me for create a gi-runtime for QuickJS?

QuickJS isn't that fast compared to v8 but it has a binary with less than 700 KB and a better memory usage for small projects compared to v8. Most of things I will need can be done with GLib and others libraries (already with gi bindings), so I suppose performance will not be an real issue.

gjs seems good, but I also want make builds for other architectures (aka Windows), and compile SpiderMonkey takes a lot of disk space.

[romgrk]

Hey,

re: contributing: awesome, I'd be happy to have help :)

re: QuickJS bindings: creating bindings is an ambitious project. The foundation seems easy enough, but the edge-cases are numerous and never ending. Would not recommend it unless you have a very clear use case. If you still wanna go this way, you need to read the code of other language bindings, such as node-gtk, gjs or pygobject, it's the only way you'll understand how to create your own. Documentation is an issue for the gnome ecosystem.

re: gjs: it's fine, but it doesn't use JS naming conventions and doesn't have access to NPM packages, so its attractiveness is quite low. I've never heard of it being used anywhere else than in the gnome desktop or for gnome desktop apps.