I’m searching for the fastest start-up to a simple GUI in Clojure on Windows as possible.
My first thought would be Graal or Babashka via a pod maybe? (If there is one.)
Toolkit isn’t set in stone, but I would prefer JavaFX via cljfx. But if it had to be Swing to achieve quick startup, then it would be OK.
Also: If there is a ClojureScript option and it spawns a webview engine in which I place some HTML I can continuously update, that would also be fine. There may be some js bundler that get you a simple executable file.
Based on seach engine I found this discussion with @ericdallo, unfortunately with no solution I could find.
I’m very open even for creative solutions. Thanks in advance!
I basically have full control over the user’s machine. A single executable binary would be nice, because it’s an easy deployment but I could bring a jvm with the program.
Disk space is not a relevant constraint on this project, purely start up time.
A dumb gui aot’d uberjar using swing (via seesaw) just loading a jframe with a title is around 2-3s.
For a more practical example, a desktop app with about 60K loc and substantial dependencies gets a swing (with substance look and feel) splash screen up in about the same time (somewhere between 2-3s), then the application code loads and the complete gui (with an integrated IDE based on nightcode) loads at the ~13s mark (on java 8 due to legacy targeting).
For our use case, the application is typically going to be used for hours potentially and not restarted, so users are happy to have feedback (splash screen) and entry (the actual ui) in that timeframe.
I think that expectation is pretty consistent (one could do some lazy loads, maybe offload a lot more to static java and try to get faster) for GUI stuff I’ve done with swing + jvm as a deploytarget. No idea how more current jvm’s change the equation.
I think that latency can be beat going with graal native-image (although there are apparently some tricky pieces pulling in some resources swing wants at runtime that are expected in JAVA_HOME, but apparently feasible) or the webserver + browser-base app route.
Thanks a lot for that detailed reply. I will investigate and consider those two options.
Alternatively, as I control the user’s machine I may install a light daemon and then have a small rpc client to trigger that daemon to start the rest of the application.
I know this is very unorthodox and not recommended in most situations but perceived latency is the number one priority, even if the login process gets slower.
Maybe Clojure-CLR should be considered? I have not used it myself, only very little C# and VB ages ago, but the UI elements availiable are hopefully at least as good as those in JavaFX. I don’t know what performance CLR code as when it comes to it’s startup performance.
Addition: the clojure-clr-projects github-wiki is probably the best introduction material.
I haven’t yet measured the time, but I wanted to give feedback because the idea of HumbleUI (Skja → Skia) and Clojure-CLR cause me to think of Flutter.
So I tried ClojureDart with cljd.flutter and that results in quite a good start-up time in release mode. And as a bonus, programs looks quite decent by default.
It’s a definite weak spot in the language. I had found similar results (with similar packages) - a bare bones “Hello World” GUI equivalent taking 3 seconds, and my “real” app taking around 10 to 15 seconds.
As a user, I would expect less than 1 second between click/launch and being able to use it (exception being “launchers”, like Steam or Epic games, where the splash card shows up for a good 1 to 5 seconds as it “boots up”).
One idea I had considered, but never created as a package, was using a much lighter language to show an animated splash screen (C/C++/nim/janet) that would launch my Clojure based GUI app as a sub-process - then the time between cause and effect for the user (click, see splash screen) would be less than half a second.
Although at that point, it might be better to put the logic all in Clojure and have 2 portions - a GUI written in the light language, communicating via IPC with Clojure as the “engine” (running as a daemon or web-server or something).