A lot of these are essentially the same as web views: just the app’s browser tab in its own app. I don’t see the point.
There are a bunch of APIs which aren’t exposed to browser windows.
Electron lets what is essentially the same html page have access to APIs which it would otherwise not be able to.
Whether that’s a good thing or not is arguable, but it’s clearly desirable to the people writing these things.
And every single one of these I have used is a notorious resource hog and has UI that is simultaniously clunky yet feature-light. This is a like a gallery of reasions not to use Electron.
Also, [META]: there isn’t a single mention of Android in the article; why is it tagged as such?
A big negative comment I often see about Electron is the fact that each app runs its own JS engine under the hood. For each applications. Are there any attempts to break that out of the final executable and make it a single server on the client? Kind of like the JVM?
Chromium runs separate V8 processes for each origin for security anyway.
I feel like I knew that about Chromium and totally forgot it. I guess the way JS was developed it doesn’t actually make any sense to run a single V8 process for multiple Electron apps.
One could argue that a single electron install shared by different apps could save memory because the text segments would only be mapped once, but that ship has sailed. Shared libraries are dead. Apps ship their own copies of everything.
This is specially interesting considering that with little effort other languages can be integrated with electron. So, in theory somebody would only need to compile for the different platforms the executable (in other language) and add it the corresponding distributable from electron for each platform.
I was watching this meetup from somebody ate WagonHQ https://youtu.be/mUAu7lcgYWE. I’m gonna try to create something