Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis

Original Article ↗ Hacker News Discussion ↗

Qt’s QML framework is being re‑evaluated in light of recent performance improvements in Qt 6.6 and 6.7, with many developers praising its declarative model, cross‑platform polish, and efficiency compared to browser-based stacks like Electron. Commenters debate whether it’s worth building a new “pure Rust” GUI toolkit versus using Qt via bindings, and weigh QML’s strengths for UI layout and rapid prototyping against its weaker desktop integration, JavaScript-heavy logic layer, licensing complexity, and tooling gaps. Overall, Qt remains seen as a powerful, well-documented option for serious desktop and embedded applications, but not without trade-offs, especially for those wanting fully native look-and-feel or Rust-first ecosystems.

Qt, Rust, and Alternative GUI Toolkits

  • Several Rust users report good experiences with qmetaobject-rs and see Qt/QML as a strong fit for Rust, especially for cross‑platform GUIs.
  • Others point to emerging Rust bindings like cxx-qt and Slint; Slint is seen as better for embedded/custom UIs than for “native-feeling” desktop apps.
  • There is skepticism that a fully competitive “pure Rust” Qt alternative can appear without large, funded teams; GUI complexity (text rendering, widgets, platforms, DPI, accessibility, etc.) is emphasized.
  • Some argue a thin Rust graphics/Canvas/SVG layer could be a good foundation for community-driven toolkits, but others doubt enough contributors will work on the “boring” parts.

Declarative vs Imperative UIs (QML, XAML, etc.)

  • Many like QML’s declarative style for typical UIs and small apps, especially its property bindings and separation of UI from backend.
  • Critics say declarative approaches struggle with very dynamic or “nonstandard” UIs (dockable panels, complex saved layouts, highly configurable views), often forcing imperative workarounds.
  • Counterpoint: much of this can still be expressed declaratively via properties and models; Qt already supports save/restore of panel/splitter states.
  • Other declarative systems (SwiftUI, Jetpack Compose, XAML, JavaFX/FXML) are mentioned; experiences range from “perfect fit” to “too magical, hard to debug.”

QML’s Role, Strengths, and Pain Points

  • Consensus: QML is great as a UI layer with logic in C++ or another language; writing large amounts of JS/QML logic leads to spaghetti and lack of type safety.
  • QML is viewed as especially strong for embedded, kiosk, and custom-look UIs; some find it less “native” out of the box for desktop.
  • Desktop integration gaps are cited: mobile-ish feel, non-native default controls, weaker out-of-the-box widgets vs Qt Widgets, and odd QML scoping rules.
  • Nonetheless, several concrete desktop apps built with QML are reported as successful and performant.

Qt vs Electron/HTML/Tauri

  • Strong pushback against equating Qt/QML with Electron: Qt apps are described as significantly lighter on memory, faster to start, and better integrated with native platforms.
  • HTML/CSS is seen by some as “good enough” or even preferable; others argue it’s document-centric, heavy, and awkward for complex desktop UIs.
  • Tauri is acknowledged as generally more lightweight than Electron (uses system webview, Rust backend) but still fundamentally browser-based; overall app bloat is often attributed to stack choices and poor coding, not just the framework.

Licensing and Ecosystem

  • Qt’s licensing story is described as complex, with a mix of LGPL, GPL, and commercial pieces and multiple historical re-licensings; some organizations remain on older Qt 5.x due to this.
  • Clarifications: core desktop/DE functionality is available under LGPL; specialized/embedded features may have stricter licenses, and some avoid LGPLv3 due to anti‑tivoization clauses.

Tooling and Language Bindings

  • Qt documentation is widely praised as detailed and high quality.
  • Qt Widgets’ Designer is generally liked more than current QML tools. Qt Design Studio is described as heavy, buggy, and producing messy QML, with weaker IDE integration and layout design UX than classic Swing/WinForms/VB/Delphi designers.
  • QML is used successfully with Python (pyotherside), Julia, and other languages for rapid prototyping and some production apps.