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