Componente GPUI multiplataforma en Rust

• Biblioteca de componentes UI para crear aplicaciones de escritorio multiplataforma aprovechando el framework GPUI basado en Rust
• Ofrece más de 60 componentes UI con estilo nativo, combinando la estética de diseño de macOS y Windows con la estética moderna de shadcn/ui
• Integra funciones avanzadas como tablas virtualizadas, editor de código de alto rendimiento, renderizado de Markdown/HTML y visualización de gráficos
• Diseño enfocado en la extensibilidad y la personalización, con sistema de temas, multilenguaje (i18n) y layout con acoplamiento
• Dentro del ecosistema Rust, se diferencia frente a Iced, egui y Qt por su estilo moderno de UI y su rendimiento para manejar grandes volúmenes de datos

---

Resumen del proyecto

• gpui-component es una colección de componentes UI de escritorio multiplataforma escrita en Rust, basada en el motor de renderizado GPUI
  • Su objetivo es permitir construir “fantastic desktop applications” de forma rápida y consistente
  • El sitio oficial es longbridge.github.io/gpui-component
• Licencia Apache-2.0

Características principales

• Conjunto amplio de componentes: incluye más de 60 elementos UI, con opciones como botones, listas, tablas, gráficos y editores
• Diseño con sensación nativa: implementa una interfaz moderna inspirada en los controles predeterminados de macOS y Windows, combinada con el estilo de shadcn/ui
• Uso sencillo: la estructura de componentes sin estado RenderOnce permite escribir código simple e intuitivo
• Sistema de temas y colores: Theme y ThemeColor permiten múltiples temas y configuraciones basadas en variables
• Layout flexible: con Dock layout es posible ubicar paneles, redimensionarlos y crear composiciones en mosaico libremente
• Renderizado de alto rendimiento: Virtualized Table/List muestra con fluidez incluso grandes volúmenes de datos
• Renderizado de contenido: soporte nativo para Markdown y HTML simple
• Funciones de gráficos: permite visualizar datos con gráficos integrados
• Editor de código: incluye un editor de código de alto rendimiento basado en LSP con soporte para hasta 200 mil líneas
  • Compatible con diagnóstico, autocompletado, hover y otras funciones
• Resaltado de sintaxis: usa Tree Sitter para ofrecer resaltado tanto en el editor como en Markdown

Stack técnico y estadísticas

• Composición de lenguajes: Rust 98.2%, Tree-sitter Query 0.8%, HTML 0.2%, Shell 0.2%, Python 0.1%, C 0.1%
• Métricas del repositorio: 5.4k stars, 223 forks, más de 45 contribuidores
• Lanzamiento más reciente: v0.3.1 (27 de octubre de 2025)

Significado general

• gpui-component es visto dentro del ecosistema Rust como un nuevo framework de UI de escritorio que combina UI/UX moderna con renderizado de alto rendimiento
• Complementa las limitaciones de frameworks GUI existentes en Rust y ofrece funciones orientadas al trabajo real, como manejo de grandes volúmenes de datos, tematización e integración de Markdown
• Es un proyecto que atrae atención como posible candidato a capa UI estandarizada para el desarrollo futuro de aplicaciones multiplataforma basadas en Rust

[GN⁺]

Comentarios de Hacker News

• En el ecosistema de UI de Rust, esto parece ser la colección de componentes más pulida que he visto hasta ahora.
  Aún casi no tiene casos de uso, pero la documentación se está organizando cada vez mejor.
  Otro ejemplo con un nivel similar de madurez es fyrox-ui, aunque casi no se usa fuera del motor fyrox.
  La UI en Rust está madurando poco a poco, pero frameworks populares como iced, egui, dioxus y slint todavía parecen quedarse cortos en cuanto a la madurez de sus componentes.
  Como actualización, este proyecto muestra un gran avance dentro del ecosistema de UI en Rust.
  Se puede ejecutar la app de galería de widgets, donde se ven todos los componentes, aquí — basta con cargo run --release

  • gpui es un proyecto separado de Zed Editor, así que probablemente tenga mucho más uso real que otros crates de UI en Rust
  • Fyrox me hace sentir escepticismo sobre el desarrollo de juegos en Rust. Es el motor más maduro y aun así nadie lo usa. En cambio, la gente solo se emociona con el ECS de Bevy. Al final, parece que lo que les interesaba era el sistema en sí, no hacer juegos de verdad
  • Parece que los frameworks de UI en Rust todavía se ven poco maduros porque siguen cambiando muy rápido. Aun así, claramente tienen impulso. Por mi experiencia personal, ya fue posible construir una UI de nivel empresarial en Rust
  • Instalé la app de Longbridge y de verdad se siente natural, como una app nativa de Mac. Corre mucho más fluida que Electron
  • La app de galería de widgets es impresionante, pero sí me preocupa un poco que tenga más de 900 dependencias. No sé si eso sea normal en una app GUI

• Incluso el ejemplo más simple tiene más de 1000 dependencias. Depende de toolkits como GTK, GDK y pango. Se siente un poco extraño que dependa además de otros toolkits

  • GNOME no implementa decoración del lado del servidor, así que hay que depender de libadwaita. Supongo que por eso termina arrastrando todas esas dependencias relacionadas con GTK
  • En Linux, esta estructura es común. Es normal usar GTK o Qt para dibujar ventanas de nivel superior o menús
  • Creo que es mejor tener 1000 dependencias pequeñas y componibles que un enorme codebase monolítico. Es mucho más fácil de auditar
  • Da un poco de pena ver que los proyectos de Rust cada vez crecen más de esta manera

• Es amargo ver que muchas tecnologías base del open source las crean empresas de trading o cripto. Aun así, es positivo que aporten algo a la sociedad

  • gpui lo mantiene el equipo de Zed.dev, y Longbridge parece ser una firma de corretaje bastante normal que hace la app Longbridge Pro. No parece haber nada especialmente problemático
  • Creo que el espíritu de Bitcoin se parece a la cultura hacker. Esa actitud de “arreglemos lo que está roto”. El dolor a corto plazo podría convertirse en beneficio a largo plazo
  • En algunos ecosistemas como Rust u OCaml (Jane Street) sí existe esa tendencia, pero en general suena a una afirmación exagerada
  • Facebook, que creó React, estuvo implicado en cosas como el escándalo de Cambridge Analytica o la masacre de los rohinyá. Viéndolo así, quizá las empresas de trading/cripto que contribuyen a open source hasta resulten moralmente mejores

• Me pregunto si los toolkits de UI “modernos” ya no tienen editores visuales de UI.
  Qt permitía construir interfaces solo con arrastrar y soltar usando herramientas como QtCreator o QtDesigner.
  Además, algunas filas de la tabla comparativa sobre Qt están mal — por ejemplo, el tamaño mínimo del binario o la descripción de QSyntaxHighlighter

  • Frameworks como Slint soportan integración con Figma, así que pueden usarse de forma parecida a Qt Design Studio. Parece que hoy ya no se aprecia lo potentes que eran los viejos diseñadores de GUI nativos
  • Si se parte de una biblioteca de componentes madura, también sería posible implementar este tipo de editor visual en Rust. Se podría conectar una estructura basada en XML/markup con macros y crear una app de vista previa en tiempo real que funcione como Glade o XAML
  • El tamaño mínimo de Qt en realidad es menor a 20MB, pero normalmente anda por 30~40MB. Los módulos Core, Gui, QML y Widget pesan unos 8MB cada uno, así que hasta un Hello World necesita 2 o 3 de ellos
  • Qt Designer está bien para interfaces simples, pero en cuanto aplicas estilos personalizados se rompe muy rápido. Por eso terminé escribiendo los archivos UI a mano. Quedó mucho más limpio y más pequeño
  • Decir que Qt6 no soporta temas es completamente incorrecto

• Por desgracia, esto es un framework. Es decir, necesita tener su propio event loop.
  En entornos donde ya existe otro loop, integrarlo es difícil. En cambio, egui tiene una estructura más tipo biblioteca que simplemente se llama en cada frame

• Me pregunto si la accesibilidad para lectores de pantalla funciona bien

  • No lo he probado directamente, pero según la documentación oficial, soporta la especificación ARIA. Solo hay que agregar las etiquetas y descripciones necesarias
  • Pero Zed Editor es totalmente opaco para los lectores de pantalla. Así que no tengo grandes expectativas
  • Cada vez que veo un framework de UI nuevo, lo primero que pregunto es precisamente por la accesibilidad

• Me pregunto si “nativo” significa simplemente que no es web, o si usa los widgets nativos del sistema operativo. En el mundo Java también se sufrió mucho esa diferencia

  • macOS es la única plataforma donde se pueden hacer apps realmente nativas. Linux está dividido entre GTK y Qt, y en Windows hay tantos frameworks mezclados que hasta un WebView puede parecer nativo
  • Aquí, nativo significa “no es web”. La estructura dibuja directamente usando APIs de GPU
  • O sea, es un ejecutable nativo, no que use widgets del sistema operativo
  • No hay integración con widgets del sistema; es renderizado completamente propio

• Me pregunto si este framework implementó accesibilidad (a11y). Las UI en Rust a veces se ven bonitas, pero cuando surge un requisito de accesibilidad hay que reescribir todo desde cero

  • Si la accesibilidad es importante, valdría la pena considerar Dioxus. Aunque todavía no tiene una biblioteca de componentes tan completa como esta
  • GPUI está construido sobre la base hecha por el equipo de Zed, pero sigue siendo opaco para lectores de pantalla. Si la accesibilidad importa, Slint o Qt (cxx-qt) serían mejores opciones, y como System76 adoptó Iced, es probable que también mejore por ese lado
  • La accesibilidad sí está implementada

• La funcionalidad de listas y tablas virtualizadas es realmente excelente. En muchos frameworks de UI era incómodo porque había que implementarlo uno mismo

• Rust tiene muchos toolkits GUI, pero le faltan colecciones de componentes reutilizables.
  Esta colección parece útil, pero la mayoría de los componentes se parecen a los de frameworks web. Lo único realmente específico de nativo sería el webview. Para cosas como el cuadro de diálogo de abrir archivo hay que usar bibliotecas externas como rfd, así que se rompe la consistencia del estilo

  • Que se rompa la consistencia del estilo es, de hecho, algo bueno. Los usuarios quieren consistencia entre aplicaciones. Es decir, los diálogos nativos del sistema operativo les resultan más familiares. Software profesional como Blender o Photoshop sería una excepción, pero para apps comunes lo nativo es mejor
  • La mayoría de las bibliotecas de UI también necesitan al menos una integración nativa mínima. Cosas como atajos de teclado, menús del sistema, diálogos de archivo o menús contextuales. Eso hace que la app se sienta más familiar para el usuario
  • El selector de archivos definitivamente debe usar el diálogo predeterminado del sistema operativo. Implementarlo por cuenta propia no es buena idea