I had hopes for JavaFX as well.
But I dont see it soing places anymore without massive corporate backing. All the secondary APIs are pretty much clean-room designed and lack some consumer-developer insight on how its used. I encountered missing API surface, missing layout logic, huge feature holes etc.
The WebView is just unusable. It segfaults the JVM if you use it wrong, and I had like three different ways I did that. It is practically impossible to control the behaviour of the navigation and Network fetching, which I really need to do.
Also it is just way to slow. All the widgets are coded like they are the only thing the app is for and contain huge object trees for the simplest blip. CSS support was (there have been efforts lately) just very clunky and half done.
Passing Events to/from a backend to the UI Model is still very clunky because of the Single Thread thing of the UI. It collides with the Binding semantics, which only really work inside one thread.
It really needs a slim down, and lots and lots of elbow grease to polish it into a state where it can be the base of a nice and big ecosystem.
The Design itself is rather modern and feels OK with Java8.
I pretty much agree with most of this with the exception of the single thread comment as all modern UI toolkits (and most old toolkits) are single threaded.
I'd like to add that the deployment was also a nightmare as javafxpackager is horribly broken in many small ways. Basic things like support for UWP targets or modern UI on Windows (not the look actually running in the metro environment) is missing. Integration with Swing is horrible, for the life of me I can't understand why this wasn't the first thing implemented in FX and why it has a separate thread from the Swing main thread...
Looking at the history of programming only one scene-graph API ever gained major traction and that was Flash. It did that thanks to amazing tooling from Macromedia that mostly hid the fact that it was a scene-graph API.
SVG failed as an API (it has moderate usage as a file format but not as popular as the newer Canvas API). iOS has a sort of Scene-Graph API in core-animation but that isn't used as much and it's really simplistic. Most samples mention the immediate mode API, OpenGL or Metal.
There is XAML which isn't exactly a glaring success either... I think it's time for the scene-graph folks to admit that it looks good on paper and can be pretty amazing, but the "market" has spoken... Repeatedly.
Scene graph is nice but when something performs badly you have no clue, too much happens "under the hood" and developers don't like that.
Yes, the single threaded design is the way to go. The authors elaborated their position on it and understandably came to the conclusion that multi-threaded updating support will just explode the complexity. But since they obviously thought about this Problem, I don't understand why this issue does not get more attention API wise.
There is the javafx.concurrent package, but that just gives you the low-level stuff Tasks/Futures. But what I really want is property binding ( or something more declarative than manually hooking Task-lambdas everywhere ) between the backend threads (which are mandatory since you don't compute in the UI thread) and the UI. You end up duplicating your models because this is really hard otherwise, even though you might only have a viewing App with little logic and could just use the JavaFX Observables as your model properties. Then you have 2 models (MVVM yay) which need to be synchronized, and right now its just loads of Platform.runLater wrapped lambdas everywhere.
So the platform kind of forces the MVVM thing, but does not give you much support of doing it in an idiomatic or clean way.
I dont really have a good solution for this either, I think DataFX goes there but I have not tried it.
But this is all really criticism on a rather high level. I did some cocoa stuff, and my hair fell out. Id rather wrangle JavaFX than cocoa any day.
One irony regarding JavaFX is that the original JavaFX Script language[1] was probably among the best frontend languages ever created (better than TypeScript or Elm in many ways, IMO). It is powerful, typed, and easy for JS developers and designers to learn, plus it's designed for CSS integration. When it was abandoned by Oracle (good decision), it was forked [2], maintained and improved for some time, and then withered. I hope someone would take it[3] and write a JavaScript/HTML backend. It has pretty good tooling (IDE support) that could probably be used.
In my head it was destroyed by trying to improve it.
IIRC the first versions just worked and was amazing with live scripting etc. I even made an applet that was popular for a while.
Newer versions added more and more complexity before you could get anything done (again IIRC).
Feels a lot like Symfony: started small and focused and ended up as multiple smaller projects including a dependency inversion container but at some point along the road the magic was lost.
I wonder how did javafx script work. I mean, I could see it working for a very simple application with a few widgets, but a full-blown application? I mean, you'd have to write the entire application in pseudo-javascript, and most calls would be to Java standard library which would look ugly (just as Nashorn JavaFX code does)...
It's always interesting to see the only people who ever talk about JavaFX are either Oracle employees or people who have a financial interest in JavaFX, such as the author of this piece whose business is based on JavaFX.
Oracle effectively killed Java with the Android lawsuit. Java's original selling point was to not be tied to a single vendor's platform. Now Oracle wants to be the single vendor. So long and thanks for all the fish.
I'm not sure what this comment is trying to insinuate? I mean sure they might have a financial interest, but they're also writing about stuff they know well since they use it.
Basically that talk about and use JavaFX are those with a vested interest in JavaFX as a platform in and of itself. Rather than hearing from people who are more interested in the programs that you'd make with JavaFX.
The connotation is that there isn't much adoption of JavaFX outside of a small (Sun/Oracle-centric) group, which has largely always been the case with JavaFX.
a few months ago I wanted to write a small desktop app which i wanted to distribute for Linux, mac & window in that order of priority. My first implementation was in Qt but faced significant problems with building for different platforms, providing binary files that would just work, etc.
JavaFx was the next choice and damn the development experience was amazing, it was fun to write even when i had no prior experience with either Java or JavaFx but distribution became a problem again, the JavaFx classes weren't found on other peoples systems, people in the javafx irc told me that it should be available for everyone on jre 1.8 but alas no solution was found.
I finally shipped a electron app (shudders)
p.s. i found the javafxpackager but it didn't work, i am doing something wrong definitely but there aren't enough people talking/writing about this that i could refer too.
>Throw in RoboVM who successfully AOT compiled Java byte codes to native Objective-C to facilitate Java running on iOS and others who contributed to the Android port, and we were now ready to take on the world!
must be a rule that the vast majority of informational sites, blog sites, tutorial sites regarding Java look hideous. Looking up tutorial sites on JSF, this 'great' front end coding framework and there's not one site that can manage a nice looking website, not even barebones nice. All are hideous.
The WebView is just unusable. It segfaults the JVM if you use it wrong, and I had like three different ways I did that. It is practically impossible to control the behaviour of the navigation and Network fetching, which I really need to do.
Also it is just way to slow. All the widgets are coded like they are the only thing the app is for and contain huge object trees for the simplest blip. CSS support was (there have been efforts lately) just very clunky and half done.
Passing Events to/from a backend to the UI Model is still very clunky because of the Single Thread thing of the UI. It collides with the Binding semantics, which only really work inside one thread.
It really needs a slim down, and lots and lots of elbow grease to polish it into a state where it can be the base of a nice and big ecosystem.
The Design itself is rather modern and feels OK with Java8.