Are there any projects concerning providing an OS bundled electron that apps can use instead of each app having to run its own? It would be nice in reducing the overhead but I don't know if something like that could even be implemented, or that devs would even use it.
People have tried, but the devs don't use it, because when you use an OS-provided WebView, you have to support way more browsers (and substantially older browsers) than you do if you just ship your own browser runtime.
On Windows, if you use an OS WebView, you'll have to support IE11 on Windows 7. On Windows 10, you'll get whatever random version of Edge was installed, or the new Chromium-based Edge.
On macOS, you'll have to support whatever version of Safari was installed on the user's Mac, which is better than IE11, but it could still be years out of date.
You might say, "Who cares? I have to support old browsers on my website, too" but this is way worse, forcing you to support browser versions you rarely see on the web. Windows 7 users typically just install the latest Chrome/Firefox and run that rather than surfing the web in IE11, but when you rely on the OS-bundled browser, all of your Win7 users will be on IE11. Your IE11 support can't be an "acceptable fallback"; it's the only/primary experience.
With Electron, you can ensure that your app will use Chromium; the exact version of Chromium you provided in your installer.
FWIW, Microsoft plans to ship a new "WebView 2" that will let you provide your own Chromium or depend on the latest Edge Chromium, with support all the way back to Windows 7. https://docs.microsoft.com/en-us/microsoft-edge/webview2/
That's cool for Windows, but macOS is still just gonna give you whatever version of Safari the user has installed, and if you want Linux support, you really have no better option than to ship a browser runtime like Electron.
But, at that point, if you've shipped an Electron app for macOS and Linux, maybe you just wanna ship an Electron app for Windows and call it a day?
AFAICT, This has been discussed in the past [0] and Electron doesn't have a stable runtime for developers to program against unlike the JRE, etc. You could try to do that at least on macOS, by moving the Electron.framework library in /Library/Frameworks and see if it will run. Some will, some won't. I won't be surprised if it doesn't work.
The problem is that the Electron API changes rapidly, such that you'd really want to run each app against the Electron release it was developed against, and Electron releases so often that you're not going to actually save any disk space this way -- you'll just have N "system" Electron versions per N apps.
From a developer-perspective this would be a big problem, because you are now depending on an external process outside your control, which in worst case can force you to become active on short notice.
Electron at the moment is just not stable enough for this IMHO. You need to have at least a certainty of that your app would be runnnable for 5-10 years without demand for updates from you, before a developer should seriously consider this.
Though, from a user-perspective this of course is desirable. Thouhg, how big is the overhead even that could be reduced that way?
Actually, I read a rumor somewhere that was planned for Windows 10 as part of UWP, which already supports JS apps.
They've already gone fairly far in integrating PWAs with the new Edgeium, so we'll see where this goes. (Your installed PWAs appear in the control panel for uninstallation, for example, which even Chrome doesn't do yet.)
I wouldn’t be super surprised if this was on the Chromium / Chrome OS roadmap. I might vaguely remember hear something about this a year or two ago in a podcast with a chromium developer, but I could be wrong :P
I would love to have framework de-duplication work this way:
- Each app ships with its own copy of the framework at a particular version. This ensures that apps can be installed offline, just as before.
- When running the app for the first time, the OS moves the framework to a centrally-managed location. The new paths are assigned in a way that both preserves both the version names and prevents collisions of frameworks with the same name but that actually have different contents. For example, a version of Electron could be moved to /Library/SharedFrameworks/Electron/9.0.0-1234abc. This change alone makes it such that two apps using identical versions of a framework can share resources.
- Each time the app runs, it tells the OS which version of the framework it's using. For apps that don't want to do anything fancy, this will simply be the version of the framework it shipped with, and the OS should take this to be the default for legacy apps. The key here is to be conservative -- the default setting should absolutely not cause more points of failure than if we didn't have this system.
- But if apps want to do more deduplication and take advantage of extra features of newer versions of the framework that other apps might have installed on the system, they can do that.
- Note: I think it's preferable to have an API that allows the app to request other versions of the framework, rather having the app specify a static dependency range. You don't know how apps might go about checking whether a newer version of a framework is safe to use. For example, maybe the developer wants the app to potentially check the newer framework version's hash against an online whitelist. This flexible solution allows for that.
- The OS keeps track of the frameworks that the app last used. Once no app has last used a version of a framework, that version can be discarded.
- Caveat: If an app allows the user to switch between multiple versions of a framework for some reason (e.g., LaTEX), it will tell the OS that it is using all of those versions. This will ensure that the version that isn't currently being used doesn't get discarded by the OS.
- Bonus points: Apps can also use an OS-provided API to install new versions of a framework. But the API doesn't allow for explicit removal, since other apps might be using it. This also allows apps that always want to use the latest version of a framework to ship with a much smaller app bundle, and download the framework on first launch. (Chrome could probably benefit from this!)
I wanted to write this out to (1) put together learnings I've gleaned from every previous time I've seen this problem brought up and (2) to point out how complex of a solution it would take to get this right. I think this would be way out of the scope of any framework and would be much better suited to be handled at the OS-level. This "framework-managing framework" could also potentially be a third-party library, but its functionality would probably trip up macOS's app checksumming, since frameworks would be removed from the app bundle.
