Electron v5.0 Timeline

Re:Electron v5.0 Timeline by twhb on Tuesday February 05, 2019 @02:03AM (#19083496)

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?

[ Parent | on HN ]

Re:Electron v5.0 Timeline by kethinov on Tuesday February 05, 2019 @12:43PM (#19087530)

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?

[ Parent | on HN ]

Re:Electron v5.0 Timeline by pjmlp on Tuesday February 05, 2019 @02:23AM (#19083551)

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

So when is Electron going to support the same features?

[ Parent | on HN ]

Re:Electron v5.0 Timeline by saagarjha on Tuesday February 05, 2019 @05:13AM (#19084080)

I have not once seen a Java application that shipped as a native binary. Sure, it can be done, but this is a very rare experience practice.

[ Parent | on HN ]

Re:Electron v5.0 Timeline by pjmlp on Tuesday February 05, 2019 @06:15AM (#19084300)

I have seen plenty on the enterprise, done by companies that actually pay for their tools, or do deployments into embedded targets.

Also Android J++ does AOT compilation, as sidenote.

Now that OpenJDK is starting to offer AOT compilation for free, maybe there will be more adoption among FOSS crowd.

[ Parent | on HN ]