Qt 6.6 e 6.7 Tornam o QML Mais Rápido do que Nunca: Um Novo Benchmark e Análise

Artigo original ↗ Discussão no Hacker News ↗

O framework QML do Qt está sendo reavaliado à luz das melhorias recentes de desempenho no Qt 6.6 e 6.7, com muitos desenvolvedores elogiando seu modelo declarativo, polimento multiplataforma e eficiência em comparação com stacks baseadas em navegador como Electron. Os comentaristas debatem se vale a pena construir um novo toolkit GUI “puramente Rust” versus usar o Qt via bindings, e ponderam os pontos fortes do QML para layout de UI e prototipagem rápida contra sua integração de desktop mais fraca, a camada de lógica pesada em JavaScript, a complexidade de licenciamento e as lacunas de ferramentas. No geral, o Qt continua sendo visto como uma opção poderosa e bem documentada para aplicativos sérios de desktop e embarcados, mas não sem trade-offs, especialmente para quem deseja aparência e comportamento totalmente nativos ou ecossistemas Rust-first.

Qt, Rust e Alternativas de Toolkits GUI

  • Vários usuários de Rust relatam boas experiências com qmetaobject-rs e veem Qt/QML como uma excelente opção para Rust, especialmente para GUIs multiplataforma.
  • Outros apontam para bindings emergentes de Rust como cxx-qt e Slint; o Slint é visto como melhor para UIs embarcadas/personalizadas do que para aplicativos de desktop com “aparência nativa”.
  • Há ceticismo de que uma alternativa “puramente Rust” e totalmente competitiva ao Qt possa surgir sem equipes grandes e financiadas; a complexidade de GUIs (renderização de texto, widgets, plataformas, DPI, acessibilidade etc.) é destacada.
  • Alguns argumentam que uma camada fina de gráficos/Canvas/SVG em Rust poderia ser uma boa base para toolkits impulsionados pela comunidade, mas outros duvidam que haja contribuintes suficientes para trabalhar nas partes “sem glamour”.

UIs Declarativas vs Imperativas (QML, XAML etc.)

  • Muitos gostam do estilo declarativo do QML para UIs típicas e apps pequenos, especialmente seus bindings de propriedades e a separação entre UI e backend.
  • Críticos dizem que abordagens declarativas têm dificuldade com UIs muito dinâmicas ou “não padronizadas” (painéis acopláveis, layouts salvos complexos, views altamente configuráveis), muitas vezes forçando gambiarras imperativas.
  • Contra-argumento: boa parte disso ainda pode ser expressa declarativamente via propriedades e modelos; o Qt já oferece salvar/restaurar estados de painéis/splitters.
  • Outros sistemas declarativos (SwiftUI, Jetpack Compose, XAML, JavaFX/FXML) são mencionados; as experiências variam de “encaixe perfeito” a “mágico demais, difícil de depurar”.

Papel do QML, Pontos Fortes e Dores

  • Há consenso: QML é ótimo como camada de UI com lógica em C++ ou outra linguagem; escrever grandes quantidades de lógica em JS/QML leva a spaghetti e falta de segurança de tipos.
  • QML é visto como especialmente forte para UIs embarcadas, kiosks e com aparência personalizada; alguns o consideram menos “nativo” por padrão para desktop.
  • São citadas lacunas de integração com desktop: sensação mais parecida com mobile, controles padrão não nativos, widgets menos fortes out of the box do que Qt Widgets, e regras estranhas de escopo do QML.
  • Ainda assim, vários apps de desktop concretos construídos com QML são relatados como bem-sucedidos e performáticos.

Qt vs Electron/HTML/Tauri

  • Há forte rejeição à comparação de Qt/QML com Electron: apps Qt são descritos como significativamente mais leves em memória, mais rápidos para iniciar e melhor integrados às plataformas nativas.
  • HTML/CSS é visto por alguns como “bom o suficiente” ou até preferível; outros argumentam que é centrado em documentos, pesado e desajeitado para UIs complexas de desktop.
  • Tauri é reconhecido como geralmente mais leve que Electron (usa webview do sistema, backend em Rust), mas ainda fundamentalmente baseado em navegador; o inchaço geral dos apps costuma ser atribuído às escolhas de stack e a código ruim, não apenas ao framework.

Licenciamento e Ecossistema

  • A história de licenciamento do Qt é descrita como complexa, com uma mistura de LGPL, GPL e partes comerciais, além de múltiplas relicenciações históricas; algumas organizações continuam no Qt 5.x por causa disso.
  • Esclarecimentos: a funcionalidade central de desktop/DE está disponível sob LGPL; recursos especializados/embarcados podem ter licenças mais restritivas, e alguns evitam LGPLv3 por causa das cláusulas anti-tivoization.

Ferramentas e Bindings de Linguagem

  • A documentação do Qt é amplamente elogiada por ser detalhada e de alta qualidade.
  • O Designer do Qt Widgets geralmente é mais apreciado do que as ferramentas QML atuais. O Qt Design Studio é descrito como pesado, com bugs e produzindo QML confuso, com integração mais fraca com a IDE e UX de design de layout pior do que designers clássicos como Swing/WinForms/VB/Delphi.
  • QML é usado com sucesso com Python (pyotherside), Julia e outras linguagens para prototipagem rápida e alguns apps em produção.