What are the real-world benefits of declarative-UI languages such as XAML and QML?

Question

I'm currently evaluating QtQuick (Qt User Interface Creation Kit) which will be released as part of Qt 4.7. QML is the JavaScript-based declarative language behind QtQuick.

It seems to be a very powerful concept, but I'm wondering if anybody that's made extensive use of other, more mature declarative-UI languages like XAML in WPF or Silverlight can give any insight into the real-world benefits that can be gained from this style of programming. Various advantages are often cited:

• Speed of development
• Forces separation between presentation and logic
• Better integration between coders and designers
• UI changes don't require re-compilation

Also, are there any downsides? A few potential areas of concern spring to mind:

• Execution speed
• Memory usage
• Added complexity

Are there any other considerations that should be taken into account?

Answer 1

(Updated)

The misconception with XAML is that it's not compiled. It is indeed compiled down to BAML a binary pre-tokenized XAML. Apparently there was a IL compiled version of XAML too called CAML. The OP pointed me to this good article explaining what XAML/BAML and CAML are.

Anyway, to the question why to use it:

XAML is simply a Serialization Format for C# objects that it is particularly well suited to describe hierarchical object structures, like found in WPF GUIs.

What WPF helps you do is write less boring C# code like this:

var grid = new Grid();
grid.Content.add(new TextBlock() {Text = "Hello"});
grid.Content.add(new TextBlock() {Text = "World"});

and just express it in a more readable way like this:

<Grid>
  <TextBlock Text="Hello">
  <TextBlock Text="World">
</Grid>

Since WPF object nesting (putting stuff inside other objects) can get very deep, WPF makes it much easier to read than the resulting C# code.

As for separation of concerns: XAML helps here too since it does only allow you to express objects and their relationships/properties, rather than logic. That forces you to separate logic from UI layout. The MVVM Pattern is very well suited for this task and allows for eay testability and interchangeable Views.

Added complexity in XAML can be also easily dismissed because the same code in C# gets easily more complex than the XAML markup.

I can't give you any insight into QTQuick though. Sorry

Answer 2

The point of declarative coding, i.e. WPF or QTQuick is to provide a separation between the developer and presumably the artist that is implementing the visual aspects of your application. With regards to WPF, I find that debugging gets to be a bit harder. As we speak, I am compiling the latest QT to look at QTQuick. (It takes a long time and I have time to look at stackoverflow :-) ) So, I don't have an opinion on that yet.

Answer 3

QtQuick is extensible via C++ plugins, actually what the Qt guys recomment is that you do the UI, Animations, Transitions etc in QtQuick/QML while all of your business logic is in C++/Qt. So this way you get the best of both worlds, you can debug your C++ code like you usually do, while at the same time making UIs becomes effortless and extremely easy.

Also another important think about QtQuick/XAML is that they are hardware accelerated, so for example you can get pretty good fps without any effort. So they are not slow at all for what they set out to accomplish.

It saves time, soo much time. I did a UI with code in 3 days, did the same in QML in 2 hours.