I've been dabbling with a desktop toy application. I have it finally "done" and am in the process of working out packaging it so folks can use it.
It's written in Java with JavaFX. Short term I'm reasonably comfortable with folks downloading a "fat jar" and then grabbing the JDK on their own, and, perhaps, firing off a .sh or .bat file to run it. Mostly because I don't have a Windows box to try the whole jlink or jpackage process.
But then I started packaging it up for delivery.
JavaFX has platform dependent shared libraries, all of which would need to be bundled in the fat jar.
After building it, the result came out to 48MB... .. .
This "app" is a pane with about 20 controls on it and a GO button. It's less then 2000 lines of code. And the deliverable is 48MB.
I know, I know, that fancy animated GIF icon on that forum for someone's Avatar is probably 48MB.
But that doesn't mean it doesn't chafe me to do so. That's not even including the JDK.
I shouldn't care, but it was soul crushing.
On total whimsy, I tried Flutter. I downloaded it, and built "Hello World" for macOS. Not only did it take an eternity to compile (on my modern, SSD enabled, eleventy gigablip iMac), the result was 108MB. And that was just for the Mac version, I'd need 2 others for Linux and Windows. The compile time was glacial (I know, its got hot reloading to speed things up).
I'm sure the Electron vesion artifact is similar.
I should just shut up and take it, but it rubs me the wrong way. I'm currently exploring the possibility of doing it as a PWA targeting Chrome, dunno how well that will work, but apparently with Chrome you can save and load local files (which is something I want to do). But I can't see my large vision being done as a PWA.
I should put my head down, blinders on, and push on through.
Went through similar feelings a few years ago. Ended up going old school with C++ and wxWidgets as UI library. Felt to me like the best balance between
- wanting a single code base that I could compile for Mac/Win/Linux
- startup times measured in milliseconds
- snappy and native looking UI
- a executable size of 10MB (Mac) / 17MB (Win) / 12MB (Linux).
The bulk of that exe size is the wxWidgets UI library I statically compiled in. If you wanted to get that crispy couple of hundred kilobyte sized binary you'd probably have to directly use the native UI API of each platform, and therefore be in for not being able to reuse very much between each platform. (github.com/allanrbo/filesremote if anyone wants to see the result)
Real desktop app development feels like a dying art. (And arguably my use of wxWidgets made it not even "real real"). And I feel like it's not even harder than trying to shoehorn the web dev tools into desktop apps with things like Electron. It's just different and sort of forgotten it seems :-)
>And arguably my use of wxWidgets made it not even "real real"
Doesn't wxWidgets wrap and abstract over the native APIs for each respective platform?
Seems real enough to me.
I once decided I'd write a GUI in pure win32 (when Windows 7 was new) and the experience really, really sucked. In my book there's no shame in using a GUI library any more than a socket library.
> If you wanted to get that crispy couple of hundred kilobyte sized binary you'd probably have to directly use the native UI API of each platform, and therefore be in for not being able to reuse very much between each platform. (github.com/allanrbo/filesremote if anyone wants to see the result)
No need for three different native code bases, you should simply use FLTK. It's actively maintained, works on win/lin/osx and is just 300kB when statically linked. However it doesn't look native, if this is a serious issue for you.
I recall building my first FLTK app in 1998 and being somewhat dismayed that it was more than 1.2 MB in size. With some craftiness I had it down to just under a Meg.
It was a 3D model viewer that allowed me to load some common 3d files including vrml and do some basic manipulation like picking a face, moving it, changing its color etc.
This was all in a single static executable. Maybe OpenGL was linked dynamically don't remember.
What the fuck happened in the last quarter century? The desktop apps of today that do little more than my viewer take three orders of magnitude more space and run slower than my thing did on a 350MHz Pentium (GPU performance excepted as there have been impressive progress on that side).
15 years ago I was able to do Skype group calls just fine on the hardware available then. Since then, camera resolutions have hardly improved and yet MS Teams grinds everything else to a halt when a call starts. Just another example of things regressing. I think it has to do with a move away from tools that do one thing well to these Kraken platforms that want to eat your life.
Counterpoint: Coolplayer (http://coolplayer.sourceforge.net/) is a fairly capable MP3 player, weighing in at ~500 KB. I've used it to play MP3's on 486's back in the day.
The closest modern equivalent would be Foobar2000. Foobar2000 is much larger than Coolplayer ever was, but it's also far more capable, has plugin support etc.
On the other hand, both players are small compared to some modern alternatives.
I’ve been down a remarkably similar path to yours, and I came to the conclusion that if you want native, cross-platform, low-footprint desktop apps, then Qt is honestly the only game in town.
I know there are other frameworks - imgui, for example, which uses GPU rendering for its widgets - but none that I’ve found check all the right boxes.
To me, those boxes are: “I want to write an app using one framework, and when it’s done, I want the person on Mac to think it was made with AppKit; the person on Windows to think it was made with UWP; the person on Ubuntu to think it was made with GTK.”
Qt is the closest I’ve found, and it’s still not totally what I want (not including it’s licensing scheme, which also is a huge turn-off).
This is my conclusion too. For cross platform, Qt is the only serious choice.
I've been dabbling in GTK and if it's just a personal or linux app then I'll do it in GTK using javascript/typescript (and I'm very curious to try out GTK for windows/mac at some point), but for now a serious app, Qt is the real choice.
Agreed Qt is the play for desktop apps. I use it at work quite a bit, and if you’re careful enough you can just rely on upstream packaging for Linux. Windows isn’t horrible if you’re only relying on base/core and the platform plugins. It’s not tiny, but at least an order of magnitude smaller than an electron app. Mac I do not have any experience with so I can’t speak to that.
It really is a fun framework to develop with and it’s signal/slot feature is a delight. I’ve recently developed a Wt web app and the learning curve was basically zero after having the Qt “expertise” I do, quoted because even after 10 years with it I’m always learning something new. The more I learn the less I know kind of thing.
I like Qt too, but when it comes to packaging size, I seem to remember it was a pretty big chunk. 20 or 50 MB or something? I therefore chose wxWidgets over it, for a recent project.
How do you make a single Qt app look like both UWP and GTK? I'm not aware of any Qt Quick Controls 2 style to make QML apps look like GTK apps (like the Adwaita theme), and Qt Widgets on Windows looks like Win32 rather than UWP (either Windows 8 or 10 settings, or the newer rounded colorful Windows 11 style).
> On total whimsy, I tried Flutter. I downloaded it, and built "Hello World" for macOS. Not only did it take an eternity to compile (on my modern, SSD enabled, eleventy gigablip iMac), the result was 108MB. And that was just for the Mac version, I'd need 2 others for Linux and Windows. The compile time was glacial (I know, its got hot reloading to speed things up).
I'm curious how you got 108mb. Here's what I'm seeing:
$ flutter --version
Flutter 3.0.4 • channel stable •
https://github.com/flutter/flutter
Framework • revision 85684f9300 (7 days ago) • 2022-06-30 13:22:47 -0700
Engine • revision 6ba2af10bb
Tools • Dart 2.17.5 • DevTools 2.12.2
$ flutter create hello_world && cd hello_world
Creating project hello_world...
Running "flutter pub get" in hello_world... 1,764ms
Wrote 127 files.
All done!
In order to run your application, type:
$ cd hello_world
$ flutter run
Your application code is in hello_world/lib/main.dart.
$ flutter build macos
Building with sound null safety
Building macOS application...
$ du -ah build/macos/Build/Products/Release/hello_world.app | tail -1
44M build/macos/Build/Products/Release/hello_world.app
Note, the release build is significantly smaller than the debug build, which includes a full Dart VM for hot swapping application code:
$ flutter build macos --debug
Building with sound null safety
Building macOS application...
$ du -ah build/macos/Build/Products/Debug/hello_world.app | tail -1
98M build/macos/Build/Products/Debug/hello_world.app
Note, on the glacial compiles, here is what I'm seeing on my M1 mac laptop:
$ time flutter build macos
Building with sound null safety
Building macOS application...
flutter build macos 1.20s user 0.59s system 47% cpu 3.801 total
It's slower than building web pages in vim, but this is comparable with compiling desktop applications in Xcode.
Disclosure: I'm a Developer Relations Engineer for Flutter
I mean sure, but I presume they weren't talking directly about the exact size but that other desktop apps can be built for (at least) an order of magnitude fewer megabytes. In other words, it's not exactly 108MB that they really care about, it's that Qt or other frameworks could make a hello world app at 10MB. That's how I interpreted their comments anyway.
If you want a sneak preview of the functionality that can be delivered in Flutter at about the 100mb mark, sign up for the beta of https://www.superlist.com/
As a potential user, I'm typically really pleased with a fat jar download option! In an age where desktop apps are less common, we beggars can't be choosers anymore so 50 MB is perfectly acceptable.
I mostly use Qt these days though for desktop apps I build. It takes a minute to learn but once you get the basics down you're off to the races. And the cross platform story is awesome. I literally don't even test on windows or mac anymore until right before a release, because if it works on my linux dev machine, it's gonna work on windows/mac.
Not sure what you've tried, but here are a few more options with the Java version:
Try ProGuard, which can remove classes that aren't being used from your fat JAR. Sometimes you'll have to tweak the configuration to keep classes that it doesn't realize are being used, though (due to reflection use or whatever).
Try GraalVM, which can compile the entire thing to a native binary without a dependency on a JVM, even. I believe this will mean a separate build for each platform you want to support, though.
Not sure if these will lower the size of the download, but they're worth a try.
Hey if you are so desperate to the point of considering a PWA (I like them, but the support isn't good and the UX isn't good either, it's also not even supported by a few major browsers such as Firefox) check out Tauri at https://tauri.app/ which uses the system web view and generally yields binaries of around 2MB (except if you use AppImage which is a bit larger of course).
Hi I'm happy to provide some context: When it comes to support on Chromium it works well but there a few things that still make them less than ideal such as the toolbar that includes the extensions icon and doesn't use the system styling (at least in the case of Linux with Gnome).
Something else I feel would make PWAs much more interesting to most people is if the browser _prompts_ the person to use the PWA, if I'm not forgotten Chrome does this on mobile but not on desktop. You also don't really have much option when it comes to customizing the PWA if the provided manifest gives a bad icon or something like that.
But overall the Chrome browser is the best for PWAs right now on both desktop and mobile. Firefox however has dropped support _completely_ for PWAs which is why I personally don't even consider it an option anymore. Some discussion here: https://connect.mozilla.org/t5/ideas/bring-back-pwa-progress...
AFAIK Apple doesn't really support them too (although theoretically Steve Jobs really liked them when the iPhone first launched) because it undermines their business model of the App Store. I wish companies would use them more because they truly are the best way to develop cross-platform right now (and the PWA size is just the size of the page load for the SPA!)
Yeah, I was there was a more mainstream solution that was free/open source, could create small binaries, and have a good builtin GUI. Usually one of the 3 is missing.
48MB? Nowadays laptop are sold with 500GB SSD and minimum of 16GB or RAM. What matters are the performances. The JVM outperforms all the electron and JS app out there.
I would much prefer to download a 300MB app than use those slow JS web apps running on top of the browser.
> Nowadays laptop are sold with 500GB SSD and minimum of 16GB or RAM.
I know we are living in a bubble as HNers, but this can be disproven quite easily. I opened the website of MediaMarkt (a major European electronics retailer) and clicked (literally) the first laptop I saw:
I've never used a java app that didn't feel like a total clunker, especially with time to start up. This includes simple little utility apps, like testing SMTP servers.
I won't dispute electron apps are also often slow, but there are counter examples, such as VSCode, that are actually reasonably snappy on fairly modest systems.
What's the counter example that runs on JVM where I might not notice it's running on the JVM? (I'll also freely admit I've spent the last decade avoiding java apps when I can, because I've never had a pleasant experience due to the combination of performance and early-2000s aesthetic. Maybe the situation is vastly different today and it's just me that's outdated)
"Not snappy" is an understatement. It's a memory hog, and can visibly lag (keystrokes and mouse clicks) on my 3-year-old laptop depending on the project I have open. I probably wouldn't use anything else for Java or Scala development, but ugh, I would not call it pleasant to use from a performance perspective.
"Is an understatement". You are probably right. When I think a bit more of when I have opened huge monstrosities of Spring boot apps then it is quite slow. But for small projects I think it is "okay" and very feature rich.
It's written in Java with JavaFX. Short term I'm reasonably comfortable with folks downloading a "fat jar" and then grabbing the JDK on their own, and, perhaps, firing off a .sh or .bat file to run it. Mostly because I don't have a Windows box to try the whole jlink or jpackage process.
But then I started packaging it up for delivery.
JavaFX has platform dependent shared libraries, all of which would need to be bundled in the fat jar.
After building it, the result came out to 48MB... .. .
This "app" is a pane with about 20 controls on it and a GO button. It's less then 2000 lines of code. And the deliverable is 48MB.
I know, I know, that fancy animated GIF icon on that forum for someone's Avatar is probably 48MB.
But that doesn't mean it doesn't chafe me to do so. That's not even including the JDK.
I shouldn't care, but it was soul crushing.
On total whimsy, I tried Flutter. I downloaded it, and built "Hello World" for macOS. Not only did it take an eternity to compile (on my modern, SSD enabled, eleventy gigablip iMac), the result was 108MB. And that was just for the Mac version, I'd need 2 others for Linux and Windows. The compile time was glacial (I know, its got hot reloading to speed things up).
I'm sure the Electron vesion artifact is similar.
I should just shut up and take it, but it rubs me the wrong way. I'm currently exploring the possibility of doing it as a PWA targeting Chrome, dunno how well that will work, but apparently with Chrome you can save and load local files (which is something I want to do). But I can't see my large vision being done as a PWA.
I should put my head down, blinders on, and push on through.
But for the moment, I'm irked.