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

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.

Answer 3

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 4

QML/XAML are:

• Great for MVVM pattern
• Hardware accelerated (QML with using OpenGL for Windows, MAC, Linux and Phone OSes... XAML with using DirectX for Windows and its phone version)
• Closer to artists
• You can create a GREAT and NICE UI using XAML/QML
• Easier UI implementation
• Nice animation is possible
• In XAML, usually you can create a Silverlight version of your application just with a little changes
• In XAML there is some great features such as Template, Trigger (DataTrigger, Trigger, EventTrigger), Binding (in any side and also both side together), Resource, Commands, DependencyProperty and Notifiable Properties.

But please note in XAML: (I am a XAML programmer, therefore i have not points for QML)

• XAML debugging is not possible
• For any change in XAML, all program must be recompile

• Be more careful for performance. For example if you use much many RoutedCommands in XAML, your application will be unusable!

• In XAML, some feature not works as expected. There is unfortunately some tricks. (It should be clear... should works as expected... isn't it? )

• Be careful for some similar namespaces like BitmapEffect and Effect. There is different features and costs. (e.g. BitmapEffect has some effects with software render and Effect has some effect with hardware render)

• In real world, artists could not use WPF as Flash (at least with good performance).

• Some features works on special places. For example DataTrigger works just in Style tag not in Resource section.

• There is some weaknesses in XAML. Some examples: there is not any sequential animation... you cannot do any calculation in XAML (you must write a converter in C# even for a liiiittle work! JavaSript is a great replacement in QML)... some attributes are duplicate. e.g. x:Name and Name... Controlling View from ViewModel is not clear. e.g. closing View from ViewModel (you need some CodeBehind)

• Tooooooo much run-time errors. If you use some tags in bad place it will notice you for syntax error, but many of errors occurs just in the run-time. e.g. if i target Background property (instead of Background.Color) for ColorAnimation, it will compile successfully, but in running animation... BUMP... runtime error!!! in such case on Expression Blend, application will crash!!!