5 ms·

Does it by any chance provide a shared Chrome version across apps? It seems possible to have a single (or 1 for every version) instance of Chrome on the system

Does it by any chance provide a shared Chrome version across apps? It seems possible to have a single (or 1 for every version) instance of Chrome on the system, and Electron apps could use the same one, or tell Electron they need another version and it could download it. This would I _suspect_ reduce memory usage and app size.

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 ago
  I 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 ago
    Eh, 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 ago
      Ah, 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.
bigato 8y ago
Using the browser installed in the system instead would reduce resource usage even further </ironic>
- oblio 8y ago
  You're kidding, but it should.
- kodablah 8y ago
  Some systems don't allow their most modern browser to be easily consumed. Also, Chromium has features that some default-distro browsers don't. Finally, using browsers on the system don't always give flexibility that Electron does and even when they do, the abstraction to the greatest common factors just so you can work cross-platform leave a lot out.
- ttoinou 8y ago
  There's https://nodekit.io/ https://nodekit.io/ But it seems it's a dead project :-( And https://github.com/zserge/webview https://github.com/zserge/webview doesn't seem to offer a lot of cross platform functionality
  - 52-6F-62 8y ago
    > And https://github.com/zserge/webview https://github.com/zserge/webview doesn't seem to offer a lot of cross platform functionality Not to drag this too far off topic—but outside of the API differences between webviews— what do you mean? I imagine it could be used to serve something like Slack's web app for example which [I imagine] would have been built to bend to each of those browsers' functionality to begin with.
    - RussianCow 8y ago
      The point is that you would have to re-implement Node's/Electron's APIs on top of each browser engine, so that OS functionality could be exposed to the JavaScript code. That webview project does not expose very much in the way of system API calls, which is what the parent was referring to.
lioeters 8y ago
There's a long-running issue (3 years~) with discussion around the idea of a shared runtime across apps. https://github.com/electron/electron/issues/673 https://github.com/electron/electron/issues/673 A few attempts at solving specific aspects, but no real solution yet..

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 ago
I 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 ago
  Eh, 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 ago
    Ah, 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.

bigato 8y ago

Using the browser installed in the system instead would reduce resource usage even further </ironic>

oblio 8y ago
You're kidding, but it should.
kodablah 8y ago
Some systems don't allow their most modern browser to be easily consumed. Also, Chromium has features that some default-distro browsers don't. Finally, using browsers on the system don't always give flexibility that Electron does and even when they do, the abstraction to the greatest common factors just so you can work cross-platform leave a lot out.
ttoinou 8y ago
There's https://nodekit.io/ https://nodekit.io/ But it seems it's a dead project :-( And https://github.com/zserge/webview https://github.com/zserge/webview doesn't seem to offer a lot of cross platform functionality
- 52-6F-62 8y ago
  > And https://github.com/zserge/webview https://github.com/zserge/webview doesn't seem to offer a lot of cross platform functionality Not to drag this too far off topic—but outside of the API differences between webviews— what do you mean? I imagine it could be used to serve something like Slack's web app for example which [I imagine] would have been built to bend to each of those browsers' functionality to begin with.
  - RussianCow 8y ago
    The point is that you would have to re-implement Node's/Electron's APIs on top of each browser engine, so that OS functionality could be exposed to the JavaScript code. That webview project does not expose very much in the way of system API calls, which is what the parent was referring to.

lioeters 8y ago

There's a long-running issue (3 years~) with discussion around the idea of a shared runtime across apps. https://github.com/electron/electron/issues/673 https://github.com/electron/electron/issues/673 A few attempts at solving specific aspects, but no real solution yet..