Ich durfte jetzt doch einige Monate mit JavaFX für den Client meiner Anwendung verbringen. JavaFX wurde mir gegenüber jeden Falls als der große Heilbringer beworben. Es wäre Swing, SWT und HTML5 weit überlegen. Es wäre schneller und würde Oberflächen ermöglichen die mit HTML nie möglich wären (im besten Falle mit Flash) und würde auch einfach Dinge können, die mit HTML5 unmöglich wären.. Drag and Drop zum Beispiel.

Weitere Vorteile wären, dass man es im Web verwenden könnte, weil es ja als Applet liefe und man könnte es ohne Probleme auf Tablet laufen lassen. Mit VMs von Drittanbietern sogar auf iOS. Android sowie so.

Die Logik meiner Anwendung ist komplett in einem REST-Service implementiert und somit macht der Client wirklich nur eine Sache: Daten und Masken darstellen.

Ein weiterer Vorteil soll auch sein, dass man super einfach selbst Oberflächen zeichnen könnte und man somit nicht auf fertige Komponenten angewiesen wäre. Und das aller Beste wäre FXML wo man die Oberflächen mit einem GUI-Designer bauen könnte und keinen Code schreiben müsse. MVC und Templates. Auch gäbe es super viele Hilfen im Internet.

Also wäre noch auf HTML5 setzen würde, würde auch schlechte und veraltete Technologie setzen.

Jetzt nach dieser Zeit mit JavaFX weiß ich eins, der viel beschworene HTML5-Killer ist JavaFX bei weitem nicht. JavaFX hat noch unglaublich viele Bugs und Probleme. Es killt sich eher mal selber als HTML5. Aber gehen wir die Argumente einfach mal durch:

* HTML5+CSS5 sind sehr viel flexibler was GUIs angeht und der Code ist immer noch vom Menschen lesbar. FXML ist alles andere gut lesbar. JavaFX als Java Code ist da deutlich angenehmer als FXML.
* Flash ist tot und das aus gutem Grund. Selbst Oracle sieht in JavaFX keinen Flash-Ersatz mehr.
* Drag and Drop.. funktioniert in HTML5 sehr viel besser und mit einigen wenigen Zeilencode. Wenn mir jemand erzählt, dass es mit JavaFX in gerade mal 1000 Zeilen-Code nun alles super läuft und ich sehe dass man dafür in HTML5 vielleicht 20 Zeilen gebraucht hätte, kommt mir der Aufwand in JavaFX unglaublich groß vor.
* Applets.. ja.. wer hat das Java Plugin im Browser noch aktiv? Kaum jemand. Applets waren um 2000 rum beliebt. Wer heute noch Applets als tolle Möglichkeit verkauft Java und das Web zusammen zubringen hat die letzten 15 Jahre verschlafen.
* JavaFX und Tablets... HTML5-Apps auf Mobilengeräten sind seit einige Jahren alltag und verdrängen immer mehr native Apps. JavaFX-Unterstützung wurde erst Anfang des Jahres aus der ARM-Distribution des JDK entfernt. RoboVM soll gut laufen, aber an die optimierten Render-Engines wie Gecko oder WebKit wird eine einzelne kleine VM nicht so schnell rankommen. Da zählt auch einfach Erfahrung+Man-Power und da sind Web-Browser sehr weit vorne.

Oft hat man das Gefühl als die Wahl für JavaFX vieler nicht darauf basierend, dass JavaFX besser wäre sondern einfach auf der Ablehnung von JavaScript. Dann kommen Argument wie dass es nativ ja viel einfacher wäre auf System-Resourcen zu zugreifen... mit HTML5 ist der Zugriff auf die Kamera eines Devices sehr viel einfacher als in JavaFX (dank WebRTC).

http://de.slideshare.net/rcuprak/javafx-versus-html5-javaone-2014

JavaFX ist ein tolles Grund-Framework, aber man muss jeden kleinen Furz mehr sich selbst implementieren. Bei HTML5 ist einfach sehr viel schon mit bei (datalist für autocomplete Inputs, Inputs vom Typ "number", AJAX, gegen CSS3 ist das CSS von JavaFX garnichts). Auch das Argument "man muss ja nur einmal implementieren" ist an sich unsinnig, weil auch es kein Mal implementieren zu müssen immer noch weniger Zeit braucht als es einmal zu implementieren.
Eine vorhandene Maske hübscher zu machen dauerte bei jemanden 6h. Mit dem Vorwissen meinte er, er bräuchte nun nur noch 2h. Mit HTML hätte man ca. 20min gebraucht. Ich habe viele Masken auch noch mal in HTML nachgebaut und habe jeweil nicht Stunden sondern Minuten dafür benötigt und sie sahen dafür dann gleich gut aus.

Ein weiteres Argument für JavaFX ist immer wieder dass es eben Java ist. Java ist nicht dynamisch Typisiert was in JavaScript-Anwendungen ja immer zu Problemen führen würde. Diese Probleme konnte ich in den letzten 2 Jahren nicht mehr groß erleben. Besonders bei einem Client für einen REST-Service wo sowie so alles als String in der URL oder im Request landet ist es Ausgabe des Services die Konvertierung in die Datentypen zu übernehmen. Ich hatte bei dem Projekt nicht an einer Stelle ein Problem, dass JavaScript Zahlen und Strings verwechselt hätte.

Für JavaScript gibt es unendlich viele Frameworks. Besonders AngularJS ist hier zu erwähnen. Nun gibt es ja die Behauptung von JavaFX als HTML5-Killer, der HTML5 schon "sehr bald" überflüssig machen werde. Auch hier laufen die Argumentation meist darauf hinaus, dass JavaScript schlecht sein und Java soviel besser. Auch ansonsten sind die Argumentationen sehr interessant.

https://jaxenter.de/javafx-ist-stabiler-als-html5-und-angular-18526

Wenn man diese Argumentation nun nach vollzieht, ist die Aussage grob, dass JavaFX in seiner jetzigen Form länger bestehen bleibt, als bis AngularJS 2.0 released wird (AngularJS 2.0 wird AngularJS 1.x nicht direkt ersetzen), weil einfach bei JavaFX keine große Weiterentwicklung in nächster Zeit erwartet wird.
Ob das jetzt ein Vorteil ist.. da bin ich mir nicht sicher. Weil dann wären nur tote Technologien stabile Technologien.

Seit neusten unterstützt JavaFX nun auch endlich Dialoge. Es hat lange gedauert.

FXML... das ist noch etwas, wo ich mir nicht sicher bin was es überhaupt bringen soll. Es ist keine brauchbare Template-Lösung, da man die Bindings immer noch im Controller machen muss und auch das Befüllen der Komponenten nur im Java-Code möglich ist. Was man mit AngularJS direkt zusammen mit dem HTML-Code schreibt, muss man bei JavaFX also einmal zum Teil im FXML und zum anderen Teil im Java-Code machen. Einträge aus ResourceBundles lassen sich nur sehr schlecht verwenden, weil man diese nicht mit einfachen Strings mischen kann. Ausdrücke wie title="%time (%time_format)" funktionieren einfach nicht. title="%time_and_time_format" wäre mögich.

$http.get().success() durfte man sich so halb-brauchbar nachbauen. Aber immer hin hat JavaFX eine gute Lösung für asynchrone Vorgänge implementiert (Task), damit man Änderungen an der GUI relativ einfach trotz Berechnungen und Abfragen in einem anderen Thread durchführen kann.

Und Hilfe findet man für JavaFX meistens nicht so einfach. Für FXML sowie so so gut wie gar nicht. Wo für HTML5 oder AngularJS Probleme spätestens der 2 Eintrag bei Google eine Lösung liefert, kann es sein dass man bei JavaFX nur Verweise auf deren Bug-Tracker findet.

Insgesamt fühlt sich Entwickeln mit JavaFX an, als würde man gerade an einem Beta-Test teilnehmen. Vieles geht schon, aber es gibt noch grundlegende Bugs und einiges Fehlt auch einfach. Dokumentation ist oft nichtssagend und bei Problemen sind Lösungen oft noch einfach unbekannt.

Am Ende würde ich allein der Entwicklungszeit möglichst immer HTML5+AngularJS JavaFX vorziehen. Wer JavaScript immer noch aus einem Blickwinkel von vor 10 Jahren betrachtet, verpasst viele Entwicklungen, die JavaScript Ding ermöglichen, die vor einigen Jahren niemand für möglich gehalten hat. JavaFX hat mich nur unnötig viel Zeit gekostet und war nicht ansatzweise der Heilsbringer, der es sein sollte. Wäre JavaFX 2 rausgekommen als JavaFX 1 rauskam, wäre es eine echte Alternative für RIAs gewesen. Aber so kommt es einfach viel zu spät und würde schon von vielen anderen Technologien überholt. Wenn man eine vorhandene Java-Anwendung in SWT oder Swing um neue Oberflächen ersetzen will, ist JavaFX toll, aber eine neue Anwendung, die nicht nativ laufen muss, sollte eher portabel in HTML5 entwickelt werden und kann dan auch Desktops und Tablets laufen.

Das ist jeden Falls meine Meinung zu JavaFX.