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還沒有形成豐富的開發者生態。