Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?


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?


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

So when is Electron going to support the same features?


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: