The UI is not based on HTML, it's QML. It's a GUI declaration language similar to XAML from MS. The whole QML described UI is an accelerated OpenGL scene backed by Qt technology so the performance should be much higher than that of HTML5.
"Native or HTML5, your choice
We recognize HTML5 as a core Internet technology often used to develop cross-platform apps. As such, the Ubuntu toolkit offers the flexibility to support HTML5 too. It’s your choice to decide whether you want to go native with QML and the best Ubuntu integration or HTML5 and less integration via Unity webapps."
And it has a lot to offer over HTML. It has a better layout model for one, sane integration of concepts like animated property transitions and behaviors, makes it far easier to put custom objects backed by native code into the scene, and many other advantages. A lot of these things aren't possible declaratively in HTML, and HTML isn't set up to be extensible enough as a language so you could make up for it yourself. 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.
That said, it is possible but still not that easy to do. Native solution will probably be faster, more energy efficient and easier to use.
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.
How does this get around sandboxing on iOS? My fuzzy understanding is that components would need to be downloaded for each app independently. And is there a reason those shared libraries can't be bundled?
According to the qt blog, only qtquick2 depends on v8.
I do wish these platforms were a little more agnostic to the technology used in their API, and had simple C bindings anyone could write glue code for to use their favourite language. Learning yet another markup language and using C++ in order to create apps doesn't really appeal. Whatever the platform insists on as glue is what we'll have to use though, as usual. Personally I'm going to look into the webapp support in Ubuntu Phone to see if it supports local web apps, and hope that I can use that glue to get at any device state that I need to access.
As to qml in the browser, I'd really rather have web apps on the desktop than start writing websites in qml, I'd be very surprised if that catches on.