Using Electron is a travesty. Why not something like "sciter" ?
Because it costs at least $1000 for year?
Electron v5.0 Timeline
81–90 of 101 posts
Re: Electron v5.0 Timeline
#82Does 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.)
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 wo…
easy. you just add sth like elsched.exe that keeps checking for updates in the runtime, then opens a popup saying "Electron Update Available".
Re: Electron v5.0 Timeline
#83Does 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.)
Post: Tries very hard to avoid any use of the word roadmap
First comment: Hey is X on the roadmap?
Re: Electron v5.0 Timeline
#84Earlier quoted context omitted.
Hi, Felix from Slack's Electron team here. Slack co-maintains Electron together with GitHub, employing multiple core maintainers full-time, contracting those who can't join us full-time. We've also just hosted (and paid for) the first Electron conference. We're also maintaining a fairly large number of electron-userland modules. tl;dr: That page might be misleading, we're investing heavily in Electron.
Any plans on dealing with Slack's/Electron's memory footprint?
Yes, we’re actively working on that.
Re: Electron v5.0 Timeline
#85Does 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.)
We once had such a thing.
It was called Java. But it's a thing of the past.
Re: Electron v5.0 Timeline
#86Does 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.)
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?
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?
Re: Electron v5.0 Timeline
#87Does 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.)
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.
Re: Electron v5.0 Timeline
#88Does 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.)
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.
Re: Electron v5.0 Timeline
#89Does 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.)
There's always Carlo[1] as an alternative.
Re: Electron v5.0 Timeline
#90Using Electron is a travesty. Why not something like "sciter" ?
Surely you could make a more positive contribution than mindlessly bashing the topic and assume anyone has heard of the random drive-by name drop?
People can surely utfg what sciter is in the context of a gui solution ?