|
QML isn't XML-based. Thanks for the correction, I was thinking of xib, XAML, Activities etc. haven't used QML, though I have used Qt, a while ago now. One thing I do think HTML got right is to separate content and code, so putting my UI markup into a js-like format which potentially mixes in code is even less appealing :) Yes, you can jam everything into a HTML document somehow, but that doesn't mean it's always a pleasant way to go, or that HTML is the peak of UI technology. While there's a lot wrong with HTML, and I agree there's much to be improved in its layout model, learning and keeping in our head a new layout model just to place some buttons and UI controls on a page every time we switch platforms is painful, and leads to fragmentation and lock-in where people choose a platform and stick with it, because they've had to invest so much time learning those platform specific tools. I think that's a shame and it's not a pain I look forward to when moving platforms. Depends on your focus I suppose - if you plan on using one platform exclusively or using Qt everywhere, it won't bother you. From my perspective doing work for clients on content-heavy apps, often with web integration, there's an awful lot of content already in html, it provides good control over text styling (typically far better than native equivalents), and it means content is portable between the web and apps, so for those pragmatic reasons I find HTML more appealing for presenting content, even for many UI controls. For example if I have an Android app, an iOS app, and an Ubuntu Phone app, I have 3 different platforms to manage, each with their idiosyncrasies, differing features, layout language, and blessed platform language, and then I have a load of content which I have to let users generate, manage and get into apps on each platform, using web tools to do so is significantly less painful. It's not a huge deal as you can obviously use webviews and frame html content with native controls for each platform, but I wish Ubuntu had taken a step towards the web instead with the phones rather than focussing on desktop technologies. I see why they'd want to tie it in with what they're doing on the desktop though. Sorry for the thread hijack! |
It is pretty close to write once, run anywhere. The only downside is if your app is the first qt app installed on an ios / android device, it forces a download of the shared libraries which are quite large. You also have to build the applications against individual platforms, since you are using C++, and the finished binary is a native application that uses the qt libraries to launch the qml engine and v8 for the javascript parts.
One experiment I am anxious to see come to fruition in the qt space is the KDE project to get qml apps running in the browser : https://projects.kde.org/projects/playground/www/qmlweb. Since QML is inherently javascript, a web app could only use javascript / qml to create a restrcited sandbox (or nacl / other browser equivalent for the c++ parts) and the entirety of qtquick is designed around high latency elements, so it can support network transport.