A lot of work has gone into making browsers use less memory by sharing #2 between tabs and windows and such. And operating systems have some ways to help with this.
But Electron shipping different copies with each app app has, afaict, undone this *entirely*.
Conversation
Because a lot of those mechanisms rely on it using the same shared libraries (DLLs/.so files) or executables, and mapping the read-only parts to the same chunk of physical memory.
1
16
Honestly, part of me wonders if it would make sense to lean significantly harder into the "browser as a framework" approach.
1
19
What if it were super tightly integrated into the desktop? But maybe standardized in a way where you could switch which browser is providing the integration. Y'know, avoiding revisiting the whole IE problems of the past and all that.
6
1
21
E.g., what if the "desktop" was simply a primary browser window, and if you opened an Electron-style app in it, the app got its own name and icon and separate window.
Visually it would be a traditional desktop, but internally it would be the logical progression of Electron.
3
1
20
Progressive Web Apps, Single-Site Browsers, and similar concepts can get you pretty fucking far with that idea, honestly.
2
18
It's a little frustrating that Firefox seems to have outright abandoned both PWA and SSB functionality on the desktop, honestly, given that it does seem to be where desktops are headed.
3
5
23
It's also FirefoxOS. There's been a few attempts.
Quote Tweet
Replying to @duckinator
That's ChromeOS. You're talking about ChromeOS.
5
25
Android, iOS/macOS and now Windows have a proper WebView integrated into the OS with out-of-band updates not depending on the application. It doesn't solve the same problem because these are 3 substantially different APIs. iOS/macOS WebView is also missing a ton of modern APIs.
1
Despite both being Chromium-based, the Android WebView and Windows WebView2 would still require making an abstraction layer and separate code outside the WebView for both platforms. Would be much more painful to also make it portable to iOS/macOS with this approach though.
There's no proper equivalent in the Linux world providing a stable API for a sandboxed WebView. Qt and GTK WebView APIs aren't on the same level. They have too many limitations (especially GTK), the APIs are moving targets and the security situation is pretty much horrifying.
2
You could use these platform-specific WebView APIs to port a web-based application to each platform but you would be maintaining a fair bit for each platform and dealing with the differences across browser engines, especially the limitations of Safari and the GTK WebKit variant.