Thursday, December 20, 2012

XAML or JavaFx?

This a quick, subjective, unauthorative and very non-scientific comparison of building applications with XAML and with JavaFx. The comparison is based on my personal experience working with each. On the XAML side this means WPF and Win8 store apps. On the JavaFx side this means a Windows 7 application.

JavaFx
JavaFx is touted by Oracle (and Sun back in the day) as new and modern way to build UIs. It's focused on supporting the flexibility and graphical niceness that modern UIs demand. JavaFx can run in and out of browser, and on various OSs.

My experience with JavaFx is building a good looking and quite modern desktop application targeting only Windows 7. We opted for writting the view code in ScalaFx, a declarative JavaFx DSL in Scala. This works fine: The application looks good, performs fine, and the code base is pretty clean. But there are few things bothering me:

  • The UI code is just not as declarative as I would have liked. In general we've found that the built-in controls do not suit our needs, so most of the UI is build from .pngs, that have mouse events attached to them. These events change the .pngs around for hover, clicked and so on. While this works just fine, it means that there is more logic in the views than I'd have liked.
  • In part as a consequence of the above, it's hard to create something like a XAML datatemplate and then bind the data into it. Again this results in more imperative logic in the views.
The things I really like are:
  • The fact that we can use Scala in the views really cuts down on the amount of noise in the view code, compared to Java counterparts, in my opinion. For instance attaching the mouse event handlers is a lot easier with a language where functions are first class citizens.
  • It's fairly easy to run the view code in headless mode from tests. This enables a decent albeit slightly slow TDD workflow for the view code.
XAML
XAML is used in a range of Microsofts UI technologies including WPF and the Win8 store app (formerly Metro) and Silverlight. The XAML UI frameworks are also focused on supporting the needs of moderns UIs, and also runs both in and out of browser.

My experience with XAML is from WPF and Win8 store apps, where we've followed the MVVM approach without any particular framework, but with some homegrown conventions inspired by Caliburn.Micro to ease some of the repetition in XAML - particularly around binding.

This has also worked out well, resulting in nice applications, but again there are some things that bother me:
  • First and foremost I detest writing code in XML. So I'm not a fan of the XAML language at all. You might, at this point, say that XAML is meant to be generated by tools, not written by humans. And you may be right. Nonetheless, my experience is that you do write most of your XAML by hand. I find doing that to be much quicker and more maintainable than using Blend or Visual Studio to edit XAML.
  • I don't like the code behinds. We've kept them quite small in the projects I've worked on, but they are still there tempting developers at weak moments to hide untestable code.
The things I really like are:
  • As with JavaFx it's fairly simple to run the views headlessly for testing. Again this enables an acceptable TDD workflow. Again albeit somewhat slow.
  • Databinding works very well. Especially with some conventions in place to cut down on boilerplate code.
  • Datatemplates in particular enable keeping the views declarative.

Conclusion?
Hmm, I don't think I have enough data here to conclude much. What I will conclude though is that for building Windows applications my experience is that both JavaFx and XAML will get the job done, but it's faster to work with XAML, because the databinding is easier, the datatemplates help a lot and there seems to be less hand rolling controls.
Beware though: The projects I'm comparing are not the same, so there is a certain level of comparing apples and oragnes going on. Also this very subjective. So YMMV.

Update - 2012-12-21
Based on feedback I've decided the conclusion above is too vague. To clarify: In my experience both technologies work, but XAML is faster (and thus cheaper, and faster to market) to work with.

No comments:

Post a Comment