Live data from Hacker News

Electron v5.0 Timeline

electronjs.org

31–40 of 101 posts

Re: Electron v5.0 Timeline

#31
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.

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.

Re: Electron v5.0 Timeline

#32
post #15
post #14

Earlier quoted context omitted.

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

Cough, PWA. https://docs.microsoft.com/de-de/microsoft-edge/progressive-...

Do PWAs allow you to do things like modify application menus, access the file system etc?

Re: Electron v5.0 Timeline

#33

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

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!

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.

Re: Electron v5.0 Timeline

#34
post #23

Earlier quoted context omitted.

Luckily web browsers take care to "never break the web" and remain backwards-compatible, so that should not be that much work.

I didn't see any sarcasm tags on your comment, so I'll take it at face value and disagree. Two quick examples: Google Chrome went from proposing a new WebAudio method called "start" to deprecating and removing the "noteGrainOn" method it renamed in the span of 12 months. Any sites using the original spec stopped working, some within a year of being released with the latest and greatest spec, one of which was Google's…

Gah, Polymer. Glad to hear I'm not the only one bitten by that...

(Did a single site with it, worked for a year and then for 6 months only in Safari/Firefox, and then we ported it to sit atop another Google project... ¯\_(ツ)_/¯ )

Re: Electron v5.0 Timeline

#35
post #14

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

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

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.

Re: Electron v5.0 Timeline

#36

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

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

Re: Electron v5.0 Timeline

#37
post #21
post #20

Earlier quoted context omitted.

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!

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.

Re: Electron v5.0 Timeline

#38

Earlier quoted context omitted.

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!

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.

You probably don't need electron to do that, it could be done by any end user. Wondering why it isn't being done!

Re: Electron v5.0 Timeline

#39

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.

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

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

Waste. It doesn't cost them much[0], and they don't seem to care on an ethical level about it either, and wastefulness allows them to achieve their business goals faster. Until there's a business pressure for it, things won't improve, and I have no idea what such pressure could be.

--

[0] - How many of their users are captive anyway? I didn't choose to use Slack, some non-tech folks at the company I'm working with chose it. Elsewhere, someone in the community of a technology I use also chose Slack. So now I'm forced to use them in both cases.

Re: Electron v5.0 Timeline

#40

Earlier quoted context omitted.

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!

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.

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.

Post reply on HN