Qt 6.6 和 6.7 让 QML 比以往更快：一项新的基准测试与分析

原文 ↗ Hacker News 讨论 ↗

随着 Qt 6.6 和 6.7 的性能改进，Qt 的 QML 框架正在被重新评估；许多开发者称赞它的声明式模型、跨平台打磨程度，以及相较于 Electron 之类基于浏览器的技术栈更高的效率。评论者讨论了是否值得构建一个新的“纯 Rust” GUI 工具包，还是通过绑定使用 Qt，并权衡了 QML 在 UI 布局和快速原型开发方面的优势，与其较弱的桌面集成、重 JavaScript 的逻辑层、许可复杂性和工具缺口之间的取舍。总体而言，Qt 仍被视为面向严肃桌面和嵌入式应用的强大且文档完善的选择，但并非没有代价，尤其是对于那些想要完全原生外观和体验或 Rust-first 生态的人来说。

Qt、Rust 和替代 GUI 工具包

  • 一些 Rust 用户表示，使用 qmetaobject-rs 的体验很好，并认为 Qt/QML 非常适合 Rust，尤其适合跨平台 GUI。
  • 另一些人则提到新兴的 Rust 绑定，如 cxx-qt 和 Slint；Slint 被认为更适合嵌入式/自定义 UI，而不是那种“有原生感觉”的桌面应用。
  • 有人怀疑在没有大型、资金充足团队的情况下，不可能出现一个完全有竞争力的“纯 Rust” Qt 替代品；他们强调 GUI 的复杂性（文本渲染、控件、平台、DPI、可访问性等）。
  • 也有人认为，一个轻量的 Rust 图形/Canvas/SVG 层可以成为社区驱动工具包的良好基础，但另一些人怀疑是否会有足够的贡献者去做那些“无聊”的部分。

声明式 vs 命令式 UI（QML、XAML 等）

  • 许多人喜欢 QML 的声明式风格，适合典型 UI 和小型应用，尤其是其属性绑定以及 UI 与后端的分离。
  • 批评者说，声明式方法在处理非常动态或“非标准”的 UI 时会遇到困难（可停靠面板、复杂的已保存布局、高度可配置的视图），往往不得不借助命令式变通方案。
  • 反驳意见是：其中很多内容仍然可以通过属性和模型以声明式方式表达；Qt 本身已经支持保存/恢复面板/分割器状态。
  • 还提到了其他声明式系统（SwiftUI、Jetpack Compose、XAML、JavaFX/FXML）；体验从“完美契合”到“太魔法化，难以调试”不等。

QML 的角色、优势与痛点

  • 共识是：QML 作为 UI 层非常出色，逻辑放在 C++ 或其他语言中；如果用大量 JS/QML 逻辑来写，会变成意大利面式代码并缺乏类型安全。
  • QML 被认为尤其适合嵌入式、自助终端和自定义外观的 UI；一些人觉得它开箱即用的桌面“原生感”较弱。
  • 桌面集成方面的缺口被指出：偏移动端的感觉、默认控件非原生、开箱即用的控件不如 Qt Widgets 强，以及 QML 令人费解的作用域规则。
  • 尽管如此，也有几款用 QML 构建的具体桌面应用被报告为成功且性能良好。

Qt vs Electron/HTML/Tauri

  • 对将 Qt/QML 等同于 Electron 的说法反对声很强：Qt 应用被描述为内存占用明显更低、启动更快，并且与原生平台集成更好。
  • 有些人认为 HTML/CSS “已经足够好”甚至更可取；也有人认为它以文档为中心、臃肿，并且不适合复杂桌面 UI。
  • Tauri 被认可通常比 Electron 更轻量（使用系统 webview、Rust 后端），但本质上仍是基于浏览器；应用臃肿通常被归因于技术栈选择和糟糕编码，而不仅仅是框架本身。

许可与生态系统

  • Qt 的许可故事被描述为复杂，包含 LGPL、GPL 和商业组件，以及多次历史上的重新许可；一些组织因为这个原因仍停留在较旧的 Qt 5.x。
  • 说明补充：核心桌面/DE 功能可在 LGPL 下使用；专门的/嵌入式功能可能有更严格的许可，而有些人会避免 LGPLv3，因为其中的 anti-tivoization 条款。

工具与语言绑定

  • Qt 文档被广泛赞誉为详尽且高质量。
  • Qt Widgets 的 Designer 通常比当前的 QML 工具更受欢迎。Qt Design Studio 被描述为臃肿、容易出错，并生成杂乱的 QML；与经典的 Swing/WinForms/VB/Delphi 设计器相比，其 IDE 集成和布局设计体验也更弱。
  • QML 也被成功用于 Python（pyotherside）、Julia 以及其他语言中，用于快速原型开发和一些生产应用。