Tech and form factor for a productivity application.

Taken from "https://pixelduke.com/2020/07/27/creating-a-cad-application-in-java-javafx/" on the 8th Dec 2020.

Technology and form factor

Notice: I might be a bit biased because I’ve been working with JavaFX (and Java) since the very first release. However, I’m going to be as impartial as possible.

If the requirements are to build a productivity application, the best option in my opinion is to go desktop native, instead of, for instance, doing a mobile app. Nothing beats a keyboard and a mouse in this area. Besides more precise and faster input, you can display much more content on screen without having to worry about the touch targets being too small for the fingers. This also means the user will be able to see more data on screen which will be important in a productivity application.

As for “native” vs web. Native allows for better performance, security, etc than a web application. Web has the advantage of higher availability (no required installations, all the user needs is a browser) but if you’re building a performance demanding app, I think your best bet is to go native.

Regarding the programming model, I tend to prefer Java (or any other object orientated, type safe language) and its framework and big collection of third party libraries than the web programming model. Especially when building complex applications.

JavaFX (and Java) are a perfect fit in this type of scenario as JavaFX really shines in the Desktop world. HERO is currently running on Windows, which will probably be the majority of users for your desktop applications. But we can easily, with a few tweaks, support Mac as well and even Linux (though in our case there probably won’t be many users using that O.S., if any).

If, for some reason, we ever have a need to create a scaled-down mobile or tablet version or reuse some of our existing components in a mobile application, we can. Oracle and Gluon have been pushing hard for this, continuously working and making it better. Recently, by leveraging GraalVM, applications can be AOT compiled, benefiting from faster startup times and performance. This is also great for IOS, since IOS doesn’t allow for JIT compilation.

To be fair and to try to be impartial, I’ll conclude this section with what, in my view, are some of downsides of JavaFX (currently):

• Table API.
• Lack of tools to better debug CSS issues and try out CSS tweaks, like for instance having something like firebug (ScenicView is great for other purposes but not specifically for this one).
• Lack of support for some of the Web’s CSS properties. Also one of my pet peeves is the fact that every property is prefixed with “-fx-” (I would prefer this would be dropped on properties that have the same behavior as the ones in Web CSS).
• IDE support for JavaFX CSS isn’t great: error highlighting, etc (side note: I’m using Intellij).
• JavaFX API is too closed and lacks better support for extension on some cases (classes that are final, classes with final methods, etc) regarding this issue I preferred Swing’s more open API.
• Some Font rendering issues (this might only happen with some fonts and only on some platforms – Windows is worse than Mac).
• Better separation of concerns in JavaFX Controls. There was a plan a few years ago to make Behavior classes public, which would probably provide a better separation between the View, Controller and Model aspects of a Control. Right now it’s a bit difficult to create a new Skin for an existing JavaFX SDK Control if your only requirement is to tweak some of its View aspects and when that can’t be done through CSS. This often results in developers preferring to create a new Control altogether than providing a new Skin for an existing one which will mean more work and a higher degree of coupling with those Controls (for instance, you won’t be able to easily switch between Skins). The fact that the API is often too closed also means that, usually, extending an existing Control isn’t an option.