Die Spiele-Entwicklung mit JavaScript und dem Canvas war eine wirklich gute Zeit... man fühlte sich wie ein Künstler.. man war kreativ und hat kein Geld verdient damit.
einblenden: opacity 0 auf 1
von links: margin-left 100% auf 0%
von-rechts: margin-right 100% auf 0%
wachsen lassen: scale(0) auf scale(1)
schrumpfen lassen: scale(2) auf scale(1)
Ich habe gestern Abend mal eine Animation so wohl als animiertes GIF als auch WebM ausgegeben.
Der Unterschied in der Dateigröße ist schon enorm.
Wenn man also überlegt, ob man auf der eigenen Seite Animationen als GIF oder WebM (selbst der neue Edge wird es unterstützen) nimmt, ist WebM wohl die beste Wahl. Damit es sich wie ein GIF verhält muss man es so einbinden:
Ich zweifel aber immer noch, dass der Aufwand nicht sehr viel höher ist als für eine entsprechende Webapp mit HTML5.
Aber ich habe zur Weihnachtszeit nochmal mit alten Kollegen gesprochen und es ist einfach so, dass wenn man Desktop-Anwendungen mit Java schreiben möchte, JavaFX das Beste ist was man momentan findet. SWT ist wirklich altbackend und Swing wird nicht mehr supportet. Wenn HTML5 keine Option ist ist JavaFX einfach die Zukunft für Java Anwendungen.
Nachdem längere Zeit bei MP4toGIF.com nichts mehr passiert ist, habe ich heute mich noch mal mit neuen Filtern auseinander gesetzt und mir eine Umgebung zusammen gebaut, in der ich mit neuen Filtern experimentieren kann. Es ist schon interessant, wie man mit dem Ändern weniger Parameter sehr verschiedene Effekte erzielen kann.
Die Test-Umgebung findet man unter http://www.annonyme.de/js/filters/. Da kann jeder gerne mal herum experimentieren und versuchen selbst Einstellungen für einen tollen Effekt zu finden.
In den nächsten Tagen und Wochen, werden dann also wohl noch ein paar Filter mehr für MP4toGIF.com entstehen und dort integriert werden.
Die zentrale Render-Function ist sehr einfach aufgebaut:
function render(src, trg, rm, ra, gm, ga, bm, ba, useGreyScale){
var srcData=src.getImageData(0,0,src.canvas.width,src.canvas.height);
var data=srcData.data;
for(var i=0;i<data.length;i+=4){
if(useGreyScale){
var avg = (data[i+0]*rm) + (data[i+1]*gm) + (data[i+2]*bm);
data[i+0]=avg;
data[i+1]=avg;
data[i+2]=avg;
}
else{
data[i+0]=data[i+0]*rm;
data[i+1]=data[i+1]*gm;
data[i+2]=data[i+2]*bm;
}
Ging dann ja doch schneller als erwartet. Der Marketplace wird wohl 2017 geschlossen.
Alle nicht Firefox OS Apps haben sich wohl schon 29. März erledigt. Ich werde dann also meine Einreichungen, die abgelehnt wurden, auch auf dem Stand belassen und keine weitere Arbeit mehr in die Richtung investieren.
Mich würde aber wirklich mal interessieren wie viele Firefox OS Smartphones es auf der Welt wirklich gibt und wie viele diese noch weiter verwenden würden. Einen eigenes Repository zu schreiben, wo Entwickler ihre Anwendungen hochladen oder verlinken könnten. So etwas ist bestimmt in 2-3 Tagen zu machen. Bei nicht gepackten Anwendungen ist es sehr einfach, weil man nur die URL zur Manifest-Datei an eine JavaScript-Funktion übergeben muss. Bezahl-Apps oder Support für In-App Käufe wäre da natürlich nicht drin. Keine großen Freigaben oder so.. jeder lädt einfach den Link oder die Zip-Datei hoch... und andere können sich die App über einen Klick auf einen Button installieren.
So etwas wäre ein lustiges kleines Projekt und Firefox OS ist eigentlich eine tolle Umgebung für Entwickler, weil man keine großen Entwicklungsumgebungen oder ähnliches braucht und ein Firefox-Browser zum Testen vollkommen reicht.
Dafür Apps zu entwickeln hat immer viel Spaß gemacht und ging immer sehr schnell.
Am Ende glaube ich nicht, dass es sich lohnen würde, in das gesamte Firefox OS Ökosystem noch mal Zeit zu investieren. Es ist wirklich schade um das System.
Ich habe den ersten Schritt gemacht und 2 einfache Filter in MP4toGIF.com eingebaut. Man kann nun direkt schwarz/weiß Animationen aus farbigen Ausgangsmaterial erstellen. Auch eine Farbgebung, die etwas "vintage" aussieht.
Die Filter basieren auf dem Code den ich hier schon mal vor einiger Zeit veröffentlicht habe. Alles natürlich HTML5 Canvas basiert.
Mit der Zeit werden noch ein paar mehr Filter folgen.
A simple file-upload is easy to implement. A input-tag of the "file"-type. Set "method" to "post" and let the action attribute point to the target-page. Don’t forget enctype="multipart/form-data" and every thing is finished.
This implementation is very limited and in modern Web-Apps you want to do more than simply upload files. You want to scale, rotate and process the image. You want to see the progress of the upload and upload more than one file at once in the upload-queue. A few years earlier you had to use flash.. but flash is dead. Today we use HTML5 + JavaScript. With ist you can do what ever you want to do. The File-API helps you to load local files per input or drag and drop. A web-notification informs you when the upload is finished… very helpful if it is a very large file.
This file-upload that is created in this posts is not perfect, but it works in many of my projects and scripts. The target-script can be implemented very easy in PHP or as a servlet.
For a simple test you can use this PHP-script:
PHP:
<?php
//see $_REQUEST["lastChunk"] to know if it is the last chunk-part or not
if(isset($_FILES["upfile"])){
file_put_contents($_REQUEST["filename"],file_get_contents($_FILES["upfile"]["tmp_name"]),FILE_APPEND);
}
?>
for Java you can use this (FileIOToolKit is a class of my own, it simply adds a byte[] to the end of a file or creates the file, if it doesn’t exist):
String filename = request.getParameter("filename");
for (Part part : request.getParts()) {
if (part.getName().equals("upfile")) {
byte[] out = new byte[part.getInputStream().available()];
part.getInputStream().read(out);
As you see, the files aren’t uploaded at once, but in multiple parts. So ist is very easy to track the progress of the upload.
To load a file in HTML5 is very easy. Drag and drop or the OnChange-Action of a file-input element delivers you a event, that contains a list of files.
Here is simple example to get the files from the event. The two events from the input and the one from the drag and drop are different.
var files = null; // FileList object
if(!nodragndrop){
files=evt.dataTransfer.files; //input
}
else{
files=evt.target.files; //drag and drop
}
But we don’t care about this part of loading and starts where we have the file-object. You also can create a binary-blob from an data-URL (from a canvas for example).
Keine Ahnung ob es schon zu früh ist, aber irgendwie klingt es doch sehr danach als wäre Firefox OS gescheitert. Gefühlt war gerade in den letzten Monaten erst wieder Bewegung in den Firefox OS Markt gekommen. Die Installationszahlen meiner Apps gingen jedenfalls mal wieder nach oben und dümpelten nicht ewig lange auf einem Level herum.
Ich hatte sogar überlegt, doch noch mal die Apps dort wieder zu überarbeiten und vielleicht auch mal was neues dafür zu beginnen, auch wenn ich Projekt-technisch doch sehr ausgelastet bin. Ok Firefox OS hatte bei der Wahl eines neuen Primär-Smartphones keine Change und ich habe mich dann für ein Lumia mit Windows entschieden, aber dennoch hatte ich mal geguckt, was da so angeboten wird. Auch außerhalb des absoluten low-Price Segements und etwas mit besserer Kamera. Gab es leider nichts.
Ich finde es durch aus schade, weil es wirklich einfach war Apps dafür zu erstellen. Meistens musste man eine vorhandene HTML5-App nur um die Manifest-Datei ergänzen und schon war die App fertig. Man konnte zwischen gehostet und gepackt wählen, wobei viele Benutzer wohl gepackte Apps vorzogen, um Traffic zu sparen. Der Vorteil ist auch, sollte der Firefox Marketplace zeitnah keine Apps mehr anbieten (was wir mal für die Smartphone-Besitzer mit FFOS-Smartphone nicht hoffen wollen), kann mit wenig Code selbst noch eine alternative bauen. Etwas JavaScript und eine URL auf die gehostete Manifest-Datei und schon ist der App-Store fertig. Gepackte Apps sind ähnlich einfach zu installieren.
Zu Wünschen wäre meiner Meinung nach, dass sich das App-Format irgendwie durchsetzen kann und man auf die selbe einfache Weise HTML5-Apps für Android, Windows Phone oder iOS anbieten könnte.
Von kompletten Neuentwicklungen werde ich wohl nun absehen, aber meine alten Apps auch weiterhin pflegen. Denn Firefox OS ist ja nicht tot.. nur nicht mehr kommerziell.
A few month ago, i wrote a post about the situation between JavaFX and HTML5 and their positions in the fight for the next leading GUI-technology in the Java world. I said, JavaFX is only interessting to improve existing Swing application but not the right thing for the developing new applications.
I can fully agree to this point of view. There are greater problems than the technological difficults and the few bugs and problems with the implementation of some JavaFX parts. The greatest problem is the missing support by Oracle. JavaFX for mobile devices is only supported through 3rd party solutions like RoboVM. Scene Builder is not very stable or bugfree. With only simple changes in a FXML, you can cause troubles that Scene Builder is not able to ... it crashes or only shows an empty screen.
You have to wait month for new versions or simple bugfixes.
Oracles own applications use Swing or are webbased. The change from Swing to JavaFX was often proclaimed, but never came to the surface or was visible in any other way. Swing has an extensive repository of mature and feature-rich components. It isn't easy to replace them in a short time range. A simple migration isn't that simple and would took a lot of work. You know that you can open JavaFX scenes in a SWT application. I used it, but it isn'T realy a good integration. It is only a canvas, where the JavaFX scenes is drawn on. No real interactions between the two worlds. It like the WebView in JavaFX. Yes you could write an application in HTML and JavaScript an use JavaFX as an wrapper.. but.. why? An IE11 should be a better solution than this.
The usage of Swing disappeares slowly, but there no new JavaFX applications to repalce them. There are a few JavaFX fans, but i think they only exist, because Swing is deceasing. Since i begin to programm in Java i wrote a few Swing applications and the first contact with JavaFX was more than disillusioning. Netbeans + Swing working great and every thing works very well. Scaling of the GUI works good. In JavaFX you can implement it too, but it isn't as intuitive as with Netbeans. The CSS-implementation in JavaFX is not comparable with the CSS we know from HTML.
Why JavaFX 2 wasn't accepted well? In my oppion, the reputation was bad, the support was insecure in version 1.0.
When version 2.0 arrives, most developers found a other or better solution with better support and more promising future. So the support from the developer-side was missing and without this every thing only works on a minimal level to save the resources for more promising projects.
JSF 1.x wasn'T that good, but there was no doubt, that it will be supported an new version will be developed. I think that Apache supported JSF, was a big advantage. And the newest versions are great. Maybe JavaFX can go the same way with more support.
So i support the conclusion: If oracle will invest more resources in JavaFX more developers show interest and so it could be a future with JavaFX.
I can't understand the fear that without JavaFX the JEE market could be damaged or it can lose it's impact in the developer-environment. Node.js could be a threat, more than php, but in the last years the JEE-market grow with microservices, middleware-services for android-apps, reactive-development and frameworks like node.js. REST-services, web-portale-solutions, small containers, websockets und push-services in the Tomcat servlet-container. Very nice and the movement doesn't stop till now. The big Topics of the last years.. Desktop-GUIs wasn't a topic. And with the great Java webframeworks, HTML5 and AngularJS the client-side won't be losed. JEE and Web-Clints work great together.
The lose of a few desktop application won't hurt, when you get new shiny web-application based on Java technology.
Vor ein paar Monaten hatte ich einen Post über JavaFX und die Konkurrenz zu HTML5 geschrieben. Und dabei das Fazit gezogen, dass JavaFX gut ist um vorhandene Swing-Anwendungen zu erweitern und in Zukunft zu modernisieren, aber für Neuentwicklungen ich eher eine andere Technologie nutzen würde.
Jetzt gab es bei JAXenter den Artikel Ruhe in Frieden JavaFX, wo ähnliches Thematisiert wird.
Die dort angesprochenen Punkte kann ich meiner Erfahrung nach voll zustimmen. Die technischen Unzulänglichkeiten und Probleme sind nicht mal das eigentliche Problem, denn die Unterstützung von Oracle scheint wirklich kaum vorhanden zu sein. Mobile-Unterstützung gibt es nur dank der RoboVM. Der Scene Builder ist relativ instabil und durch händische Anpassungen schnell aus dem Tritt zu bringen. Updates und neue Versionen, die das Problem beheben, waren bis Sommer jedenfalls nicht verfügbar gewesen.
Die Programme von Oracle setzen auch jetzt meistens noch auf Swing und nicht auf JavaFX. Der große Wechsel wurde zwar an vielen Stellen beschworen, aber war nie sichtbar. Swing hat auch zum Großteil sehr ausgereifte Komponenten und die Anwendungen sind über viele Jahre gewachsen... da ist ein schneller Wechsel nicht möglich und eine einfache Migration ist auch nicht machbar. Anwendungen komplett auf JavaFX umzustellen ist viel Arbeit. Ich habe gesehen, dass man gut SWT und JavaFX in einer Anwendung verwenden kann, aber wenn man es nüchtern betrachtet, wird auch nur eine JavaFX GUI irgendwie in SWT rein gezeichnet. Eine echte Integration gibt es nicht. 2 Welten die in einer Anwendung existieren.
Es gibt also weniger Swing, aber nicht mehr JavaFX. Es gibt ein paar JavaFX Verfechter, die es aber wohl auch nur gibt, weil Swing ja irgendwie abgekündigt wurde. Ansonsten wären alle wohl einfach bei Swing geblieben. Ich habe auch seit meinen Anfängen in Java ein paar Swing-Programme geschrieben und empfand den ersten Kontakt mit JavaFX als sehr ernüchternd. Netbeans + Swing funktioniert einfach sehr gut und auch das skalieren der GUI-Element funktioniert relativ gut. JavaFX kann es zwar auch, aber die Bedienung ist hier weniger selbsterklärend und das CSS ist weit von dem entfernt, was man sich erhofft hatte und aus dem Web-Bereich gewohnt ist.
Das mit der Version 2 von JavaFX kein großer Anstieg der Nutzerzahlen kam, liegt meiner Meinung auch daran, dass JavaFX einen schon sehr schlechten Ruf hatte und Jahre auf der Kippe stand.
Als dann eine brauchbare Version kam, hatten die meistens sich schon anderweitig umgesehen und etwas mit Zukunft und größerer Unterstützung gewählt. Das Problem ist damit eben, dass JavaFX dadurch nicht mehr die Unterstützung bekommt, um weiter wachsen und sich entwickeln zu können. So wird alles auf einem minimal Level betrieben. Wenige Nutzer.. wenige Entwickler.
Betrachtet man dagegen JSF was mit der Version auch nicht das Gelbe vom Ei war, aber immer offizielle Unterstützung bekam (auch von Apache) und somit man auch Vertrauen in die Zukunft hatte, das sich gerade mit den neusten Versionen auch als gerecht fertig erwiesen hat. Vielleicht würde auch JavaFX mit breiterer Unterstützung sich genau so gut entwickeln können.
Ich kann mich dem Fazit voll und ganz anschließen: Sollte Oracle nicht plötzlich viel in JavaFX investieren, sollte man lieber sich etwas mit mehr Unterstützung suchen und auf eine ungewisse Zukunft vertrauen.
Die Angst dass der Java EE Markt dadurch gefährdet wird. Node.js ist vielleicht eine größere Gefahr als PHP, aber die letzten Jahre basierte der Wachstum und die Stabilität von Java EE nicht auf Swing oder dem Desktop-Markt. Microservices, Android-Apps, Frameworks für Reactive-Entwicklung oder gleichwertige Lösungen als Alternative zu Node.js. REST-Services, Portale und kleinere Container. Auch die WebSocket und Push-Services im Tomcat. DevOps Lösungen. Alles tolle Entwicklungen im Java-Bereich.. es gab viel Bewegung und Fortschritte, aber keiner davon hing groß mit der Entwicklung von Desktop-Clients zusammen. Ich glaube der Rückgang bei den Desktop-Clients ist normal und Dank Java Web-Frameworks, HTML5 und AngularJS oder ähnlichen Frameworks, muss sich die JEE-Welt keine Sorgen machen.
Aber ich fühle mich gerade sehr in meinen Ansichten und Äußerungen von vor einem halben Jahr sehr bestätigt :-)
Ein kleines Beispiel wie man sich eine eigene Validierung für Inputs in JavaScript basteln kann. Man kann es natürlich beliebig komplex machen und es sollte auch super mit Ajax funktionieren. Nur mit nicht required Inputs habe ich so mein Problem, da ich die gerne in neutraler Farbgebung hätte, wenn nichts eingegeben ist. So wären sie momentan einfach "valid" und damit grün. Falls dort jemand eine Lösung kennt, wäre es echt toll.
Jetzt läuft auch alles im Microsoft Edge. Das Problem war dass das "canplay" Event im Edge nicht bei einem Wechel der Zeit gefeuert wird wie beim Firefox oder Chrome. "timeupdate" löst aus bevor das Bild verfügbar ist und sorgt für ein ruckeliges GIF. Die Lösung war: seeked. Damit läuft MP4toGIF.com jetzt im Edge, Chrome und Firefox.
So.. nach ich gelesen habe, dass Facebook GIFs zulassen will und man für MP4 bald zahlen muss und WebM damit vielleicht interessanter wird, habe ich MP4 to Gif mal geupdatet. Das Ergebnis wird jetzt nicht mehr in einem neuen Fenster geöffnet (was man ja immer extra bestätigen mußte, damit das Fenster geöffnet werden durfte) sondern in einem eigenen Dialog.
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).
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.
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.
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?