Very interesting to use a redux (re-frame) like programming model for building native desktop UI's. I have done some basic stuff with it and it sure seems powerful.
If you're interested in desktop alternatives for clojure, check out https://github.com/phronmophobic/membrane. It's different from javafx in that all the event handling code is pure clojure. For graphics, it uses skia, https://skia.org/.
Thanks! More complicated layout strategies are easy to integrate, but spacer works really well for examples since most people can intuit what the result will look like.
Skia has worked well so far. Since it's used by Chrome, Android, and Firefox under the hood, it means that I can reach a lot of platforms "for free".
As someone who used to like JavaFX and maintain a few desktop apps that use JavaFX, I have to say you're totally right.
Google seems to be putting huge amounts of effort on Flutter, and it can already run on the desktop (still early stages and in alpha I believe)... JavaFX is mostly orphan right now. Oracle seems to have no interest in it... so it seems to be currently being mostly advanced by Gluon[1], which honestly, does not have the muscle to pull out something competitive with Flutter or Electron.
JavaFX still has fundamental pieces missing... like setting an icon for the app or opening some URL in the system browser[2] (without using horrible hacks, which is what I've been doing - which get you lots of warnings since the module system was introduced, and may stop working soon). Not to mention no support for auto-updates, the fact that jpackage is still in "incubator" stage[3] and intentionally does not have JavaFX-specific features at all (it's just barely usable with JavaFX), the SceneBuilder, which could be such a great tool to develop UIs, similar to Lazarus, but it's nowhere as good, being in about the same unfinished state it was in around 2014, terrible documentation and lack of adoption (most examples you find online are from circa 2015, when JavaFX got a little traction)...
These things all make JavaFX a very hard sell for non-developers apps (if you're a developer who does not mind installing the appropriate JVM version to run the app, JavaFX works quite well - a 1MB jar can give you A LOT of features - one of my apps, my favourite and really useful, is only a 340KB single jar and works on any JVM 8+ - and looks as modern as any Electron app).
It's sad but the best way to get professional apps developed and distributed nowadays seems to be, by far, Electron (because of JS, and its stupid browser-based architecture)... but I am hoping Flutter will break Electron's hegemony soon as I have great experience developing Flutter apps on mobile and the web... Just try the online pad[4] to get a taste of what it looks like! It's amazing.
As in stage.getIcons().add()? Or do you mean for the binary that jpackager produces? I wrap my apps with launch4j which allows that. Then I bundle them with jlink-made JRE (about 60 MB). Works pretty well, total size is ~100MB for the whole app with all the dependencies, (not a Hello World app by any means).
>opening some URL in the system browser
As in getHostServices().showDocument("https://google.com")? Then again, nothing's stopping you from using awt's Desktop class, not sure I understand the problem here.
JavaFX seems like it was a good incremental step over Swing but right at a time when the web’s paradigm (the DOM, a brilliant concept) was becoming popular and was a leap beyond Swing. So JavaFX has the same problem as Windows Vista: too little too late. If we had something like the DOM as a new UI kit, it could be a big hit if done right.
The DOM stitches several useful but unrelated concepts together. Besides just being a tree of composable views:
* You can query elements arbitrarily deep using different patterns (depth, class names, ids, tag names, attribute presence/values).
* You can attach event handlers to arbitrarily deep nodes that you just queried, not just the nodes at the level your "controller" is in charge of creating/updating like traditional frameworks.
* Customizing style and behavior is entirely done via properties and composition rather than subclassing like traditional frameworks.
In that regard I think React Native has much better future than Dart/Flutter, specially with Microsoft backing it now, unless Fuchsia actually gets released.
Flutter is all about being the last opportunity to sell Dart, and I doubt that Chrome (PWAs) and Android (JetPack Composer) teams are that happy about its existence, given the political answers when questioned about Flutter on their own Q&A sessions.
I don't think purely about Dart, originally it seemed to be aimed as a technically more robust cross-platform competitor to React Native. Its implementation has good merit in that regard.
That said, it may well not survive nearly as long as RN will, time will tell.
TornadoFX is just a Kotlin wrapper around JavaFX.
It makes writing apps much nicer, but has considerable cost in terms of even more memory usage and, obviously, due to the Kotlin runtime and lots of Kotlin wrappers for most JavaFX classes, app size.
For anyone interested there will be a virtual meetup 16:th of April 6PM CEST: https://www.meetup.com/sthlm-clj/events/269204900