Electron v5.0 Timeline

Post by saagarjha » Tue, Feb 05, 2019, 10:13 AM UTC

pjmlp wrote: post #30

twhb wrote: post #24

Earlier quoted context omitted.

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?

Java applications can compile to native code and remove needless bloat via linking. So when is Electron going to support the same features?

Post by windom » Tue, Feb 05, 2019, 10:39 AM UTC

ravedave5 wrote: post #5

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?

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.

Post by de_watcher » Tue, Feb 05, 2019, 10:58 AM UTC

aserafini wrote: post #19

stabbles wrote: post #17

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.

Post by pjmlp » Tue, Feb 05, 2019, 11:17 AM UTC

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?

Post by pjmlp » Tue, Feb 05, 2019, 12:10 PM UTC

Vinnl wrote: post #54

jointhefuture wrote: post #25

Earlier quoted context omitted.

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

You're right that there's some risk - especially using API's that can also be abused. However, percentage-wise, the vast majority of works targeting browsers continue to work unmodified (at least in terms of interacting with the browser), making it a very stable platform and definitely not breaking as often and as likely as implied by the words "aggressive release cycle". That said, it's definitely not yet feature-ri…