4 ms·
> This would I _suspect_ reduce memory usage and app size. App distribution size maybe, just like any app relying on shared libs on the system, but it needs to
by kodablah 8y ago
> This would I _suspect_ reduce memory usage and app size.
App distribution size maybe, just like any app relying on shared libs on the system, but it needs to be ready to install them if not already present and has to have strict compat guarantees. With download speeds and disk sizes being what they are, most people would just ship the lib w/ the app anyways. It would have no real affect on runtime memory usage; surely runtime mem cost of a browser is more on what it loads/does, not its code.
Now, if Chrome would put chrome.dll (or chrome.so or whatever) in a reliable location and promise ABI compat w/ some functions, there could be some real reuse since a lot of people have Chrome on their systems and could be used as a webview. However, I wouldn't expect Google to do any such thing both because they don't want to restrict themselves with compat guarantees and embeddability has no benefit for them.
- nkkollaw 8y agoI see. I meant more that Electron would add ~/.electron/chrome-66.so, and guarantee that it will be there or downloaded if required by an Electron app. Then, all apps that are built against Chrome 66 would all use a single ~/.electron/chrome-66.so
- untog 8y agoEh, that would save in hard disk space but that's hardly the main concern. What you'd actually want is the ability to use the same Webview runtime across processes, which this wouldn't allow. Android does it, but I don't know if it's possible on desktop OSes (easily)
- nkkollaw 8y agoAh, I see what the problem is, then. I've always thought it was something they were going to do sooner or later. Electron gets a lot of hate, while I think it's a great tech and 90% of the apps I use are available just because of its existence, since I'm on Linux and they wouldn't bother porting them if it wasn't made easy by Electron.