javafx_logo_color_small.png

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