The one question that JavaFX aficionados like myself are facing over and over again is the question when (or why) to use JavaFX instead of HTML (5). Here are my two cents on it:
You should use JavaFX if ….
- … you are interested in robustness / quality. JavaFX is Java! You will be able to implement your entire application with the same language / technology. This has a direct impact on the people and the skill sets that you have to have in your team and also on the robustness and quality of the application. The more you have to switch between different languages the more likely it is that you will loose control over the overall solution. HTML applications typically consist of HTML, JavaScript, CSS, and Java (on the server). JavaFX applications consist of FXML, CSS, and Java. Only one language less? Doesn’t sound like much? Have you programmed in JavaScript? This leads me to my next bullet:
- … you hate JavaScript. Welcome brother / sister! That’s a no-brainer.
- … you want to focus on programming, best practices, patterns, and not constantly reading up on the latest development in web framework development.
- … you want to save money. There are not many developers out there that are equally proficient in Java and in Javascript. It is usually either / or. So you end up paying two people where you could have gotten away with just one.
- … your application and its business logic is very complex. A very good example for this category of applications can be found in the planning and scheduling domain. These applications have to be able to provide detailed feedback and guidance directly in the front end. Implementing this with HTML and an untyped scripting language like JavaScript would be a nightmare. Read also here: European Broadcasting Union
- … your data volume is huge. Yes, killer argument right there. Try playing around with Gigabytes of data inside your browser. Enjoy! Again, scheduling applications tend to load a lot of data into their UI, otherwise the planner / scheduler / dispatcher would not be able to make informed decisions. Read also here: Emirates Airlines
- … you are interested in long-term sustainability. The technology deployed in web applications is subject to frequent change and so are the browsers themselves. You will have to stay up-to-date with both and keep supporting your application during its life-span. Creating a JavaFX application and shipping it with a Java runtime ensures that your users will be able to run the application for a long time. Read also here: HRC-Matic Trade Registry
- … you want to support mobile / apps. HTML on mobile devices is a work-around, nothing else. Users want apps! This is simply a fact. With JavaFX and technology provided by Gluon you can write a JavaFX application that runs on desktop, mobile, and embedded. This leads me to another point:
- … you want to run an “embedded” application: software and hardware are forming a single solution and solve a specific problem. A browser makes no sense in this scenario whatsoever. Example: full screen rich client solution with a modern look and feel and running on wall-mounted consoles in an operating room. See also: EIZO Curator Caliop
- … you enjoy working with an elegant and modern API. The architecture of JavaFX, its controls, skins, and property binding concepts, are simply beautiful and a great place for learning how to code well. Kudos to the entire JavaFX team. You have come a long way since version 1.0.
You should not use JavaFX if …
- … you have millions of users and you have to be able to deploy frequently / daily. An application like Facebook probably would not be a good candidate for JavaFX. You can hardly expect your users to download a new installer every time you introduce a new feature, bugfix, security patch. A good example would be the Flash player. Who isn’t annoyed by the constant updates that are needed because of yet another security issue?
- … (open for suggestions, please email me).
Seriously?
I’m no fan of JavaScript but if any of that was true why isn’t Oracle migrating its apps to JavaFX?
Not even the Swing based apps…
Why did they move the developers who are working on FX to “do other things” and fired a rather large IoT FX team (not to mention all the evangelists).
To your points:
robustness / quality – we use JavaFX for the browser component which is awful and crashy. The media API is ridiculous (doesn’t even support https).
JavaScript – I don’t like JavaScript either. But at Codename One we use TeaVM for our JavaScript port and it works. Well!
No security bulletin or buggy webstart/fxpackager/applet nonsense. Deployment in FX has somehow become worse than Swing deployment which is something I didn’t believe possible.
you want to save money – I would partially agree with that. However, being a consultant for quite a few years I can tell you about a former customer of mine which is a major bank around here that was walking around seeking any Swing consultant willing to help them workaround bugs in Swing and i18n. They couldn’t find anyone at any price (I was busy with Codename One). FX has less experts than Swing had and since it never picked up the likelihood of finding an expert is quite low.
application and its business logic is very complex – That’s why we have TeaVM/GWT, server side code etc.
data volume – this is a problematic claim to make. Yes Java can handle HUGE data sets. But FX is problematic with its display because of the scene graph, e.g. charts with real large data sets go haywire. Its the one semi “fair” point of the bunch and even then I would use something other than FX for the data display e.g. Google works with huge datasets with bigquary which runs on the server, it displays the data via JavaScript just fine using search, paging and charts. You would probably need to do the same with FX.
you are interested in long-term sustainability – that is a crock. All of us stuck with Swing code that barely gets bug fixes can’t wait to have the same with FX. Hell even file choosers stopped working for some Windows versions with no fix in site a couple of years ago. We had to go back to AWT for that…The web is moving forward and is maintained.
support mobile – as a guy who does mobile this boils my blood!
Oracle couldn’t get FX to work on mobile. I’m VERY familiar with the problems involved and Gluon is a non-product with no real shipping apps. Basic things like heavyweight/lightweight integration, sub pixel anti-aliasing etc. become HUGE problems in mobile. Getting all that to perform is hard enough, getting it to work when Apple moves the goal posts every year is impossible, impractical and unsustainable.
I don’t think PhoneGap is a good solution, but it has billions of installs… Get to 100k installs or to our 120M installs first.
Embedded – one of the most brilliant engineers I know was running the embedded FX effort at Oracle. He got canned because he and his team weren’t in the USA. I have zero faith on Oracles ability to execute on this when faced with the Android juggernaut.
I will not make any additional remarks regarding Shai’s comments but I would like to mention that Shai obviously has his own agenda regarding technologies that are competing with his company’s product. To be completely fair I also have to mention that I am obviously opinionated, too, and that I have my own interest in the success of JavaFX as my freelancing work and two of my three frameworks are based on this technology.
You mistake our product for a bias against JavaFX. It isn’t.
We use FX for our desktop builds and don’t compete with it, I want it to work properly because there is no other alternative API right now (don’t get me started on SWT).
I’m an ex-Sun/Oracle guy so I’m friends with a lot of the FX team and I think they are brilliant people who were mismanaged by Sun. This is the source of most problems in FX.
We could support FX in Codename One and actually talked several times with Oracle execs about doing this. These talks led nowhere and I got the impression that Oracle doesn’t really care about FX to put an effort there.
I think that if you REALLY want to fix FX you need to look at its problems and address them realistically. Unfortunately right now Oracle doesn’t have anything on the table other than FX and with all my personal desires, Codename One isn’t an FX replacement and won’t be for most use cases (e.g. NetBeans won’t be rewritten in Codename One).
I don’t like Gluon in the same way a doctor wouldn’t like a snake oil salesman. We’ve been doing cross platform mobile development for more than a decade and even basic things are problematic with their approach e.g. cell networking in iOS is only activated by the Objective-C layer… That’s one of those things that’s impossible to discover unless you have a really narrow API or the TCK team we had at Sun.
I think the only problem with FX is Oracle !
so I agree with Shai, Oracle doesn’t really care about FX, I started to realize that since they have withdrawn their support for JavaFX Embedded !
I don’t know what your (the author’s) experience with developing real-world applications in JFX was. Maybe you hit a sweet spot (a form-based ui with not much serious graphics on Windows?). I can only support the overall impression Shai conveys in his post (in his blog and in comments here) on this topic (backed by a lot less insight, of course) because we have really desperately wanted JFX to be our future technology for our swing-based product and we did not have to evaluate for very long to run in serious bugs in almost every area we touched with things being especially bad on the Mac platform. And that contained all categories of deficiencies, i.e. among other things
– unusable graphics performance
– lack of obvious features
– apis not working as they are documented
– apis feeling unfinished (I cannot determine which table row was just scrolled into visible range???)
– bad quality (rendering defects like bad flashing when opening a dialog)
Our agenda is simply to find a future for our java-based cross-platform development and we, after long consideration, stopped our JFX porting activities for the time being after, in addition to the problems described above, Oracle’s commitment to that technology and the respective dev community seemed to fade away more with every month.
The openjfx-dev mailing list is full of posts from people from frustrated ISVs who want to compete on the market with java-based desktop software, many of those people who have invested serious time in diagnosing, evaluating, debugging and then only hitting a wall (Oracle’s resource management, I don’t blame the engineers) in the end, probably many of them giving up.
I have no commercial interest in bashing JFX and I find the picture you paint in your post very different from my reality which, on the other hand, is very much in line with Shai’s judgement (no affiliation with him btw., didn’t know he existed before this morning).
@Robert Krüger your comments sound like they are based on versions 1 and 2 of JavaFX, not version 8. Is that correct? I was in the lucky position to start with version 8 and found the platform to be absolutely ready for real-world apps. Alexander Casall of Saxonia Systems and I gave a presentation at JavaOne this year where we presented 11 apps from various domains where the companies were very happy with JavaFX. The list includes Emirates Airlines and the European Broadcasting Union (Eurovision), each one of them investing several million Euros into their products. I have written a series of articles called “Real World Apps” in this blog. If you haven’t read them, yet, I would suggest you take a look at them. Each one of them includes an interview where the developers report on their experiences. I will also try to find a way to make the JavaOne presentation available for everybody.
Regarding performance: many people make the mistake to create huge scene graphs with several hundred thousand nodes, each one of them being styled via CSS. Then JavaFX will go down to its knees. For large data volume visualization I would strongly suggest to use the canvas API that comes with JavaFX. I am using it for the FlexGanttFX framework, which is capable of rendering over one hundred thousand activities with a performance that still allows for smooth scrolling.
Regarding the TableView: yes, there is room for improvement. The VirtualFlow that is used under the covers is not being fully exposed, which makes it hard / impossible to control it programmatically. The same can be said about the ListView that is also based on VirtualFlow.
No, we have used JFX 8 from the start (always testing both with production and latest preview JREs).
No, the performance Issue was basically with one animated circle. I posted a JFX bug report for this. If you need more evidence, check the openjfx-dev list for posts by the guys from ultramixer who ran into abysmal graphics performance on the Mac as well. Note that my comments do have a Mac focus as our product is currently mac-only, planned to be released for Windows later. The situation may be very different there and I would suspect large Banks and similar corporations do have quite a homogeneous windows environment.
Yes, I know that there are companies out there selling JFX-based products. I think, if you move in an area, where you don’t run into showstopper bugs, it is a good option technically. For us it hasn’t been so far and the prioritization of issues in the offical tracker doesn’t give one too much hope.
We’ll keep observing for some more time, though not with too much hope.
I will check out your other articles and I am very interested in your JavaOne presentation, though.
The presentation “JavaFX Real-World Apps” can now be downloaded from the CalendarFX homepage at http://www.calendarfx.com
[…] of Dirk, he posted about ‘When to use JavaFX instead of HTML‘, and this was responded to by Shai Almog with his post ‘Should Oracle spring clean […]
[…] of Dirk, he posted about ‘When to use JavaFX instead of HTML‘, and this was responded to by Shai Almog with his post ‘Should Oracle spring clean […]
I disagree with the facebook argument. There are a lot of reasons why facebook would not use an RCP approach, but regular updates surely aren’t the problem. Lots of applications handle updates in a more subtle way than flash player. Or to put it in other words: You do realize facebook has an android app?
I’m agree with dlemmermann.
After JavaFX 1.3, I’m following very close the technology and we are using it for internal developments. I worked with JavaFX on short-medium time-size projects and yes, it has a lack of features and some rendering bugs (some of them, very close to those saw in Swing 😀 ).
However, it is an amazing technology. I don’t know what could be better: improve swing or start from beginning with a new technology (like JFX). The fact is that JavaFX is here and it has been very functional in our projects. So, we (and I ) are very interested into it’s success. It is a reallity that desktop market is little now, but for those few desktop needs, JavaFX is a serious platform to consider.
Reblogged this on CodeBytes.
[…] sur son blog un billet dans lequel il discutait des raisons pour lesquelles, à son avis, l’utilisation de JavaFX peut être préférable à celle de HTML 5. Dirk venait en effet de présenter à la JavaOne plusieurs cas d’utilisation de JavaFX pour […]