Sure, at this point HTML/CSS has grown to accomodate many features. But there's a lot of ugly and non-obvious cruft that has been inherited over the ages and it

Sure, at this point HTML/CSS has grown to accomodate many features. But there's a lot of ugly and non-obvious cruft that has been inherited over the ages and it won't change soon. Perhaps a tool can bundle resources, but in the end it's still going to be inserted into the DOM and can potentially clash with other code since everything lives in a global namespace. There's also the problem of competing tools and the dilemma of which one to choose. Any other additional library that is meant to augment/fix HTML/CSS is another dependency that can cause problems and needs to be maintained. QML is meant to be extensive. Not happy with how the drop shadow works? Write your own shader that does it the way you want it. Feeling that there's some primitive like an Ellipse missing? You can write your own in C++ and expose it to QML easily. In fact you can expose any native code to QML. With HTML/CSS you are constrained to the environment it works in. QML supports components, animations, transitions, particles, states, bindings, i18n and much more. It's also very smooth, qml is hardware accelerated. In the case of CSS so you get some hardware acceleration only for animating properties like translation, etc. Here's the dialog I posted before which I changed to support states and transitions and also added an inline shader and particle emitter: http://pastebin.com/hh7xARTS http://pastebin.com/hh7xARTS http://i.minus.com/iATg82IRCaMa9.gif http://i.minus.com/iATg82IRCaMa9.gif (result 4MB gif) As it can be seen it's highly declarative and it basically contains no javascript logic at all besides setting the states. Of course a lot of such features are available indirectly in HTML/CSS by piggybacking on third party libraries/frameworks, but wouldn't HTML be so much nicer if it were designed with those things in mind from the very beginning?