Live data from Hacker News

Using Java 9 Modularization to Ship Zero-Dependency Native Apps

steveperkins.com

81–90 of 117 posts

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

#81
post #75

Earlier quoted context omitted.

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

It's not a small gain for me, it's basically a necessity for keeping RAM low enough. I have 16GB on my work machine, and that's barely enough.

Your comment ties in so very well with an above exchange concerning resultant binary sizes. RAM was once $100 for a MB, I paid $400 for 4MB of RAM.

Shocking, when I look back at it.

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

#82

Earlier quoted context omitted.

stutters horrendously very often for my work setup (~800 people). also eats tons and tons of memory and kills my battery

Anecdotal problems

Another anecdote; your comment is the only one I've ever noticed that appears to be defending Slack. From an outsider looking in, I'm not sure why it is so popular.

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

#83
post #68

Earlier quoted context omitted.

No. 2.17 MB is NOT enormous. Usually there is no runtime library. In contrast, C or C++ runtime libraries can easily exceed that size. For example, vc_redist.x64.exe is 13.9 MB.

(Note: The size in the article is 21.7 MB, and not 2.17 MB!) I just tried building a statically linked 'hello world' c++ program, and co-incidentally, the binary also happened to be 2.1 MB! #include int main( int, const char *[] ) { std::cout 'g++ -static -o hello hello.cpp' produces a binary of 2191112 bytes (Linux x64). Stripping it of debug symbols leaves a 1.7 MB file.

http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...

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

#84
15 years since I last looked at Java for Desktop Apps and shipping as binary. I remember there were also GCJ as the commercial JET alternative.

Graal and Truffle are progressing along. I wonder what happen to SubstrateVM, which allows AOT of Java. I assume with SVM the binary size can be further reduced and much faster startup time.

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

#85
post #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 c…

Since Go and Electron are mentioned, let me offer a web UI library for Go: https://github.com/zserge/webview (I know UI has been a problem for Go apps for a while and is often a stopper when it comes to writing desktop apps in Go).

The library creates a full-screen webview window and lets you write UI code in HTML5/CSS/JS connecting it to the core app logic written Go. It provides JS-to-Go bindings allowing to call Go code from JS and vice versa.

The whole library is a single header file of ~800LOC with a thin Go wrapper. It supports Windows 7+, MacOS, Linux and OpenBSD.

Executables are 5-10MB in size and take about the same amount of RAM. No external libraries are used on Windows and MacOS, on Linux gtk-webkit is required, but it is typically one "apt-get" command to run.

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

#86
post #15

Earlier quoted context omitted.

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

My cursor lagging is not a small concern. It disrupts the flow between code being re/written and the mental model I'm trying to pour out.

Text input lag is an issue every editor has to deal with, and many go to extreme lengths to optimise it. Electron makes it far more difficult than most editors to fix, and every lag issue opened on VS Code seems to get decent attention, (and patches), and comparisons to Sublime Text.

Seems to be something I'm not alone in caring about.

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

#87
post #18
post #15

Earlier quoted context omitted.

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…

Electron pop culture made me buy Sublime Text.

What a breath of fresh air Sublime is.

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

#88
post #32

Earlier quoted context omitted.

While some may find GitKraken visually pleasing, it can't be used for big repos; didn't even manage to open a few of the ones I tried.

I was curious as I've never found a standalone visual git client I liked as much as IntelliJ's integrated one. So I downloaded it, found it was 1/4 of a GB and wouldn't look at a local repo without logging in to a web service. Deleted.

It never used to require logging in but the moment they added that I deleted it.

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

#89
post #32

Earlier quoted context omitted.

While some may find GitKraken visually pleasing, it can't be used for big repos; didn't even manage to open a few of the ones I tried.

I was curious as I've never found a standalone visual git client I liked as much as IntelliJ's integrated one. So I downloaded it, found it was 1/4 of a GB and wouldn't look at a local repo without logging in to a web service. Deleted.

Some years ago I was evaluating GUI git clients (the landscape has changed since) for rather simple flows and found SmartGitHg simple enough to setup and explain in under an hour and powerful enough not to drop to a shell. No affiliation here.

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

#90
post #5

> A “Hello World” CLI written in Go compiles to around 2 MB. Nitpick but hello-world in Go : package main func main(){ print("Hello World") } is < 1MB on most computers (900KB on windows). No need to import the "fmt" package.

Hey! You win the worthless example competition! See the front desk for your prize. How about comparing a full stack, monolith app in Java vs Golang? While you’re at it, don’t just compare binaries. Compare how well it handles concurrency. Compare how well it handles templates. Or how smoothly it handles DB interaction. Then look at all this and compare the population of Golang vs Java devs. Compare how well you can l…

Your message is stupid and aggressive. The author of the blog post himself compares hello-world executable sizes, so what are you complaining about?
Post reply on HN