
JavaFX: Call to ARMs - youjiuzhifeng
https://justmy2bits.com/2016/03/12/javafx-call-to-arms/
======
ysleepy
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.

~~~
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
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.

------
pron
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.

[1]:
[https://en.wikipedia.org/wiki/JavaFX_Script](https://en.wikipedia.org/wiki/JavaFX_Script)

[2]: [http://javafx.steveonjava.com/accouncing-
visage/](http://javafx.steveonjava.com/accouncing-visage/)

[3]: [https://github.com/visage-lang](https://github.com/visage-lang)

~~~
reitanqild
I also miss JavaFX Script.

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.

------
pjmlp
For our customers it is all about WPF, Qt and Xamarin.Forms.

The few customers that still require Java desktop applications have no desire
to move away from Swing.

I really don't see a bright future for JavaFX.

------
incepted
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.

~~~
jmcdonald-ut
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.

~~~
mbreese
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.

------
aksx
disclaimer: I am not a java developer

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.

------
bitmapbrother
>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!

I wonder if he knows the fate of RoboVM.

------
geodel
With Oracle increasingly looking to win in Oracle vs Google court case JavaFX
might have future after all.

------
crudbug
Oracle can revive JavaFX, if they develop something like ReactFX, JavaFX
target React. They have all the infrastructure with Nashorn, SceneGraph, etc.

------
michaelbuddy
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.

~~~
bitmapbrother
Incompetent people always blame the tool. It would seem your issue has more to
do with design which JSF has nothing to do with.

