On: JavaFX: Call to ARMs

[invalidname]

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.

[ysleepy → invalidname]

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.