Qt 6.6 y 6.7 hacen QML más rápido que nunca: un nuevo benchmark y análisis

Artículo original ↗ Discusión en Hacker News ↗

El framework QML de Qt se está reevaluando a la luz de las mejoras recientes de rendimiento en Qt 6.6 y 6.7, y muchos desarrolladores elogian su modelo declarativo, su pulido multiplataforma y su eficiencia frente a stacks basados en navegador como Electron. Los comentaristas debaten si merece la pena construir un nuevo toolkit GUI “puro Rust” o usar Qt mediante bindings, y comparan las fortalezas de QML para el diseño de interfaces y el prototipado rápido con su peor integración en escritorio, su capa de lógica intensiva en JavaScript, la complejidad de sus licencias y sus carencias de herramientas. En general, Qt sigue viéndose como una opción potente y bien documentada para aplicaciones serias de escritorio y embebidas, aunque no sin compromisos, especialmente para quienes quieren una apariencia totalmente nativa o ecosistemas centrados en Rust.

Qt, Rust y toolkits GUI alternativos

  • Varios usuarios de Rust informan buenas experiencias con qmetaobject-rs y ven Qt/QML como una gran opción para Rust, especialmente para GUI multiplataforma.
  • Otros señalan bindings de Rust emergentes como cxx-qt y Slint; Slint se considera mejor para UIs embebidas/personalizadas que para aplicaciones de escritorio con “sensación nativa”.
  • Existe escepticismo de que pueda aparecer una alternativa “pura Rust” plenamente competitiva a Qt sin equipos grandes y financiados; se enfatiza la complejidad de las GUI (renderizado de texto, widgets, plataformas, DPI, accesibilidad, etc.).
  • Algunos argumentan que una capa delgada de gráficos/Canvas/SVG en Rust podría ser una buena base para toolkits impulsados por la comunidad, pero otros dudan de que suficientes colaboradores trabajen en las partes “aburridas”.

UIs declarativas vs imperativas (QML, XAML, etc.)

  • A muchos les gusta el estilo declarativo de QML para UIs típicas y aplicaciones pequeñas, especialmente sus enlaces de propiedades y la separación de la UI del backend.
  • Los críticos dicen que los enfoques declarativos tienen dificultades con UIs muy dinámicas o “no estándar” (paneles acoplables, diseños complejos guardados, vistas altamente configurables), y a menudo obligan a usar soluciones imperativas.
  • Contraargumento: gran parte de esto todavía puede expresarse declarativamente mediante propiedades y modelos; Qt ya admite guardar/restaurar estados de paneles/splitters.
  • Se mencionan otros sistemas declarativos (SwiftUI, Jetpack Compose, XAML, JavaFX/FXML); las experiencias van desde “encaje perfecto” hasta “demasiado mágico, difícil de depurar”.

Rol de QML, fortalezas y puntos de dolor

  • Consenso: QML es excelente como capa de UI con la lógica en C++ u otro lenguaje; escribir grandes cantidades de lógica en JS/QML conduce a espagueti y falta de seguridad de tipos.
  • Se considera que QML es especialmente fuerte para UIs embebidas, kioscos y de aspecto personalizado; algunos lo encuentran menos “nativo” de forma predeterminada para escritorio.
  • Se señalan brechas de integración de escritorio: sensación parecida a la de móvil, controles predeterminados no nativos, widgets out-of-the-box más débiles que Qt Widgets y reglas extrañas de ámbito de QML.
  • Aun así, se reportan varias aplicaciones de escritorio concretas construidas con QML que han tenido éxito y buen rendimiento.

Qt frente a Electron/HTML/Tauri

  • Hay una fuerte oposición a equiparar Qt/QML con Electron: las aplicaciones Qt se describen como significativamente más livianas en memoria, más rápidas al arrancar y mejor integradas con plataformas nativas.
  • Algunos consideran que HTML/CSS es “suficientemente bueno” o incluso preferible; otros sostienen que está centrado en documentos, es pesado y resulta incómodo para UIs de escritorio complejas.
  • Se reconoce que Tauri suele ser más liviano que Electron (usa el webview del sistema, backend en Rust), pero sigue siendo fundamentalmente basado en navegador; el bloat general de las apps suele atribuirse a las decisiones de la pila y al mal código, no solo al framework.

Licencias y ecosistema

  • La historia de licencias de Qt se describe como compleja, con una mezcla de LGPL, GPL y componentes comerciales, y múltiples relicenciaciones históricas; algunas organizaciones siguen en Qt 5.x por esta razón.
  • Aclaraciones: la funcionalidad central de escritorio/DE está disponible bajo LGPL; las funciones especializadas/embebidas pueden tener licencias más estrictas, y algunos evitan LGPLv3 debido a cláusulas anti‑tivoización.

Herramientas y bindings de lenguaje

  • La documentación de Qt es ampliamente elogiada por ser detallada y de alta calidad.
  • Qt Widgets’ Designer suele gustar más que las herramientas actuales de QML. Qt Design Studio se describe como pesado, con errores y capaz de producir QML desordenado, con una integración en el IDE y una UX de diseño de layouts más débiles que los diseñadores clásicos de Swing/WinForms/VB/Delphi.
  • QML se usa con éxito con Python (pyotherside), Julia y otros lenguajes para prototipado rápido y algunas aplicaciones en producción.