Good electron replacement should re-use your installed browser engine. That would reduce RAM consumption dramatically, while providing better security (because browsers usually update faster than individual apps).
There are a number of problems with locally-run websites.
One is that TLS is married to DNS, and no third-party CA would issue a certificate for localhost. TlS with self-signed certs generated on the spot becomes easy to forge.
Another is that no web browser suppoorts Unix domain sockets or a Windows equivalent as a an access protocol. You are stuck with IP-based access, wee above.
Third is that access to the OS is limited or forbidden inside the browser, for a good reason. Want to run a locally installed compiler from within your web IDE? Tough luck.
Electron solves all of these problems. It doesn't do it in the best way imaginable, but in some cases just a web site cannot be a replacement.
Depends, there is a bunch of Electron apps that work just fine as websites (e.g. Slack, Spotify, Microsoft Teams, etc. As far as I know). I personally prefer running those in a browser tab to both save resources and benefit from privacy enhancing tools like content blockers, etc. I would be curious to know how many of the Electron apps actually need these extra native APIs.
Some of those you listed have extra features with electron. I was just being sarcastic with my remark. Like I don’t believe you can screen share with slack via a browser for example.
> Like I don’t believe you can screen share with slack via a browser for example.
If you can't, it's not the browser's fault. I can definitely screen share in Jitsi from the browser, so there's no technical reason Slack shouldn't be able to do the same thing.
Well, There is Apache Cordova. Cordova uses built-in webview. It also support windows and mac, but it's not as popular as electron because its api is not as rich as electron.
Electron supports native V8 extensions that are really fast. Cordova (at the time I tried it) only supported message passing which is very slow. Sufficient for many applications but for some it won't cut it.
Windows has had that feature since at least IE5. The main drawback was that "installed browser engine" might in practice mean "whatever ancient IE version this user who disabled windows update is using". Of course that is now mostly solved, and e.g. iOS offers the same feature.
But if you want broad cross-platform support "just get the locally installed browser engine" suddenly becomes a hard problem, unless this becomes a popular OS feature.
Back in the Win98 days, I think a .hta (html application) was meant to be that - like .html but opens as an "application". Never really took off though, I presume due to lack of APIs at the time.
It had access to the full VBScript or JScript runtime and WScript host. This means you could do OLE Automation, filesystem access, network access, registry access, and I believe invoke processes.
At the same time, companies were locking down WScript due to scripting viruses and HTAs that were impersonating other applications with their configrable icons.
Removing the electron apps works well. Usually they have a browser version, and that's still dogshit slow, but at least it shares more resources and has better sandboxing.
