Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Electron v5.0 Timeline

electronjs.org

Post reply on HN
Print view View original

71–80 of 101 posts

Re: Electron v5.0 Timeline

#71

Post by zamadatix »

shagie wrote: post #3
zamadatix wrote: post #2

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?

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 Ch…

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

Re: Electron v5.0 Timeline

#72

Post by cdnsteve »

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?

Re: Electron v5.0 Timeline

#73

Post by Maakuth »

bgdam wrote: post #57
pjmlp wrote: post #47

Earlier quoted context omitted.

If you bothered to read the link I posted, you would see that PWAs are native apps in UWP with full access to the same APIs as .NET and C++ have, if distributed via the store. Same applies to PWAs on ChromeOS (naturally given its nature), and Google is ramping up the same capabilities on Android with their initial release of TWA. Yep, there are a few OSes currently left out, it is up to their masters to follow Micros…

So you're proposing a solution which works on only Windows and ChromeOS (considering desktop OS only), and has to be distributed via a proprietary store (which in all likelihood might take a cut of my revenues), as a replacement for something that works on Win, Linux, and MacOS, and does not require that I lock myself into an unfavorable distribution method?

AFAIK there's no such lock-in in PWAs, even if the app stores are probably going to be the most important venues for their distribution. PWA is a web app that gets more 'app-like' progressively when you need it to. You can use it like any other web application in your browser, but if it's okay to you, it can store data (and cache it's own assets) to your machine, start in it's own window from a launcher, use the filesystem and so on. Many web apps already have this sort of behaviors when you create a home screen launcher for them from your browser.

Re: Electron v5.0 Timeline

#75

Post by bgdam »

Maakuth wrote: post #73
bgdam wrote: post #57

Earlier quoted context omitted.

So you're proposing a solution which works on only Windows and ChromeOS (considering desktop OS only), and has to be distributed via a proprietary store (which in all likelihood might take a cut of my revenues), as a replacement for something that works on Win, Linux, and MacOS, and does not require that I lock myself into an unfavorable distribution method?

AFAIK there's no such lock-in in PWAs, even if the app stores are probably going to be the most important venues for their distribution. PWA is a web app that gets more 'app-like' progressively when you need it to. You can use it like any other web application in your browser, but if it's okay to you, it can store data (and cache it's own assets) to your machine, start in it's own window from a launcher, use the file…

Per the parent comment I was responding to, PWAs will only have full access to native APIs if they are distributed via the store. And without access to native APIs things like window management, menus etc. become impossible to customize.

Re: Electron v5.0 Timeline

#76

Post by eswat »

aportnoy wrote: post #16
briandear wrote: post #8

Earlier quoted context omitted.

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.

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.

The Slack integration is a bit rough still, but: https://cancel.fm/ripcord/

Re: Electron v5.0 Timeline

#78

Post by megous »

Renaud wrote: post #43
kethinov wrote: post #13

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

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…

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

Re: Electron v5.0 Timeline

#79

Post by hylaride »

felixrieseberg wrote: post #45
yodon wrote: post #4

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

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?

Re: Electron v5.0 Timeline

#80

Post by smichel17 »

barrystaes wrote: post #37
arbie wrote: post #21

Earlier quoted context omitted.

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"?

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.

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".
Post reply on HN