JavaFX’s FXML a big step backwards

I shouldn’t care about this because I don’t use JavaFX. But it bugs me so I’ll rant a bit.

A while ago (probably around version 1.2) the language caught my eye. I especially liked its literal declarative syntax for creating tree structures and data binding. I thought I heard that Oracle was discontinuing JavaFX but version 2.0 is in beta. I now realize that it is only JavaFX Script that is canned — JavaFX is alive and well. (JavaFX Script lives on in visage.) The features of JavaFX are available as APIs that can be used from Java or other languages on the JVM. This is a good architecture.

Writing procedural code to construct a scene graph looks as ugly and cumbersome as JavaFX Script was elegant. To “fix” this problem FXML was invented. FXML is a XML dialect for declaring a scene graph.

From what I have read there are two main motivations for using XML:

  • Familiarity — from the getting started with FXML page: “One of the advantages of FXML is that it is based on XML and is therefore familiar to most developers”
  • No need to compile (presumably changes to FXML are made on the fly without having to restart the app). This is fair but doesn’t imply that XML is a good answer.

The familiarity argument is false. It confuses syntax with semantics. Yes many developers are familiar with the syntax of XML but just because someone knows XML Schema doesn’t mean they will have any understanding of XSLT. One must still learn the semantics of FXML and that’s the hard part.

Here is what I think is bad about FXML:

  • XML is just not a convenient language for source code. It is verbose and cumbersome. It has lots of little things that get in the way such as entity references. New programming languages including declarative ones should not be XML.
  • Use of character case in element names to distinguish between instances and properties is ugly.
  • Properties can be represented by either XML attributes or XML elements. This is practical but confusing and stems from using the wrong tool for the job (XML).
  • Type coercion.

And a few things I liked:

  • Use of XML processing instructions.
  • Built-in support for string translation. But it doesn’t go far enough. It should eliminate the need for maintaining resource property files and support format substitutions.
  • Concept of static properties.

What FXML shows is the importance of having a literal representation for data. It looks like FXML could be used to build arbitrary heterogeneous object trees which is generally useful. What I think is really needed is an object literal syntax for Java similar in concept to what JavaScript has. The syntax used by JavaFX Script would make a great starting point.

5 Responses to “JavaFX’s FXML a big step backwards”

  1. Greg Brown Says:

    Hi John,

    Saw your blog entry and wanted to share some thoughts (my first attempt generated an error, so I’m trying to post this again):

    “The familiarity argument is false. It confuses syntax with semantics…One must still learn the semantics of FXML and that’s the hard part.”

    That is true. However, the key is that developers are familar with and comfortable with the markup metaphor, so it is less of a conceptual hurdle than JavaFX Script was.

    “XML is just not a convenient language for source code…New programming languages including declarative ones should not be XML.”

    In general, I agree with you. I have seen attempts at using XML to encode logical operations, and they were pretty ugly. However, that’s not what FXML does. FXML is for declaring the structure of your UI (which, as you noted, is fairly cumbersome in procedural code). The actual “programming” (i.e. logic) is still implemented Java, JavaScript, or some other JVM langauge. So FXML allows the developer to use the right tool for the job – XML for structure, code for behavior.

    “Use of character case in element names to distinguish between instances and properties is ugly.”

    I agree. This is simply an unfortunate consequence of basing the language on XML.

    “Type coercion.”

    Could you elaborate? Scripting languages do this – why not FXML?

    “Built-in support for string translation. But it doesn’t go far enough. It should eliminate the need for maintaining resource property files and support format substitutions.”

    Regardless of how you actually construct your UI (FXML, procedural code, DSL, etc.), you still need some way to keep your localized resources separate from the UI elements – you wouldn’t want to hard-code any particular language into the UI, right? And since format strings are inherently locale-specific, it wouldn’t make sense to support them in markup, since that would be counter to the goal of locale-independence.

    Greg

  2. John Snyders Says:

    Hi Greg, Thanks for commenting

    wrt type coercion, Even something like JSON is less ambiguous going from number to Double or true/false to Boolean. Even if there is some type coercion it is nice to start with a richer syntax for literal values vs. everything is a string. But I’m glad you didn’t suck in XML schema types like XSLT 2.0 did. (I like XSLT2 but mostly ignore the type stuff.)

    wrt “you wouldn’t want to hard-code any particular language into the UI, right?” actually yes I would. I know it sounds crazy but it works. Thats all I can say here. A previous post may give some idea of where I’m coming from.

  3. S. M. Mousavi Says:

    Hi John,

    Thanks for your blog post. I found it intersetng, and I would like to share my ideas too.

    I understand the problems that you have mentioned about XML format of fxml. But, I think the disadvantages should be considered to be much less than advantages. I have summarized my ideas about JavaFX approach for RIA and the concept of FXML in following blog post:

    http://community.jboss.org/blogs/mousavi/2011/09/26/rich-internet-application-ria-by-java-is-javafx-on-right-path

    If you consider FXML as one sub-project of JavaFX, yes, you are right. It is almot meaningless. But, if you consider the possibility of FXML to become the content modeling language for visual presentation of any kind of Java application on any device/platform, I think FXML will become much more attractive solution, just the way the Microsoft has used XAML technology.
    I will be happy to know your idea.

  4. John Snyders Says:

    Hi Mousavi,

    I read your blog post – its a worthwhile read. Seems I have to register to comment so I’ll respond here. I think that your 4 rules have some overlap with what I wrote about here.

    I very much agree with you on specifying the UI declaratively and also that the “rendering engine” should be independent from the declaration (specification). I believe that more than just the UI can be specified declaratively. Most of what could be considered UI behavior should be wrapped up in higher level UI widgets and navigation patterns. The rest is just bindings to data and functions which transform and validate data as it flows. The functions ideally need no knowledge of the UI or back end data store.

    I used to be a big fan of the principal of separation of presentation and behavior, which is why I used stringtemplate – its the only markup language that really enforces it. In the right context this makes sense but it needs to be rethought in the context of a declarative end-to-end language. There’s more to say about that but perhaps in another post. I now prefer moving the MVC to the browser (keeps things much simpler and scales better) and so I have no need for template languages on the server.

    I agree with you that a declarative language for UI (and more) should span UI technologies rather than be specific to one framework such as JavaFX. If I had to choose between creating a UI procedurally and declarative I would choose declarative even if it was XML. I used to be a big fan of XML. For a while all my thinking about data was in terms of XML. That has passed and I just don’t like writing code or specifications in XML. I do think XSLT 2 is a good tool and I put up with the XML syntax in that case – but if there were something better…

    As far as RIAs go I expect Browsers and HTML 5 to provide everything I need. I have no use for Flash (except for audio and video for a little while longer), Silverlight, or JavaFX on the web. This will do all the way up to high end 3D games where you need the power of a GPU and these are not the kinds of web apps I have been building so far.

  5. Bob Says:

    I just wanted to say that I tried using Pivot to quickly prototype Apache SOLR output (since it comes out in XML already) so that users can quickly work with SOLR. It was pretty slick the way you can quickly convert SOLR’s XML into a GUI. Now that this functionality is in JavaFX and combinded with the fact that you can spit out SOLR matches into a Webkit window, I’m in heaven.

    Bottom line: if you’re like me and work primarily on the server-side, but you need to prototype possible usage scenarios, this is perfect.

    Greg, thanks for all that hard work. BTW, does this mean that Pivot’s life is over?

    Bob