Desktop Java

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.
 

Reference: XAML or JavaFx? from our JCG partner Christian Horsdal at the Horsdal blog.

Christian Horsdal

Independent Consultant helping clients architect and develop real world solutions. Typically, but not always, based on the broader Microsoft ecosystem.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

5 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Carlos
Carlos
11 years ago

XAML also means Windows 7…or even Vista. When you say “XAML is faster (and thus cheaper…)”, I think we have a problem. It can be faster, but cheaper not really. Visual Studio, Blend and some of WPF good looking controls are not free neither cheaper. I don’t know JavaFx, but I think the IDE and some other tools are free…

HighCore
HighCore
10 years ago
Reply to  Carlos

Carlos: Why do the java guys alway bring the same stupid argument about supposedly not free tools?? Don’t want to pay for Visual Studio?? Use Visual Studio Express!!!! ITS FREE… and of course it supports WPF. Don’t like Visual Studio because it’s not “open source”…. Use SharpDevelop…. can’t you see your argument is completely irrelevant??

publicENEMY
publicENEMY
10 years ago
Reply to  Carlos

The os is not free. The tools are not free. But doesnt mean cost of development is cheaper for other free alternatives. Tools and os are not the only thing thats cost in any development. Other things like expertise, manpower, timeline do costs. Product quality also matters as it related to how much sales you get. Im not saying microsoft platform is greater than java or anything like that(nothing is perfect), but i detest people who only factored in the cost of ide and os in to make their judgement.

Jan Flos
Jan Flos
9 years ago

Really funny. Did you ever something programmed in WPF ? Probably not more than Hallo World App. You would quite quickly realised that WPF ist technologically years ahead. JavaFx8 is not rally mature.

Christian Horsdal
9 years ago
Reply to  Jan Flos

Look at the publish date. This post is from 2012. At time yes I had built real stuff with both. And the post reflects the conclusions I drew from those experiences.

A lot has happened on the WPF side since 2012. Sadly same does not seem to be true on the JavaFx side. So,yes today WPF is leaps and bounds ahead. But this 2015. Not at the time of wiriting.

Btw: Did you actually read the conclusion?

Back to top button