I can think of a number of different approaches to try and explain it, loosely building on each other:
1) If you've used Qt before, you can think of QML files as next-gen .ui files. Like .ui files, QML files allow you to instanciate objects implemented in C++, set properties on them and declare connections between them. However, unlike .ui files they can also instanciate things implemented in QML, and they can evaluate JavaScript expressions.
2) The latter is quite powerful. Expressions can be bound to properties (example: c: a + b), and if properties referenced in an expression (i.e. a and b in the example) change, it will be re-evaluated and thus the value of c will change. This is a simple principle that tends to eliminate an entire class of UI bugs by dropping an entire class of scaffolding code, namely code written to update values somewhere in response to changing state in the system. This is the declarative style - the correct state sort of arises out of the description of the system the files hold, instead of needing to write procedural, step-by-step code to get it there.
3) On top of ideas like this, QML has an excellent anchor-based layouting system and well thought-out ways to inject things like animation behavior into property and state changes. It's also implemented on top of a modern OpenGL scenegraph that does sophisticated draw call batching, texture atlasing and so on, so its performance is game-like. It's also easy to get your own stuff in there.
Combined with what Qt offers in terms of writing serious C++ backends to UIs written in QML, I'm a fan.
1) If you've used Qt before, you can think of QML files as next-gen .ui files. Like .ui files, QML files allow you to instanciate objects implemented in C++, set properties on them and declare connections between them. However, unlike .ui files they can also instanciate things implemented in QML, and they can evaluate JavaScript expressions.
2) The latter is quite powerful. Expressions can be bound to properties (example: c: a + b), and if properties referenced in an expression (i.e. a and b in the example) change, it will be re-evaluated and thus the value of c will change. This is a simple principle that tends to eliminate an entire class of UI bugs by dropping an entire class of scaffolding code, namely code written to update values somewhere in response to changing state in the system. This is the declarative style - the correct state sort of arises out of the description of the system the files hold, instead of needing to write procedural, step-by-step code to get it there.
3) On top of ideas like this, QML has an excellent anchor-based layouting system and well thought-out ways to inject things like animation behavior into property and state changes. It's also implemented on top of a modern OpenGL scenegraph that does sophisticated draw call batching, texture atlasing and so on, so its performance is game-like. It's also easy to get your own stuff in there.
Combined with what Qt offers in terms of writing serious C++ backends to UIs written in QML, I'm a fan.