JavaFX redux

Having spent a few weeks experimenting with JavaFX, and creating several examples, here is an assessment of whether JavaFX succeeds in it’s objective of being a graphics DSL. Bear in mind that I am evaluating it in terms of it’s ease in being a graphics DSL – if it makes my life easier, it succeeds. Where it makes my life harder than developing web apps – it fails.

On with the list.

Wins

• bind keyword – it took a while, but finally concepts from sloppy tools like Excel is making it’s way into mainstream programming languages. Programmers should never have to do the work that a computer can do just as well.
• First class support for animations The language simplifies the process of creating keyframe-styled animations, without having to launch background threads, worry about EDT and having to write callback code for timers.
• Object initializer syntax Using keyword-style arguments suits objects which has tonnes of properties
• effect property in Nodes makes it straightforward to add “bling” to a project without having to rearrange program layout
• strong support for functional-style programming List comprehensions, filter, map. Built into the language.

Losses

• Javaesque layouts, not Webesque – containers are emphasised over styles. This is not going to win any points with the semantic crowd.
• Difficulty in adding extension points – I would have favoured seeing C# static extension methods in the language. It would have made adding behaviors easier. For instance, centering a piece of text takes more effort than it should, and once done it could not be easily refactored and added to other elements. I regard this as a wart in a DSL that aims to support animators.
• Difficulty in adding behaviors – adding behaviors like “clickable”, “hoverable”, “draggable” requries programmatic intervention, rather than being able to declaratively do this. This is due to the absence of extension points above, and the absence of namespacing from the YAML syntax. XML-style syntax would have been kinder to these kind of mashups.
• The DSL may be suited for laying out standard blocky objects, but (I was working with Vim and) it was hard to lay things out by hand. One still needs to fall back on a graphic editor to create most of the resources.
• The story on accessibility is still unclear – granted that JavaFX is a DSL for graphics and animations, however, it’s target is to be a platform for developing applications. Without a clear accessibility story, JavaFX will never see the doors of a government application, or a public-facing application of large corporations.
• event handlers – there is only one for each event. I couldn’t figure out why. onclick=”…” is so 1997.

Recommendations

• Tools support is essential The language compiler project should make the abstract syntax trees available so that third parties can easily develop tools to parse the language. Currently, it is a one-way conversion from Adobe/SVG to FXD. Syntax sugar in the Timeline, duration may be cutesy, but we need parsers please.
• Extend language to make it easy for developers to add custom attributes and behaviors to graphical nodes. The OpenJFX developers should wrap Centering layout code for each graphical shape to see how weak JavaFX is in this area.
• More support to attract web developers – the people who are writing the specs come from a Java development background, and it shows. The JavaFX language team needs a few web developers on the advisory board to make it easy to attract this particular constituent.
• more interfaces and less inheritance – when writing layout code, I’m frequently stymied by containers like scene and stage which do not have the same base classes, making it hard to measure width and height.

You should follow me on twitter here