Live data from Hacker News

Using Java 9 Modularization to Ship Zero-Dependency Native Apps

steveperkins.com

51–60 of 117 posts

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#51
post #23
post #14

Earlier quoted context omitted.

Yes, but it's electron. I've honestly seen only one properly written Electron app and it's VSCode. Everything else electron sucks. VSCode is not great either but it's much better than say, Atom or Slack.

Discord is great

Sure, but Discord's web app and their native app are basically equivalent. The native app gives a little more system integration (like global hotkeys and direct access to sound hardware) but fundamentally the Discord app is just a webview.

I don't think anyone doubts that a high-quality website wrapped in a webview won't be at least the same quality. The question is whether "web-native" platforms can do more than just be a branded browser.

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#52
post #15
post #2

Even so, Java is now at a place where you can ship self-contained, zero-dependency applications that are comparable in size to other compiled languages (and superior to web-hybrid options like Electron). For cross-platform desktop GUI apps, I would argue that JavaFX combined with Java 9 modularization is hands-down the best choice available today. Electron is succeeding in the desktop GUI space because it tears down…

Well, will see how Electron will pan out in the end. While I dislike default Java Swing GUI (it can be made easily to look native but many devs previously did not do it), JavaFX can be made to look like anything with almost weblike feel to development and animations. Now, more than the looks I dislike the slowness and utterly unacceptable memory Electron apps consume. I ditched Electron and VSCode (it is a little bet…

Probably not many. They are too busy developing instead of over obsessing over small performance gains

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#54
post #2

Even so, Java is now at a place where you can ship self-contained, zero-dependency applications that are comparable in size to other compiled languages (and superior to web-hybrid options like Electron). For cross-platform desktop GUI apps, I would argue that JavaFX combined with Java 9 modularization is hands-down the best choice available today. Electron is succeeding in the desktop GUI space because it tears down…

It’s really not clear what the electron app even provides over the same app in chrome. Its own icon, sure, but the behavior is just as bad as on the web—just take slack for example.

It offers access to file system and system resources as well as multi platform build support. Developers like all people will whine over anything. For students and indie devs who have little time, support, and resources things like electron are great

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#56
post #2

Even so, Java is now at a place where you can ship self-contained, zero-dependency applications that are comparable in size to other compiled languages (and superior to web-hybrid options like Electron). For cross-platform desktop GUI apps, I would argue that JavaFX combined with Java 9 modularization is hands-down the best choice available today. Electron is succeeding in the desktop GUI space because it tears down…

It’s really not clear what the electron app even provides over the same app in chrome. Its own icon, sure, but the behavior is just as bad as on the web—just take slack for example.

Not closing and losing your data when your chrome crashes?

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#57

Earlier quoted context omitted.

It’s really not clear what the electron app even provides over the same app in chrome. Its own icon, sure, but the behavior is just as bad as on the web—just take slack for example.

It offers access to file system and system resources as well as multi platform build support. Developers like all people will whine over anything. For students and indie devs who have little time, support, and resources things like electron are great

Right, but does eg slack actually use any of that? It’s not a great native client by any stretch—it doesn’t use a native UI, it’s not particularly snappy, and it doesn’t do any special integration. So, it seems that electron is mostly a way to distinguish certain sites from others, not that they provide a better experience.

Granted I do like the distinct app icon. But electron should mean more than that to qualify as meaningfully native.

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#58
post #15
post #2

Even so, Java is now at a place where you can ship self-contained, zero-dependency applications that are comparable in size to other compiled languages (and superior to web-hybrid options like Electron). For cross-platform desktop GUI apps, I would argue that JavaFX combined with Java 9 modularization is hands-down the best choice available today. Electron is succeeding in the desktop GUI space because it tears down…

Well, will see how Electron will pan out in the end. While I dislike default Java Swing GUI (it can be made easily to look native but many devs previously did not do it), JavaFX can be made to look like anything with almost weblike feel to development and animations. Now, more than the looks I dislike the slowness and utterly unacceptable memory Electron apps consume. I ditched Electron and VSCode (it is a little bet…

There are probably more people hopping onto VS Code than people jumping off.

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#59
So, after "optimizations [...] to further reduce the resulting bundle size", a Java command-line "Hello World" is still 21.7 MB. I've found a Node.js version (using node-packer [1]) to be about the same size.

However, as mentioned in the article, "Hello World" in Go is an order of magnitude smaller. The article may be right that Java is "the best choice available" for cross-platform GUI apps, but for cross-platform command-line tools, I think Go is currently the best option. IMO Go provides the best tradeoff between ease of development, ease of distribution and runtime performance.

[1] https://github.com/pmq20/node-packer

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#60
“Zero dependency” after you install a 80MB JRE. You keep using this word. I don’t think it means what you think it does. Statically linked C is zero dependency. Go is zero dependency. Copy a binary to the target system and it runs. There’s nothing else to install.
Post reply on HN