NeutralinoJS

[Pakrohk]

MOD EDIT: This was originally a feature request. However, it fits more to Discussions as it is more a request of rewritting the entire app to completely different framework and a bit more serious change that has to be deeply discussed, unlike to feature requests. It is also probably controversial in some way, since there's a lot of other frameworks, some even advertise to solve issues NeutralinoJS has.

Is your feature request related to a problem? Please describe.

Problems that electron has with Gnu platform unix/linux systems + incompatibility with Wayland

Describe the solution you'd like
I'm not looking for a solution, I'm looking for your help, I know the development of the project has been temporarily stopped, but the question I have is this.
Can you guide me to transfer the project to Neutralinojs ?

Describe alternatives you've considered
In Electron and NWjs, you have to install NodeJs and hundreds of dependency libraries. Embedded Chromium and Node make simple apps bloaty. Neutralinojs offers a lightweight and portable SDK which is an alternative for Electron and NW.js. Neutralinojs doesn't bundle Chromium and uses the existing web browser library in the operating system (Eg: gtk-webkit2 on Linux). Neutralinojs implements a WebSocket connection for native operations and embeds a static web server to serve the web content. Also, it offers a built-in JavaScript client library for developers.

[SpacingBat3]

@ALipAkrohk Thank you for your suggestions, but I'm aware NeutralinoJS is not a proper framework for WebCord project.

So, here's are my reasons against Neutralino:

• For some time, it lacked ARM support, unlike to the Electron. This was the first major reason why it wasn't appropriate.
• It lacks Node support. To compare their own API with Node, it is like comparing an Electron API with Node: both of these serves different purposes. To be more clear, I'm not sure if Neutralino would have in its API a such WebSocket implementation that could work alongside the WebSocket or even has a UNIX socket implementation for IPC feature. A lack of alternative to modules which WebCord uses will also make it a bit more problematic.
• First of all, does NeutralinoJS support WebRTC at all? I've heard of similar project to it (also using the WebKit) but with Node support and it had some issues with WebRTC not being a thing in Chromium.
• There's no truly native web browser library implementation. gtk-webkit2 on Linux is not really native for another window rendering library like QT or infamous TK. Ideally, such software would need to have different versions for each of the libraries. Moreover, similar situation is with Windows where Edge WebView is not that much native as well, considering older Windows versions don't include Edge or the one could de-bloat their Windows and do complete Edge removal.
• Discord is mostly designed for Chromium (at least they give a better support for it AFAIK and might work on bugs if they can be solved on their side), which makes more sense to develop an Electron client for it. I also spoof WebCord as Chromium for this reason, it can't be so easily distinguished then as it uses Chromium under the hood. That wouldn't be possible to achieve with any other browser, since they render stuff a bit differently and that difference can be detected by fingerprinting scripts (sure, WebCord blocks them but that doesn't mean you're safe – Discord could integrate those in their internals, so there would be no easy way to block this). And Electron ≠ Chromium (at least a bit), they actually remove a lot of stuff from the engine, mostly stuff not appropriate for all web apps like chrome APIs that can be found in the extensions (which is the reason why Electron devs had to reimplement it, at least from what I know). I'm not quite sure how it is with WebKit browsers, but as Safari (default browser on macs) is based on that I guess they have no choice but to support it?

---

However, I'm still thinking about moving from Electron to completely different framework – but instead of WebKit, I would prefer more Gecko for that purpose (a lot of people use Firefox, so it makes sense to use that engine). On the other hand, there's no much alternatives there for Electron as well, I've heard of qbrt but it doesn't look to be enough to move to it (it's still experimental and probably lacks the APIs I would need). I've also heard recently Gecko doesn't look like a better choice for ARM users (and WebKit might not be as well) in case of the performance. But maybe in the future I could consider doing some work with Rust and maybe even to switch to Servo if it will get stable or maybe we will get a framework based on Gecko and Gecko/Firefox will improve in case of the ARM devices performance. Since Rust is a bit low-level language, stuff there could be much more performant but that definitely would need a lot more time to implement and maintain.

[Pakrohk]

You gave me really interesting words and information, thank you, it was great
But maybe if we want to find an alternative to Electron despite the current problems and maintaining WebKit, Tauri is the best possible option.

[SpacingBat3]

@ALipAkrohk, there was a discussion on that as well:

#181

This is actually a framework I've mentioned in my answer:

I've heard of similar project to it (also using the WebKit) but with Node support and it had some issues with WebRTC not being a thing in Chromium.

[SpacingBat3]

And to reply to this:

I'm not looking for a solution, I'm looking for your help, I know the development of the project has been temporarily stopped, but the question I have is this.
Can you guide me to transfer the project to Neutralinojs?

I doubt you can transfer WebCord to NeutralinoJS that easily. You would have to completely rewrite WebCord (or whatever you want to call it) for it, since it is deeply integrated with both Node and Electron. There're however other frameworks discussed on GitHub Discussions that use both WebKit and integrates with Node, so you might consider doing that. This also will make it a bit more problematic:

(...) embeds a static web server to serve the web content.

You see, Discord by itself implements a kind of web server with the REST API, on which WebSocket is also being built. Both of these are used for a communication with the web version of Discord, so you can e.g. authenticate Discord if you're logged in browser or redirect some stuff directly into the browser. This could also be possible to be implemented in WebCord and was actually partially done in socket.ts. I also have plans for IPC reimplementation and a support for the authorization in the future, but I'll need to find out if that'll be possible via the web requests (there's a page in Discord that implements a GUI for AUTHORIZATION requests, the one actually used for bots; I wonder if it would be possible to use that directly in WebCord with the WebSocket to pass these requests to this page – I think that could make some features possible, maybe like StreamKit integration or RPC but I'll investigate on that in the future). If you're curious, the entire API for RTC and app authorization is actually documented well by Discord itself here for WebSocket (IPC will have similar requests, but it has to be differently implemented on WebCord side).