JavaFX: Lame Duck or Golden Goose?
The software industry is highly competitive and just like consumers, developers have to wade through a sea of FUD and misinformation when it comes to selecting the languages and tools for their next project.
This is particularly true for JavaFX.
Consider the following much-uttered statements:
- Rich client and/or the desktop is dead.
- The web browser is the platform of the future.
- HTML5 applications are just like native applications.
- HTML5 is the only true cross-platform technology.
- Java will never run on mobiles or tablets.
- Java is dead.
- JavaFX is D.O.A.
I for one am sick and tired of guff like this because all of it is in fact completely incorrect.
For example, despite an enormous amount of hype, HTML5 is not going to cure cancer or put a man on Mars or do whatever the current outlandish claim about this technology is. HTML5 is very important and has a very significant role to play in the future of software development but if you believed everything you read on the interwebs about it you might as well ditch all other languages and devote your life to the worship of everything HTML5.
It’s true that HTML5 allows you to build “things” that can be accessed on all the major classes of devices we currently use but these “things” will always be web sites and not what end users have come to know as “applications”. This is because web sites have serious limitations that prevent them morphing into fully fledged applications such as performance limitations, lack of support for multi-threading, poor access to native APIs, lack of advanced programming language features such as true OOP, poor access to hardware devices/sensors etc. and a very limited range of APIs to make use of in the first place. For these reasons there are many software categories that are simply not suitable for web-based deployment. For such software we need the power of native applications.
Clearly then, not only are native apps alive and well but they still have an enormous part to play in the future of software development. What definitely isn’t FUD or misinformation is the *fact* that HTML applications (i.e. web sites) and native apps can and will live side-by-side for many years to come simply because they fill very different niches. And quite clearly neither rich client nor the desktop are anywhere near death. The reality is starkly different with desktop applications surviving into the future for at least 15 years as there remain several niches where only such applications can deliver.
Accordingly I’d like to now focus on native apps and the various ways they can be developed and deployed. If you are only interested in HTML5 then GIYF and, you are seriously missing out.
Up to this point I have been using the terms “app” and “application” somewhat interchangeably. The distinction between the two has probably never formally been defined but I suppose most people think of applications as software that runs on a desktop and apps as software that runs on a mobile phone or tablet device. As far as I am concerned, these is actually no distinction between these two terms and I will now focus on using the word “app” simply because it requires fewer letters to type.
So, I have a great idea for a new app, now I have to ask myself some key questions:
- What language(s) and tool(s) am I going to use to develop it?
- Which platforms is it going to be deployed to?
- How can I minimise the effort and costs involved in development yet maximise its global presence?
Well, there are two main approaches to development of “native” apps that are used today namely finding some kind of cross-device meta platform or language that will enable me to develop using a core code base and deploy to a number of devices with minimal changes or utilising the best languages and tools on each device/platform to maximise the “native” experience but pay the cost of having to write large chunks of platform-specific code.
Choosing between these two approaches has never been easy and usually comes down to being determined by the specific nature of the app or even personal experience or choice.
I don’t know about you but I certainly don’t have the time or financial resources to build software specific to each particular platform even if I am able to compartmentalise as much core code as possible that can be reused. It’s not just the development effort but testing on multiple devices and platforms is extremely time-consuming.
So that’s one of the reasons why I am looking at JavaFX.
For those that don’t know, JavaFX is the new(ish) graphics toolkit for Java applications that has officially replaced the now deprecated Swing toolkit. It’s strengths are that it is high-performance (being hardware accelerated), supports 2D & 3D graphics and animations, does charting, plays media, includes a WebKit based browser component, has sophisticated data binding capabilities and utilises an XML-based file format known as FXML. There is also a drag-and-drop WYSIWYG design tool known as Scene Builder for whipping-up GUIs fast. And JavaFX is open source. Further, JavaFX apps run on almost every operating system known to mankind…
…or almost. The major caveat is that currently there is no “official” release of JavaFX for iOS or Android. There isn’t one for Windows Phone either but that is hardly a weakness However, members of the JavaFX community have demonstrated working examples of JavaFX running on iOS and Android using a product called RoboVM. Given that these demos prove that there is only a lack of investment getting in the way, I believe it is only a matter of time before we will see apps written in JavaFX in the Apple App Store and in Google Play.
When I say “JavaFX” I am not referring to the first generation JavaFX that was released in about 2007. That JavaFX was a different beast because it relied on a brand new scripting language called JavaFX Script and basically very few people bothered to learn it. It wasn’t that the language was bad (in fact it had some outstanding features); it’s just that Java programmers wanted to keep programming in Java. And now they can. With the advent of JavaFX 2, the API is just-another-Java-API and the JavaFX functionality can be accessed from any JVM-based language such as Groovy or Scala. This is a *huge* advantage over JavaFX 1 and is the main reason why interest in JavaFX has exploded in the last couple of years.
A very broad range of apps can be developed using JavaFX ranging from simple form-based UIs to complex 2D/3D graphics incorporating audio and video playback and animated content. It is therefore suitable for business apps and games as well. Sure, I wouldn’t choose JavaFX to write Halo 6 or build an operating system but they’re not the kind of apps I develop on a daily basis and I don’t think many people actually get to work on such projects very often. But for your most common business and personal software requirements, JavaFX is an ideal fit and not just for Java programmers. While it is very clear that Java programmers will be by far the most abundant users of JavaFX, developers who have never used Java will gravitate to this toolkit because it offers them features, performance levels and deployment options not readily available with other products.
Also, there is a real buzz about JavaFX in the Java community at the moment with several high-profile JavaFX rock stars motivating people like me to get involved. If you have questions, someone will quickly respond on the official JavaFX forum and more and more code snippets are cropping up online to help you bash out your first app.
I have to say that having considered all the options I could locate and after a great deal of research and actual software testing I am convinced that JavaFX is no Lame Duck. Quite the contrary in fact. It’s a Goose; a Goose of the Golden variety.
Just my 2 bits.