Question: What you think about a port to Gjs?

[JumpLink]

Background
I am thinking about developing a framework for GJS. So far it's just ideas and nothing concrete, because I want to improve ts-for-gir first, because the framework should make a lot of use of Typescript.

In the framework I would also like to implement some web standards, so that these can be used in GJS similar like I can do in the browser or in Deno. With the hope that then some libraries for the browser or Deno can be used in Gjs.

Now your project implements such a standard and that is the WebRTC Javascript API, nut for Node.js and not for GJS. But you use the GObject Introspection Repository using node-gtk, so it should not be too difficult to port your codebase to Gjs.

Question
My question now is: What do you think about my idea, would you also be interested in it and what do you think how far is your project to be able to port basic functions to Gjs. Possibly we can then also benefit from each other.

Regardless, this is a cool project, I'm excited to see how it turns out :)

[peat-psuwit]

My end goal for this library is to be compatible with e.g. lib-jitsi-meet, to allow creating desktop applications which connect to existing websites, but using Gstreamer to tap into HW acceleration potential. I understand that would require a significant amount of Web APIs support anyway, which is the reason I based this library on NodeJS.

Now, if this library is to be ported to Gjs, a few things has to be done. The library uses Node-specific APIs in a few places (e.g. setImmediate(), Buffer.byteLength(). I guess we can find replacements for these in GLib.

A more interesting thing is how to translate between node-gtk's and Gjs' style of members. You see, node-gtk uses camelCase, while Gjs uses snake_case. I don't want to have 2 versions of the code for 2 environments, and so I'm not sure if there's a good solution.

I'm not sure what you mean by "how far is your project to be able to port basic functions to Gjs". At the moment the library is missing main features (e.g. it still can't send streams), and so I guess this thing is still pre-alpha state. Sadly, I don't have much time to continue the development - I have to put an emphasis on Ubuntu Touch first, as you might or might not know.

Overall, having this library in Gjs environment too is an interesting idea. However, I'm not sure how realistic that is.

[JumpLink]

Thank you your answer has already answered some of my questions. I could create a fork for Gjs and maintain it, then you do not need to maintain two code bases and the option to merge the whole thing again still exists. But before I start, however, I am still busy with other things and just wanted to ask what your attitude to my idea is.

Iit would help if we could implement and have the same or very similar tests. Since not all frameworks work with Gjs it would be good to use something simple. Gjs itself uses a port from Jasmin so I think it would be the best to use Jasmin for tests, how I can port this then to Gjs I will see then.

It would be really great if you could get a desktop version of Jitsi Meet running with it, Ubuntu Touch and other mobile Linux distributions could certainly benefit from this as well. I will continue to watch this anxiously.