Electron v5.0 Timeline

https://electronjs.org/blog/electron-5-0-timeline

by jedixit • 7 years ago

135 96 7 years ago

zamadatix2• 7 years ago

As someone who has only ever created some basic quick apps in Electron and NW.js why is it Electron sees a much slower release cadence? Is there a different scope of integration with the underlying components?

shagie• 7 years ago

From the article:

In the last half of 2018, our top priority was releasing faster and catching up closer to Chromium. We succeeded by sticking to a predetermined timeline. Electron 3.0.0 and 4.0.0 were released in a 2-3 month timeline for each release. We are optimistic about continuing that pace in releasing 5.0.0 and beyond. With a major Electron release approximately every quarter, we're now keeping pace with Chromium's release cadence. Getting ahead of Chromium stable release is always a goal for us and we are taking steps towards that.

zamadatix2• 7 years ago

I'm not sure this answers the question I asked. I'm already aware Electron has been trying to achieve release cadence I was curious as to why they've been having trouble doing so vs e.g. NW.js

ravedave53• 7 years ago

Chromium changes a lot. One of my teams tried integrating it directly and couldn't keep up with the API change. We went with a 3rd party library that wraps it to shield us from it.

ttoinou3• 7 years ago

Which 3rd party library ? :)

windom• 7 years ago

I'm very curious, which library did you end up using?

yodon• 7 years ago

Looking over the donors page, I'm pretty amazed at slack's absence. Ditto for Microsoft Teams. Way to give back to the community.

no_wizard• 7 years ago

To be fair, Microsoft now pays the bills for the entire company, since electron is Githubs project as I have come to understand it

basil-rash2• 7 years ago

Which makes me wonder: where do the donations actually go? It looks like the total amount is less than 15k, so everything donated is very easily overshadowed by MSFT's contributions, and I don't see any hints at a payment-for-contributions program on the electron github.

briandear• 7 years ago

I’d rather Slack just stop using electron and write a real native app; they can certainly afford it. Meanwhile, Slack remains an incredible resource hog.

anticodon• 7 years ago

It also behaves very erratically on a slower channels. On 3G speeds and lower it becomes basically unusable - messages are not sent or sent in the wrong order.

Why it needs so much resources just to send a few bytes of text?..

aportnoy• 7 years ago

Slack takes 5-7 seconds to start up and connect on an ultra low latency 300 Mbit connection. I really wish there were a native app on Mac.

choward• 7 years ago

I would say VS Code is pretty good contribution. Since it's open source it can also be seen as a large code example.

legostormtroopr• 7 years ago

Donations are a voluntary contribution based on "feeling good", and companies especially big publicly funded companies can rarely donate to "feel good". Its hard to justify to financiers why you should pay for open-source updates, if you can get them for free anyway.

It just highlights why donation is a terrible business model for open-source.

Come up with a better support model and people will pay.

make3• 7 years ago

are you kidding, GitHub belongs to Microsoft, they would be giving themselves money

paxys2• 7 years ago

The top donor on that page is Facebook, which has given $9,000 total. Next highest is $745. Just a few commits' worth of development time costs a lot more than that, and both Microsoft and Slack have been major contributors to Electron.

chrisco255• 7 years ago

Several Slack employees contribute core source code to Electron. I believe they may even have several dedicated employees working on Electron full time. Same goes for MS.

felixrieseberg3• 7 years ago

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.

hylaride• 7 years ago

Any plans on dealing with Slack's/Electron's memory footprint?

kethinov2• 7 years ago

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.)

BubRoss• 7 years ago

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

pjmlp8• 7 years ago

Cough, PWA.

https://docs.microsoft.com/de-de/microsoft-edge/progressive-...

devwastaken2• 7 years ago

This won't meet requirements either. Desktop apps require full system access. Either they get that, or it's another API that'll be deprecated sooner than later.

stabbles• 7 years 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!

aserafini2• 7 years 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.

icelancer• 7 years 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.

twhb• 7 years 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?

pjmlp8• 7 years ago

Java applications can compile to native code and remove needless bloat via linking.

So when is Electron going to support the same features?

kethinov2• 7 years 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?

devwastaken2• 7 years ago

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

felixrieseberg3• 7 years 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.

Renaud2• 7 years 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.

ttoinou3• 7 years 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• 7 years 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• 7 years 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

black_puppydog• 7 years ago

easy. you just add sth like elsched.exe that keeps checking for updates in the runtime, then opens a popup saying "Electron Update Available".

matharmin• 7 years ago

You can use Chrome + NodeJS as the shared runtime instead of Electron, using an approach such as this: 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• 7 years ago

Post: Tries very hard to avoid any use of the word roadmap

First comment: Hey is X on the roadmap?

jhoechtl• 7 years ago

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

raydev• 7 years 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.

tracker12• 7 years 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.

tracker12• 7 years ago

There's always Carlo[1] as an alternative.

https://github.com/GoogleChromeLabs/carlo

theredbox3• 7 years ago

Using Electron is a travesty. Why not something like "sciter" ?

StellarTabi• 7 years ago

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?

theredbox3• 7 years ago

People can surely utfg what sciter is in the context of a gui solution ?

slezyr• 7 years ago

Because it costs at least $1000 for year?

theredbox3• 7 years ago

Yes good software costs money. Whatever is wet.

nm2259• 7 years ago

I've seen sciter come up in discussion on quite a few threads related to Electron and other web browser embedding systems, but I've never seen a good answer for "why not sciter", so I'll try to put some points out here:

1. Electron is open source, sciter is free as in beer only. 2. Electron implements the exact same javascript as the web, sciter implements its own js-like language. Harder to find developers with experience, and harder move your app from sciter to some other engine down the line. 3. Electron implements the exact same html/css as the web, sciter implements html/css from a few years back plus its own proprietary bolt-ons. Same problems as #2.

paxys2• 7 years ago

Maybe because no one has ever heard of it?

tonyedgecombe• 7 years ago

Those poor Electron devs, they will be pushing that Sisyphean boulder up the hill forever. It reminds me of the thesis of Joel Spolsky's essay Fire and Motion.

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

cdnsteve2• 7 years ago

What is the upgrade process like for existing applications built on the Electron framework? Is it well documented and a first consideration or are you thrown to the wind? Will 4 be able to move to 5 or are we talking about rewrites?

WorldMaker• 7 years ago

It's pretty well documented.

If you are just using Electron "off the shelf" to host your web app it's generally `npm install` the updated binary, test, and deploy.

Sometimes an Electron-only API changes, but that's pretty rare and most of them aren't "mission critical" if they break. That's always documented well in the release notes and the API and Electron for the most part seems to follow a "deprecate for a version ahead" pattern that you should have plenty of warning.

If you are using native libraries is where things get complicated. At that point you are likely building your own Electron binary, and need to find updated versions of your libraries that support the upgrade NodeJS and/or Chromium versions. Most of that is the same documentation whether or not Electron was in the project, check the related documentation for the appropriate NodeJS and/or Chromium versions, rebuild as needed using the usual tools.

cdnsteve2• 7 years ago

Great response, thank you!

Electron v5.0 Timeline

Related Stories