7 ms·

Does anyone know if the idea of creating a runtime mode for Electron is on the roadmap? (A runtime mode would be allowing multiple apps to share one installed E

Does anyone know if the idea of creating a runtime mode for Electron is on the roadmap? (A runtime mode would be allowing multiple apps to share one installed Electron dependency rather than bundling Electron with every Electron app.)

stabbles 8y ago
Yes, that would be very useful to have. Some runtime, or some central application, so that the user just has to download some HTML, CSS and Javascript -- not a complete copy of Electron each time. And if this application could be used to browse the internet when the user enters a URL, that would be useful too! Game changer!
- aserafini 8y ago
  Yes great idea! The different applications (or URLs) could be opened simultaneously and displayed as ‘tabs’ for the user to manage in the central application.
  - dewiz 8y ago
    That would also allow to call one application from another, just assigning some reserved namespace or domain and appending the feature at the end, kind of a path. Exciting times!
    - arbie 8y ago
      How would one remember a collection of these namespaces or the current place within one location? Analogous to physical paper, could we repurpose the concept of a "bookmark"?
      - barrystaes 8y ago
        To avoid having to update these files on your pc, these could be served by a "server" on the internet. We would have to run cables around the earth so everyone can benefit.
        xaitv 8y ago
        First thing we'd have to serve then is some place where stuff like that can be discussed though, maybe some sort of "forum" with "comments" and stuff?
        smichel17 8y ago
        Unfortunately, that would also introduce latency. Plus, I'd like to be able to access these files when I'm not connected to one of these "servers".
  - murukesh_s 8y ago
    You probably don't need electron to do that, it could be done by any end user. Wondering why it isn't being done!
  - sterlind 8y ago
    I get the joke, but an Electron "player" daemon seems like a decent idea. It could manage getting the right runtime versions, installing apps, deduping assets and granting permissions. It'd be a sort of cross-platform Google Play Services.
  - de_watcher 8y ago
    Oh, you're too brutal to the webdev community. Don't do that. :D
- icelancer 8y ago
  Everyone likes this idea until the HTML, CSS, and JS are given the ability to change application menus and access the file system. Then oh no, we can't have that.
  - ninkendo 8y ago
    Surely you can fix that without having physically separate copies of the underlying chromium engine? edit: I realize now this is a joke thread... whoosh.
    - krapp 8y ago
      It's funny because it's not entirely a joke.
  - aserafini 8y ago
    Instead we are encouraging users to download arbitrary binaries bundled with a browser that can be controlled and updated remotely. It’s not clear to me this is any safer.
BubRoss 8y ago
Or just build local permissions into web browsers and download 200KB of HTML and JavaScript instead of 200MB for an electronic install.
- pjmlp 8y ago
  Cough, PWA. https://docs.microsoft.com/de-de/microsoft-edge/progressive-web-apps/windows-features?branch=pwa https://docs.microsoft.com/de-de/microsoft-edge/progressive-...
  - flukus 8y ago
    Probably OK for some uses, like when you publish as a web app anyway, but for others it burdens you with keeping up with the aggressive release cycle of browsers.
    - Vinnl 8y ago
      Luckily web browsers take care to "never break the web" and remain backwards-compatible, so that should not be that much work.
      - jointhefuture 8y ago
        I love your sarcastic response. Favorite recent example, Chrome's audio blocking solution pretty much broke every HTML5 game in existence. 1000s of sites are still broken. To just name some easy categories, every Pico-8 game exported to HTML5, Every Unity and Unreal game exported to HTML5. Even 100s of Google's own Doodles, examples, promotions, etc ... until they pre-whitelisted every domain they own. The worst is Apple. Trying to do anything game related in a webpage on iOS Safari is a nightmare and is pretty much guaranteed to break with each new iOS release. "minimal-ui" (nope, took that way), "user-scalable" (worked but they keep changing the conditions so old games break and have to reverse engineer under what conditions it's respected). I recently noticed one of my sites broke for audio. No errors, no mention of what changed that I can fine, worked 6 months ago, stopped working, Safari only. Note it's a site about audio and it doesn't start that audio until the user clicks the "Play" button. It's using the "resume" api but no sound comes out. Still works in Firefox and Chrome (after having to update it last year for Chrome's breaking change)
twhb 8y ago
Java-based GUI applications have been moving from the system's JVM to bundling one due to longstanding and seemingly unfixable reliability and ease of use problems. Why will Electron be different?
- pjmlp 8y ago
  Java applications can compile to native code and remove needless bloat via linking. So when is Electron going to support the same features?
  - saagarjha 8y ago
    I have not once seen a Java application that shipped as a native binary. Sure, it can be done, but this is a very rare experience practice.
    - pjmlp 8y ago
      I have seen plenty on the enterprise, done by companies that actually pay for their tools, or do deployments into embedded targets. Also Android J++ does AOT compilation, as sidenote. Now that OpenJDK is starting to offer AOT compilation for free, maybe there will be more adoption among FOSS crowd.
- kethinov 8y ago
  The right way to design it would be to allow apps to declare an allowed range of Electron dependency in package.json. For instance, if my app depends on Electron 5.x, then it will only run if 5.x is installed. If other apps require 4.x, then a system needs to be in place to allow both 4.x and 5.x to be installed on the system simultaneously. This way if—say—you have five Electron apps running on your system, three of them require Electron 5.x, and two of them require Electron 4.x, then you only need two versions of Electron installed to your system instead of today's approach of bundling one with each app. Honestly not sure why Java doesn't work this way too. I think .NET does, doesn't it?
devwastaken 8y ago
I'm unsure if chromium is designed in a way to allow for this safely.
felixrieseberg 8y ago
Currently not on the roadmap – for what it's worth, the majority of apps perform their Electron updates at different times, so you'd still have the same number of binaries and files as you do today.
Renaud 8y ago
Then you get into the issue of keeping apps and runtime in sync so you don't get issues with older apps not working well with a new version of the runtime required by newer apps... You end-up having to keep multiple runtimes and hoping they don't step on each-other's toes... After a while you're still downloading 200+MB runtimes to run your particular app that still requires Runtime 5.05 and hasn't been updated to work with Runtime 6.12 that is required for newer updates of an app that used to work with Runtime 5.84... Maybe a better idea would be to make Electron's install specific to each app and only include the bits you actually need so it's a 30MB bundle instead? Just wondering if calling for a runtime isn't going to make things worse in the long run. It 's already often a pain to install an app that target any framework version in particular that may not be installed or may conflict on some user's target machines. Sometimes it's unavoidable, but I'm wondering if this is really the case here.
- ttoinou 8y ago
  Fully agree. I've thought about that and the only solution I came up was to only update all your electrons apps at the same time and they would share the minimal electron runtime's version possible. Would also require electron-apps developers to provide all versions of their app (with the runtime version information)
- ksec 8y ago
  Agree. I think the solution is to make the runtime a lot smaller to the point where download each time becomes a non-issues. Which isn't really PWA because Electron do offer slightly more capabilities.
- megous 8y ago
  What ends up happening is that without a shared runtime, now each user is responsible for ensuring he has the latest security fixes in every single of his apps' bundled runtimes, which is much harder to ensure than with a shared runtime. The users have to track the releases of electron themselves and keep on top of security bugs. While it may be easier for devs to bundle, it's a major loss and a huge risk to users. Probably much more with non-major apps, where the developer may not care all that much to update bundled runtimes, when he's not adding features to the app itself. Did you check none of the apps you use are vulnerable to this?[1] Now until every single developer and every single electron app in existence updates their runtimes, they'll be potentially vulnerable to this major privilege escalation bug. [1] https://electronjs.org/blog/window-open-fix https://electronjs.org/blog/window-open-fix
matharmin 8y ago
You can use Chrome + NodeJS as the shared runtime instead of Electron, using an approach such as this: https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo You still need to bundle a copy of NodeJS with your app if you're not targeting developers, but that's much smaller. Of course, this still has many of the issues that a shared copy of Electron will have - you need to make sure that your app stays compatible as Chrome is updated. The HTML/JS side is typically not an issue, but the devtools protocol that you need for this does get breaking changes now and then.
m0dest 8y ago
Post: Tries very hard to avoid any use of the word roadmap First comment: Hey is X on the roadmap?
jhoechtl 8y ago
We once had such a thing. It was called Java. But it's a thing of the past.
raydev 8y ago
I think MS fully intends to have something like Electron available for apps to use as a target on Windows. They are desperate to make things easy as possible so devs of consumer apps don't abandon the platform or just make general performance worse by targeting standalone Electron. macOS is experimenting with UIKit, so we'll see how that plays out. But I wouldn't be completely surprised a few years from now if they announced a Safari-based competitor to Electron that has obvious benefits, like battery life and GPU acceleration everywhere.
tracker1 8y ago
I think it would be nice to see this happen, it could be what Adobe's Air platform was supposed to be... I would think that MS could do it relatively easily. The biggest risk, however are those modules that are compiled to the platform and node version in question. There are now some abstractions that make this easier, but it's still far from perfect. And depending on the application there are more or fewer risks of this being a problem. As it stands SQLite is specifically one of the most used compiled modules alone and is used in many projects.
tracker1 8y ago
There's always Carlo[1] as an alternative. https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo

stabbles 8y ago

Yes, that would be very useful to have. Some runtime, or some central application, so that the user just has to download some HTML, CSS and Javascript -- not a complete copy of Electron each time. And if this application could be used to browse the internet when the user enters a URL, that would be useful too! Game changer!

aserafini 8y ago
Yes great idea! The different applications (or URLs) could be opened simultaneously and displayed as ‘tabs’ for the user to manage in the central application.
- dewiz 8y ago
  That would also allow to call one application from another, just assigning some reserved namespace or domain and appending the feature at the end, kind of a path. Exciting times!
  - arbie 8y ago
    How would one remember a collection of these namespaces or the current place within one location? Analogous to physical paper, could we repurpose the concept of a "bookmark"?
    - barrystaes 8y ago
      To avoid having to update these files on your pc, these could be served by a "server" on the internet. We would have to run cables around the earth so everyone can benefit.
      - xaitv 8y ago
        First thing we'd have to serve then is some place where stuff like that can be discussed though, maybe some sort of "forum" with "comments" and stuff?
      - smichel17 8y ago
        Unfortunately, that would also introduce latency. Plus, I'd like to be able to access these files when I'm not connected to one of these "servers".
- murukesh_s 8y ago
  You probably don't need electron to do that, it could be done by any end user. Wondering why it isn't being done!
- sterlind 8y ago
  I get the joke, but an Electron "player" daemon seems like a decent idea. It could manage getting the right runtime versions, installing apps, deduping assets and granting permissions. It'd be a sort of cross-platform Google Play Services.
- de_watcher 8y ago
  Oh, you're too brutal to the webdev community. Don't do that. :D
icelancer 8y ago
Everyone likes this idea until the HTML, CSS, and JS are given the ability to change application menus and access the file system. Then oh no, we can't have that.
- ninkendo 8y ago
  Surely you can fix that without having physically separate copies of the underlying chromium engine? edit: I realize now this is a joke thread... whoosh.
  - krapp 8y ago
    It's funny because it's not entirely a joke.
- aserafini 8y ago
  Instead we are encouraging users to download arbitrary binaries bundled with a browser that can be controlled and updated remotely. It’s not clear to me this is any safer.

BubRoss 8y ago

Or just build local permissions into web browsers and download 200KB of HTML and JavaScript instead of 200MB for an electronic install.

pjmlp 8y ago
Cough, PWA. https://docs.microsoft.com/de-de/microsoft-edge/progressive-web-apps/windows-features?branch=pwa https://docs.microsoft.com/de-de/microsoft-edge/progressive-...
- flukus 8y ago
  Probably OK for some uses, like when you publish as a web app anyway, but for others it burdens you with keeping up with the aggressive release cycle of browsers.
  - Vinnl 8y ago
    Luckily web browsers take care to "never break the web" and remain backwards-compatible, so that should not be that much work.
    - jointhefuture 8y ago
      I love your sarcastic response. Favorite recent example, Chrome's audio blocking solution pretty much broke every HTML5 game in existence. 1000s of sites are still broken. To just name some easy categories, every Pico-8 game exported to HTML5, Every Unity and Unreal game exported to HTML5. Even 100s of Google's own Doodles, examples, promotions, etc ... until they pre-whitelisted every domain they own. The worst is Apple. Trying to do anything game related in a webpage on iOS Safari is a nightmare and is pretty much guaranteed to break with each new iOS release. "minimal-ui" (nope, took that way), "user-scalable" (worked but they keep changing the conditions so old games break and have to reverse engineer under what conditions it's respected). I recently noticed one of my sites broke for audio. No errors, no mention of what changed that I can fine, worked 6 months ago, stopped working, Safari only. Note it's a site about audio and it doesn't start that audio until the user clicks the "Play" button. It's using the "resume" api but no sound comes out. Still works in Firefox and Chrome (after having to update it last year for Chrome's breaking change)

twhb 8y ago

Java-based GUI applications have been moving from the system's JVM to bundling one due to longstanding and seemingly unfixable reliability and ease of use problems. Why will Electron be different?

pjmlp 8y ago
Java applications can compile to native code and remove needless bloat via linking. So when is Electron going to support the same features?
- saagarjha 8y ago
  I have not once seen a Java application that shipped as a native binary. Sure, it can be done, but this is a very rare experience practice.
  - pjmlp 8y ago
    I have seen plenty on the enterprise, done by companies that actually pay for their tools, or do deployments into embedded targets. Also Android J++ does AOT compilation, as sidenote. Now that OpenJDK is starting to offer AOT compilation for free, maybe there will be more adoption among FOSS crowd.
kethinov 8y ago
The right way to design it would be to allow apps to declare an allowed range of Electron dependency in package.json. For instance, if my app depends on Electron 5.x, then it will only run if 5.x is installed. If other apps require 4.x, then a system needs to be in place to allow both 4.x and 5.x to be installed on the system simultaneously. This way if—say—you have five Electron apps running on your system, three of them require Electron 5.x, and two of them require Electron 4.x, then you only need two versions of Electron installed to your system instead of today's approach of bundling one with each app. Honestly not sure why Java doesn't work this way too. I think .NET does, doesn't it?

devwastaken 8y ago

I'm unsure if chromium is designed in a way to allow for this safely.

felixrieseberg 8y ago

Currently not on the roadmap – for what it's worth, the majority of apps perform their Electron updates at different times, so you'd still have the same number of binaries and files as you do today.

Renaud 8y ago

Then you get into the issue of keeping apps and runtime in sync so you don't get issues with older apps not working well with a new version of the runtime required by newer apps... You end-up having to keep multiple runtimes and hoping they don't step on each-other's toes... After a while you're still downloading 200+MB runtimes to run your particular app that still requires Runtime 5.05 and hasn't been updated to work with Runtime 6.12 that is required for newer updates of an app that used to work with Runtime 5.84... Maybe a better idea would be to make Electron's install specific to each app and only include the bits you actually need so it's a 30MB bundle instead? Just wondering if calling for a runtime isn't going to make things worse in the long run. It 's already often a pain to install an app that target any framework version in particular that may not be installed or may conflict on some user's target machines. Sometimes it's unavoidable, but I'm wondering if this is really the case here.

ttoinou 8y ago
Fully agree. I've thought about that and the only solution I came up was to only update all your electrons apps at the same time and they would share the minimal electron runtime's version possible. Would also require electron-apps developers to provide all versions of their app (with the runtime version information)
ksec 8y ago
Agree. I think the solution is to make the runtime a lot smaller to the point where download each time becomes a non-issues. Which isn't really PWA because Electron do offer slightly more capabilities.
megous 8y ago
What ends up happening is that without a shared runtime, now each user is responsible for ensuring he has the latest security fixes in every single of his apps' bundled runtimes, which is much harder to ensure than with a shared runtime. The users have to track the releases of electron themselves and keep on top of security bugs. While it may be easier for devs to bundle, it's a major loss and a huge risk to users. Probably much more with non-major apps, where the developer may not care all that much to update bundled runtimes, when he's not adding features to the app itself. Did you check none of the apps you use are vulnerable to this?[1] Now until every single developer and every single electron app in existence updates their runtimes, they'll be potentially vulnerable to this major privilege escalation bug. [1] https://electronjs.org/blog/window-open-fix https://electronjs.org/blog/window-open-fix

matharmin 8y ago

You can use Chrome + NodeJS as the shared runtime instead of Electron, using an approach such as this: https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo You still need to bundle a copy of NodeJS with your app if you're not targeting developers, but that's much smaller. Of course, this still has many of the issues that a shared copy of Electron will have - you need to make sure that your app stays compatible as Chrome is updated. The HTML/JS side is typically not an issue, but the devtools protocol that you need for this does get breaking changes now and then.

m0dest 8y ago

Post: Tries very hard to avoid any use of the word roadmap First comment: Hey is X on the roadmap?

jhoechtl 8y ago

We once had such a thing. It was called Java. But it's a thing of the past.

raydev 8y ago

I think MS fully intends to have something like Electron available for apps to use as a target on Windows. They are desperate to make things easy as possible so devs of consumer apps don't abandon the platform or just make general performance worse by targeting standalone Electron. macOS is experimenting with UIKit, so we'll see how that plays out. But I wouldn't be completely surprised a few years from now if they announced a Safari-based competitor to Electron that has obvious benefits, like battery life and GPU acceleration everywhere.

tracker1 8y ago

I think it would be nice to see this happen, it could be what Adobe's Air platform was supposed to be... I would think that MS could do it relatively easily. The biggest risk, however are those modules that are compiled to the platform and node version in question. There are now some abstractions that make this easier, but it's still far from perfect. And depending on the application there are more or fewer risks of this being a problem. As it stands SQLite is specifically one of the most used compiled modules alone and is used in many projects.

tracker1 8y ago

There's always Carlo[1] as an alternative. https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo