回复内容：
做UI啊。如果是桌面应用，QML可以更快速。如果是手机UI，H5绝对占优。毕竟Qt提供的那一套控件库更适合桌面应用，而当年诺基亚都开发了塞班和米果的QML手机控件库，现在Ubuntu，旗鱼，黑莓都有自己的QML手机控件库。
渲染性能上。QML有绝对统一的接口规范以及渲染机制。（跨平台是这样的）。 H5桌面系统一套，就谷歌做的好。手机WebKit嗯，但是系统对WebKit的支持也不能说表现一样。
接下来我来说说QML吧。 QML的执行引擎是基于Qt的V4引擎，V4最大的改变就是添加了类型。（有关源码分析，请移步qtdeclarative 源码略读）添加了类型让QML的属性绑定相比于之前的版本（Qt4的QtQuick 1.x）有极其大的提升。 属性绑定（数据绑定，表达式绑定）。嗯，在QML中随处可见的属性绑定，虽然有H5中有类似数据绑定的JS库。但QML语法上就支持了。
QML的渲染方式相较于之前的版本也有了重大的更新。 之前的版本（Qt4的QtQuick 1.x）更接近widget，虽然是Griphics/view，但是渲染更多是优先提交给cpu处理。当然，在N9(嗯，第一个完全使用QML构造应用的系统)，会使用gpu，有硬件加速嘛。
现在的QML渲染方式更倾向于优先使用显卡。（所以现在使用QML需要良好的显卡支持，例如正确安装显卡驱动）。
简单扯扯现在QML的渲染绘制机制吧。
1. 基于事件的,基于Griphics/secen
2. 有两个线程，一个绘制，一个渲染。
3. cpu负责绘制，gpu负责渲染。
4. 当需要重绘时，绘制线程暂停，渲染线程进行渲染，渲染完毕，绘制线程启动，绘制。
嗯，上面那个我是看Qt英文文档，自己理解的，叙述有出入。 此外，Qt正在开发的Qt3D，类比WebGL，其性能以及可部署性远大于H5的WebGL，嗯，是个重型武器。其实也反应出了QML渲染和绘制的效率。这是个非常好的问题，不过以我的了解程度，还没办法给出好的回答。
QML 组件化特征比较强，这一点是 HTML5 不具备的。原始的 Web 开发方式（HTML/CSS/JS）更像是在用砖头砌墙。便捷h5胜。
性能qml胜。
强大，这个没标准吧？投QML一票 之前有一个项目。急着要出产品。拉了2，3个JAVA工程师，3个月就把第一版做出来了。UI部分用的是QML。
后面领导突然觉得不够潮流，不能在浏览器运行，决定拉了一帮人马20多个人，用Node.js 和HTML5去做。做了几个月，做不出来。
回来后老老实实用QML继续做，越来越好。
用html5去做，同时刷4路1080p的摄像头视频，能做到吗？QML可以做到。
当然，QML坑挺多。
当然，后面做HTML5的人跳槽了。薪资杠杠的。他们跟我说写QML比写HTML快且爽，但怕找不到工作。这不仅仅是个技术的问题，或者说压根不是个技术问题。
首先，用 html5 做桌面，只要有若干 c++ 或者 nodejs 开发人员做支撑（取决于需求和框架），上层的逻辑和 UI 可以全部交给前端工程师搞定，无论从交接还是招聘的角度，都方便的多。
用 qml 可能架构干净了，性能好了，可你到哪儿找通这门技术的工程师呢？让前端现学，人家嫌不来钱不乐意，Qt 原生程序员又不好找（本来基数就小，就算找到了，这部分人现在大都琢磨着转型，未必想给你干这个）。这种情况以后会越来越麻烦。
我之前做过原生 Qt 桌面应用，身边同事懂 Qt 的不在少数。我也考察过 qml，确实有不少成功案例，包括 ktv 点唱机那种花哨的界面，用 qml 都是完全可行的。但是最近的项目，我还是选择了基于 html5 的方案，主要考量就是以后的维护和交接。而且伙伴团队跟我沟通过这里面的利弊之后，他们新上的项目也采用了 html5 方案。
第二点理由，前端领域的可用工具比较多，包括 jQuery 这样的工具库，以及 angular 这样的框架，可选项很丰富，qml 在这方面就差很远。
第三点理由，调试。我对 qml 了解不够深入，对调试手段了解不多，但是基于 html5 的方案调试起来实在太方便了，UI 层无需任何改动，直接用 Chrome 浏览器就能调试，必要时增加些 mock 代码即可。
html5 做桌面的劣势主要是系统级接口的缺乏，解决方法其实也很多，可以使用 nw.js 这类 nodejs 和 webkit 的集成框架，也可以自己封装 native 和前端的消息通信。对于需要界面展示、前端又不好做的需求（比如播放视频），可以动用 npapi 插件技术解决。
另外有评论认为 qml 的性能比 html5 好，这一点我认为除非是特殊的行业应用，大部分时候可以忽略。对于一般的业务， html5 的整体性能足以应付——你对网易云音乐和有道云笔记的性能满意吗？你的应用比这俩复杂多少？对于一些性能有要求特殊模块，直接动用 c++ 即可。
以上说的是桌面端，移动端就不需要争论了，铁定 html5，移动端 qml 找个典型案例都费劲。
ps：啥时候能出个 React Qt？实际上很多时候用脚本就是想提升开发效率（不大喜欢pyQt），不是想要那些复杂的 gpu 动画效果。React native 的思想，可能比 qml 更实用，也更能体现差异性。没大规模写过QML，凭印象答下。便捷程度的话，怎么可能有东西比的上H5呢，几千个css样式和几百个标签，各种排版布局，各种矢量绘图，甚至还有webgl这种3D的东西，,再加上各种第三方库,QML无疑在便捷、强大程度上差太远了。如果说渲染效率的话，这个不好比较。但据我对chromium的渲染机制的了解，绝对远比qt的渲染机制强大的多的多。HTML的解析，chromium早就做到多线程解析，渲染的话，chromium的cc层现在已经非常强大了，做到多颗layer tree架设在各种线程，录制渲染指令，回放渲染指令，合成，上屏，都能做到不同线程并发，这方面QML肯定又要差的远。但HTML有个致命缺点就是规范太复杂，以至于要实现完整的html标准会导致低下的性能。未完待续·····这个问题其实想真正回答好，是有难度的。Qt重在跨平台的桌面应用，而H5则重在WebApp的体验，二者本没有多少重合点，但近年来浏览器被拿来做UI了，所以才有了纠结的开始。
对QML了解不多，只是随便百度了下，仅知道了个所以然。从题主关注的几点出发，主要以下几点：
一、便捷性
与H5的大众型普及度来看，QML只能算是Qt家族的一小分支，属于小众类。QML提供了专有设计器，H5的设计工具则琳琅满目。QML的语法类似JSON语言，如果离开设计器，可读性和可维护性较差。而H5的HTML和CSS黄金组合，则更容易获得开发人员的支持。
两者运行都需要自己的容器。QML离不开Qt的一堆库，开发基于组件式，调用Qt的各个功能，开发比较便捷；而H5离不开浏览器支持，但如果要考虑一个个性化的界面，H5需要把浏览器嵌入现有的的开发框架。虽然已经有很多爱好者对各种流行的浏览器内核进行了令人叹为观止的精简，但发布包依然动辄十几兆，而且需要c++等语言与库的捆绑，技术难度较大。但如果解决了上述问题，H5本身的开发难度就小case了。
二、功能性
QML有点类似Adobe前些年推出的Flex，有自己的ActionScript和MXML语言，在自己的框架里使用，可以充分的调用Qt的各个功能包，界面方面比较循规蹈矩，很难冲出Qt本身的组件框架。
H5依靠Javascript以及HTML5强大的canvas、css3的动画支持，可以做出更自由、更充满灵气的界面。这一点无可置疑。
三、渲染性能
没比较过。但从二者的实现原理来看，Qt本身是基于OS的native层的，而H5则需要间接的通过js这一层脚本去调用。虽然现在js的性能已经很强，但毕竟以脚本去对抗native，还是略占下风。不过好在现在用户的电脑和设备配置都越来越好，一点点的性能差异几乎难以察觉。
从开发者角度，在技术选型时，不仅仅要考虑上面的几点因素。还要考虑技术的学习成本、可维护性、扩展性、可部署性等多方面。技术没有绝对的优和劣，最合适自己的就是最好的选择。从qt到qml再到html5，现在开发单机应用，html5开发界面，qt开发后台服务，你说呢也投qml一票，排版，属性绑定，动画。