QML的权衡

项目是否能上QML？
QML的优点：ui漂亮、轻易实现各种炫酷的ui特效、编程容易基于Javascript的扩展、与Qt C++紧密相连便于用C++扩展（前后端分离）；QML的缺点：不成熟（即使到了QT 5.12 LTS仍旧很多隐藏的坑，官方文档看着详细，但里面很多实际使用碰到的问题不会说）、依赖后端支持（解放了前端人员，但对于后端是个噩梦，很多代码要重写的）
QML可以通过C++“轻松”地扩展，基本没有实现不了的事情了。但是否“轻松”得看底层逻辑的负责程度。假设你已经有一套QT C++的项目代码，奔着QML的优点想往上面转，既然后端代码都有了，前段ui弄一下，很快不就完事了吗？很多时候现成代码根本没法直接用，很多已经开发好的模块你必须做一层qml与c++的中间件，这个工作量已经不少了，更要命的是，有时候还得改变底层逻辑的实现机制，例如在QT上，显示图像用QLabel很容易实现，到了QML上，image仅支持载入图片文件，如果想显示内存中的图像数据，必须用到一套叫做 image provider的机制，你得继承QQuickImageProvider写一堆代码，然后为了避免刷新数据阻塞ui线程，你又得研究QQuickAsyncImageProvider写一堆代码，然后这个provider还必须在main.cpp的qmlengine加载前设置好，官方文档对这个过程有演示，但是看着让人觉得很魔幻、很奇怪。在使用C++扩展QML的过程中，一个感觉就是心很累，经常卡住，心里憋着，在qt上很简单的需求，到了qml就很绕，你得为了适配qml精心设计后端代码，工作量非常大。用一段时间，就不想再用了，因为并没有减轻负担，随时要面临新的问题。
用之前，先试探一下，设计需求，如果qml的已有模块都帮你实现了，那尽管上；否则，很可能一个地方耗很长时间，最终实现效果还不满意。如果说C++是万物，那理论上QML也是万物，它有无限的可能性，但依赖于大量的C++扩展代码，目前QML还没有形成丰富的开发者生态。