Componente GPUI multiplataforma em Rust

• Biblioteca de componentes de UI que permite criar aplicativos desktop multiplataforma usando o framework GPUI baseado em Rust
• Oferece mais de 60 componentes de UI com estilo nativo, combinando a linguagem de design do macOS e do Windows com a estética moderna do shadcn/ui
• Traz recursos avançados integrados, como tabelas virtualizadas, editor de código de alto desempenho, renderização de Markdown/HTML e visualização de gráficos
• Projeto com foco em extensibilidade e personalização, com sistema de temas, suporte multilíngue (i18n) e layout com docking
• No ecossistema Rust, se diferencia de Iced, egui e Qt pelo estilo moderno de UI e pelo desempenho no processamento de grandes volumes de dados

---

Visão geral do projeto

• gpui-component é uma coleção de componentes de UI desktop multiplataforma escrita em Rust e baseada no motor de renderização GPUI
  • O objetivo é permitir criar “fantastic desktop applications” de forma rápida e consistente
  • O site oficial é longbridge.github.io/gpui-component
• Licença Apache-2.0

Principais recursos

• Conjunto rico de componentes: inclui mais de 60 elementos de UI, com opções como botões, listas, tabelas, gráficos e editores
• Design com sensação nativa: inspirado nos controles padrão do macOS e do Windows e combinado com o estilo do shadcn/ui para criar uma interface moderna
• Usabilidade simples: a estrutura de componentes sem estado RenderOnce permite escrever código de forma simples e intuitiva
• Sistema de temas e cores: Theme e ThemeColor oferecem suporte a múltiplos temas e configurações baseadas em variáveis
• Layout flexível: com Dock layout, é possível posicionar painéis, redimensioná-los e montar composições em mosaico livremente
• Renderização de alto desempenho: Virtualized Table/List permite exibir grandes volumes de dados com fluidez
• Renderização de conteúdo: suporte nativo a Markdown e HTML simples
• Recursos de gráficos: visualização de dados com gráficos integrados
• Editor de código: inclui um editor de código de alto desempenho baseado em LSP com suporte a até 200 mil linhas
  • Compatível com diagnóstico, autocompletar, hover e outros recursos
• Destaque de sintaxe: usando Tree Sitter, oferece syntax highlighting tanto no editor quanto em Markdown

Stack técnico e estatísticas

• Composição de linguagens: Rust 98.2%, Tree-sitter Query 0.8%, HTML 0.2%, Shell 0.2%, Python 0.1%, C 0.1%
• Métricas do repositório: 5.4k stars, 223 forks, mais de 45 contribuidores
• Release mais recente: v0.3.1 (27 de outubro de 2025)

Significado em resumo

• gpui-component é visto no ecossistema Rust como um novo framework de UI desktop que combina UI/UX moderna com renderização de alto desempenho
• Complementa limitações de frameworks GUI existentes em Rust e oferece recursos práticos como processamento de grandes volumes de dados, tematização e integração com Markdown
• É um projeto que vem ganhando atenção como candidato a camada de UI padronizada para o desenvolvimento de apps multiplataforma em Rust

[GN⁺]

Comentários do Hacker News

• No ecossistema de UI em Rust, isso parece ser a coleção de componentes mais completa que vi até agora
  Ainda quase não há casos de uso, mas a documentação está ficando cada vez mais bem organizada
  Outro exemplo com nível parecido de acabamento é o fyrox-ui. Mas ele quase não é usado fora da engine fyrox
  A UI em Rust está amadurecendo aos poucos, mas frameworks populares como iced, egui, dioxus e slint ainda parecem ficar devendo no nível de acabamento dos componentes
  Atualizando: este projeto mostra um grande avanço no ecossistema de UI em Rust.
  Dá para executar aqui um app de galeria de widgets com todos os componentes — é só usar cargo run --release

  • O gpui é um projeto separado do Zed Editor, então o uso real provavelmente é muito maior do que o de outros crates de UI em Rust
  • O Fyrox acaba passando um certo ceticismo sobre desenvolvimento de jogos em Rust. É a engine mais madura e mesmo assim ninguém usa. Em vez disso, as pessoas só se empolgam com o ECS do Bevy. No fim, parece que havia interesse apenas no sistema em si, não em fazer jogos de verdade
  • Os frameworks de UI em Rust ainda parecem pouco acabados porque estão mudando muito rápido. Mesmo assim, o momentum é claro. Pela minha experiência pessoal, já foi possível criar UIs de nível enterprise em Rust
  • Instalei o app da Longbridge por conta própria e ele realmente funciona de forma natural como um app nativo de Mac. Roda com muito mais fluidez do que Electron
  • O app de galeria de widgets é impressionante, mas o fato de ter mais de 900 dependências preocupa um pouco. Não sei se isso é normal em apps GUI

• Até o exemplo mais simples tem mais de 1000 dependências. Ele depende de toolkits como GTK, GDK e pango. Essa estrutura de depender de outros toolkits parece meio estranha

  • O GNOME não implementa decorações do lado do servidor, então é preciso depender de libadwaita. Parece que isso é o que puxa todas as dependências relacionadas a GTK
  • No Linux, esse tipo de estrutura é comum. É normal usar GTK ou Qt para desenhar janelas de nível superior ou menus
  • Eu diria que 1000 dependências pequenas e combináveis são melhores. É muito mais fácil de auditar do que uma base de código monolítica gigantesca
  • É uma pena que os projetos Rust hoje em dia estejam cada vez maiores desse jeito

• É amargo ver que muita infraestrutura de base do open source está sendo criada por empresas de trading e cripto. Ainda assim, é positivo que estejam contribuindo com alguma coisa para a sociedade

  • O gpui é mantido pela equipe da Zed.dev, e a Longbridge parece ser uma corretora comum que faz o app Longbridge Pro. Não parece haver nada de especialmente problemático nisso
  • Acho que o espírito do Bitcoin se parece com a cultura hacker. Essa atitude de “consertar o que está quebrado”. A dor de curto prazo pode acabar trazendo ganhos de longo prazo
  • Em alguns ecossistemas, como Rust ou OCaml (Jane Street), essa tendência existe, mas no geral isso parece um pouco exagerado
  • O Facebook, que criou o React, esteve envolvido em casos como o escândalo da Cambridge Analytica e o genocídio dos rohingya. Vendo por esse lado, empresas de trading/cripto contribuindo com open source talvez seja até moralmente melhor

• Fico me perguntando se esses toolkits de UI “modernos” hoje em dia não têm editor visual de UI
  O Qt permitia criar UIs só com drag and drop usando ferramentas como QtCreator ou QtDesigner
  Além disso, alguns itens da tabela comparativa com Qt estão errados — por exemplo, o tamanho mínimo do binário ou a explicação sobre o QSyntaxHighlighter

  • Frameworks como Slint oferecem integração com Figma, então podem ser usados de forma parecida com o Qt Design Studio. Parece que hoje em dia pouca gente percebe o quão poderosos eram os antigos designers de GUI nativa
  • Com base em uma biblioteca de componentes bem acabada, também daria para implementar esse tipo de editor visual em Rust. Bastaria ligar uma estrutura baseada em XML/markup com macros e criar um app de preview em tempo real, funcionando como o Glade ou o XAML
  • O tamanho mínimo do Qt na prática é menor que 20 MB, mas normalmente fica na faixa de 30~40 MB. Os módulos Core, Gui, QML e Widget têm cerca de 8 MB cada, então até um Hello World precisa de 2 ou 3 deles
  • O Qt Designer é aceitável para UIs simples, mas quando você aplica estilização customizada ele quebra rápido. Por isso, acabei escrevendo os arquivos de UI manualmente. Ficou muito mais limpo e menor
  • Dizer que o Qt6 não suporta temas é completamente errado

• Infelizmente isso é um framework. Ou seja, ele precisa ter seu próprio event loop
  Em ambientes que já têm outro loop, a integração fica difícil. Já o egui tem uma estrutura mais de biblioteca, sendo apenas chamado a cada frame

• Fico curioso se a acessibilidade para leitores de tela funciona bem

  • Não executei pessoalmente, mas segundo a documentação oficial, ele oferece suporte ao padrão ARIA. Basta adicionar os rótulos e descrições necessários
  • Mas o Zed Editor é completamente opaco para leitores de tela. Então não crio grandes expectativas
  • Sempre que vejo um novo framework de UI, a primeira coisa que pergunto é justamente sobre acessibilidade

• Queria entender se “nativo” aqui significa só que não é web, ou se usa os widgets padrão do sistema operacional. O ecossistema Java também sofreu bastante com essa diferença

  • O macOS é a única plataforma em que dá para fazer apps realmente nativos. O Linux está dividido entre GTK e Qt, e no Windows há tantos frameworks misturados que até WebView pode parecer nativo
  • Aqui, nativo quer dizer “não é web”. É uma estrutura que desenha diretamente com APIs de GPU
  • Ou seja, é um executável nativo, não algo que use widgets do sistema operacional
  • Não há integração com widgets do sistema; é tudo renderização própria

• Queria saber se este framework implementou acessibilidade (a11y). As UIs em Rust às vezes são bonitas, mas quando surge exigência de acessibilidade é preciso reescrever tudo do zero

  • Se acessibilidade for prioridade, vale considerar Dioxus. Só que ainda não existe uma biblioteca de componentes tão acabada nesse nível
  • O GPUI foi construído pela equipe do Zed, mas continua opaco para leitores de tela. Se acessibilidade for importante, Slint ou Qt (cxx-qt) parecem opções melhores, e como a System76 adotou o Iced, talvez ele também melhore nesse ponto
  • A acessibilidade está implementada

• O recurso de listas e tabelas virtualizadas é realmente excelente. Em muitos frameworks de UI, isso precisa ser implementado manualmente, o que é inconveniente

• Rust tem muitos toolkits de GUI, mas faltam coleções de componentes reutilizáveis
  Esta coleção parece útil, mas a maioria dos componentes é parecida com a lista de componentes de frameworks web. O único elemento mais específico de nativo parece ser o webview. Para coisas como caixa de diálogo de abrir arquivo, ainda é preciso usar bibliotecas externas como rfd, o que quebra a consistência visual

  • Quebrar a consistência visual é, na verdade, uma coisa boa. O usuário quer consistência entre aplicativos. Ou seja, caixas de diálogo nativas do sistema são mais familiares. Softwares profissionais como Blender ou Photoshop são exceções, mas para apps comuns o nativo é melhor
  • A maioria das bibliotecas de UI também precisa de pelo menos alguma integração nativa. Coisas como atalhos, menu do sistema, caixa de diálogo de arquivos e menu de contexto. Esses detalhes aumentam a familiaridade para o usuário
  • O seletor de arquivos deve usar obrigatoriamente a caixa de diálogo padrão do sistema operacional. Implementar isso manualmente não é uma boa ideia