A firewall with a configuration interface running on Electron, just like the horrid free AV solutions for Windows back in the day :) Can't be too critical of that because the developers have already expressed their dislike of Electron on the website, and it makes sense that they won't drop everything for a huge UI rewrite.
This entire thing seems incredibly polished, I'm surprised I haven't heard of this before. For every question and potential limitation for my use cases there seems to be an explanation on their FAQ. I'm definitely going to take this for a spin! Too bad there's no AUR package ready to go yet because I don't really want the burden of updating manually, but all in good time I suppose.
What kind of features of electron are you using in the UI?
If it's only http/websockets and the UI, you could try webkit2gtk or other alternatives. It's actually quite easy to build a gjs or Qt wrapper on Linux. WebKit(Legacy) from webkitgtk also builds on Windows.
I am currently in the process of making WebKit into a webview that only includes websockets as an API, so the long term goal is to have a minimalistic webview that doesnt have everything that a browser has. [1]
Maybe it makes sense to combine development efforts?
We mainly use http/websockets, but have also started using a feature that will give us the application icon of an executable on Windows.
We've previously used the webview lib [0] and we will look into it again, as they now support Microsoft's new Edge webview.
It's a C and Golang library.
retrokit definitely looks interesting, can you elaborate on the additional value provided in regards to a simple webview? I just saw that your use case is using it for a full browser.
We use a strict CSP for the UI, which works pretty well.
A collaboration sounds interesting, but as we are still bootstrapping, it will take some time until we'd have the resources to do that.
> can you elaborate on the additional value provided in regards to a simple webview?
The proposed value of retrokit (when it's more progressed) is a much smaller library/file size and the reduction of a potential attack surface in regards to fingerprinting, privacy and security.
Legacy encryption APIs that are outdated, Plugin APIs that are from the Netscape-era, "navigator.plugins" and old stuff that's not actually providing any value anymore is being removed as well - due to the history of e.g. PDF files or Java applets being such an oftentimes exploited plugin.
The idea is to have a webview that's focussing on the rendering part + websockets for local interprocess or webapp-to-webserver communication. At a later point in time my goal is to bundle it with nodejs, with the idea being that the "local backend" in nodejs allows all the flexibility you need to port networking and OS interactions; and the webapp representing the UI process that's separated (from a security perspective).
This would be a great base for a secure browser, which is something we are interested in long-term.
Maybe we can have a chat about a possible future partnership?
We won't be able to support such an initiative at the moment, but we are definitely interesting in investing in that area at some point in the future.
Please also publish a version that does not auto update. The aur package for google-chrome-stable does not allow in app updates, for I g the system to choose. This choice should not be taken away.
Here's my take on Electron and anything else resource-intensive: if your UI is either short-lived (like a configuration window) or the main thing you're using (like an IDE), I don't really care how much RAM or anything else it uses.
A firewall configuration windows falls in the first category - you only open it very occasionally and for not very long, so it doesn't really matter how heavy it is. Where Electron (or similar) is really bad are things like Discord, Slack, Spotify, Teams, etc. where you'll likely be running many of them all the time, while you're doing other things that need those resources.
This entire thing seems incredibly polished, I'm surprised I haven't heard of this before. For every question and potential limitation for my use cases there seems to be an explanation on their FAQ. I'm definitely going to take this for a spin! Too bad there's no AUR package ready to go yet because I don't really want the burden of updating manually, but all in good time I suppose.