GPUI: la crítica que cuestiona el Rust de Discord

Qué es GPUI y por qué Discord lo eligió para reescribir su cliente

GPUI es un framework de interfaz en Rust que dibuja su propia UI con la GPU en lugar de embeber un navegador o usar widgets nativos de la plataforma: usa Metal en macOS, DirectX 11 en Windows y wgpu en Linux, según su documentación oficial. Ese detalle importa porque es el mismo framework con el que se construyó Zed, el editor de código de los creadores de Atom y Tree-sitter.

El framework dejó de ser un tema de nicho cuando Discord confirmó que reescribe su cliente completo en Rust. Según Dexerto, el cofundador y CTO Stanislav Vishnevskiy explicó a comienzos de noviembre de 2026 que la compañía usa Rust desde 2018 en infraestructura y tecnología de voz, y que el objetivo era llevar todo el cliente allí: eso implica dejar atrás Electron en escritorio y React Native en móvil. La aclaración clave que dio: no es Tauri, es GPUI. La captura que acompañó el anuncio mostraba una aplicación llamada Discord Phoenix consumiendo unos 290 MB de RAM, frente a los 1,57 GB de Chrome o los 653 MB de Spotify en la misma pantalla, según el mismo medio.

Ahí está el gancho para cualquier founder: la promesa no es solo velocidad, es memoria. Y sobre esa promesa acaba de publicarse una crítica técnica incómoda.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La tesis: el modelo de estado es el problema, no el lenguaje

El análisis lo firma un desarrollador que conoce GPUI por dentro: portó el renderer Linux actual del framework a wgpu, construyó el arnés de benchmarks que usa en el texto y trabaja en zgui, un framework Rust basado en señales que aparece en sus propias gráficas. Él mismo lo aclara, así que conviene leer los números con esa advertencia.

Su argumento central cita a Raph Levien: dentro de cada framework de UI hay algún tipo de framework de incrementalización. Una UI es una función del estado, y el estado cambia de a poco. Entonces todo framework tiene que responder una pregunta: cuando un valor cambia, qué se vuelve a ejecutar.

El autor clasifica los modelos así:

Inmediato (egui): toda la UI, en el siguiente frame. Nadie detecta el cambio.
Elm (Iced): toda la función de vista, y después un diff.
Views (GPUI): cada vista sin caché. El desarrollador avisa con notify.
Señales con re-ejecución (Freya, Compose): los componentes que leyeron el valor.
Señales de una sola pasada (Floem, Solid, zgui): los closures que leyeron el valor.

En GPUI el problema es estructural. notify lleva el id de la entidad, pero Rust no tiene write barrier sobre &mut, así que el framework no puede saber qué campo cambió, ni siquiera si cambió algo. El autor lo compara con el diagnóstico que el equipo de Angular hizo de zone.js en 2023: solo es capaz de notificar cuando algo pudo haber pasado, y ese enfoque no ha escalado bien. notify es más preciso porque nombra una entidad, pero dice lo mismo: por debajo de ese id, GPUI no sabe nada y re-renderiza toda vista que no esté detrás de un .cached() válido. Y .cached() casi no se usa en aplicaciones reales.

Los números: qué cuesta cambiar una etiqueta

El benchmark es concreto: 3.000 filas vivas, una vista cacheada por fila, y un solo label que cambia. Resultado: 8,4 ms. Un hover, una tecla y escribir un valor igual al anterior cuestan lo mismo, porque el costo sigue al árbol y no al cambio. El crecimiento es de unos 3 ms por cada 1.000 filas vivas. Si las filas se escriben como elementos planos, el mismo label tarda 92 ms. Una guarda de igualdad escrita a mano baja la escritura redundante de 7,9 ms a 0,9 µs, y eso muestra cuánto trabajo queda para cada punto de llamada.

El fork gpui-fast mejora el caso de 3.000 filas de 8,4 a 3,4 ms, pero el frame sigue recorriendo el árbol completo. Y el propio equipo de Zed midió que la retención era 1-3% más lenta que apagada en cargas de trabajo ordinarias, y advirtió que las victorias en microbenchmarks no predecían los resultados en el editor real.

El resto de la tabla ayuda a dimensionar:

Iced construye 39.023 widgets y tarda 7,3 ms por un label; con lazy baja a 5,7 ms. En una lista virtualizada, en cambio, es el más rápido medido: 0,19 ms.
egui tarda unos 32 ms por edición pequeña en 3.000 filas, o 19 ms con accesibilidad desactivada.
Floem gasta 0,01 ms en trabajo reactivo y luego unos 14 ms en layout.
Vizia ejecuta 4 bindings y recorre 120.091 entidades: 46 ms.
Slint escribe un valor igual en 4 µs, pero tarda 172 ms en un label.
Freya produce 5 mutaciones y visita 57.050 nodos de layout.
zgui, el framework del propio autor, hace el label en 0,69 ms y unos 0,26 ms por 1.000 filas, unas 12 veces más plano que GPUI. Él mismo pide tomar ese número con pinzas.

Las mediciones son medianas de apply y settle, en una sola máquina: i9-13900K, RTX 3080 Ti, Vulkan, Linux. Sin Windows, compositor ni input.

El costo que no aparece en las gráficas

Aquí está la parte que más incomoda. Para actualizar un label sin reconstruir el sidebar, ese label tiene que ser una vista propia: una entidad, un Render, una suscripción, una copia del valor, una guarda escrita a mano y un dueño. Todo eso para expresar que un label depende de un contador.

El autor lo dice sin vueltas: la gente elige GPUI porque render es una función plana del estado. Una UI donde cada proyección es una entidad con su suscripción y su guarda ya no es eso: es un grafo de señales armado a mano con piezas más pesadas, donde una arista olvidada es silenciosa. La nota de diseño de Zed lo confirma: las notificaciones faltantes son bugs de la aplicación.

No es un problema nuevo. El autor lo lee en la historia de la web: la guía de estilo de Redux pide preferir más componentes suscritos al store leyendo datos a un nivel más granular, y MobX recomienda crear muchos componentes observer pequeños. Ambos te dicen que construyas el límite a mano porque el framework no puede inferirlo. Y el resto del ecosistema se movió a lecturas rastreadas: Angular, Vue, Svelte y Solid construyen sobre señales o equivalentes, y el equipo de Svelte lo resumió diciendo que se dieron cuenta de que Knockout tenía razón desde el principio.

¿Qué significa esto para tu startup?

Si estás eligiendo stack para una aplicación de escritorio, esta discusión no es académica: es una decisión de tres a cinco años.

Mide con tu propia carga antes de comprometerte. El benchmark del artículo es reproducible y el punto es simple: prueba con 3.000 filas y un cambio aislado, no con el demo de 20 elementos. La diferencia entre 8,4 ms y 0,69 ms solo aparece cuando la UI crece.
Trata el modelo de estado como una decisión de arquitectura, no de librería. Si eliges GPUI, egui o Iced, estás aceptando que la granularidad la pones tú, a mano. Documenta cada notify y cada guarda de igualdad como parte del contrato, porque un aviso olvidado no rompe el compilador: rompe la UI en producción.
Separa el estado de la capa de render. El propio autor señala que la convergencia del sector es hacia lecturas rastreadas. Un modelo de datos que no dependa del framework te deja migrar sin reescribir la lógica de negocio.
Pregunta qué estás comprando. En el caso de Discord, el argumento público es memoria: 290 MB frente a un cliente Electron. Eso es un problema de runtime, no de modelo de estado, y se resuelve igual con Rust nativo.

La otra cara: cuándo GPUI es suficiente

El autor no pide tirar el framework. Reconoce que Zed se siente rápido y que él mismo usa egui para interfaces de depuración en juegos con bevy. Su lectura es que GPUI hace un frame completo relativamente barato, y eso probablemente alcanza para muchos casos de uso. Zed, dice, es una aplicación relativamente simple en términos de UI: una barra con unos botones, un sidebar y un editor de texto que se implementa como elemento custom y se saltea por completo el layout y las vistas de GPUI. Por cuenta del propio equipo de Zed, una ventana tiene decenas de nodos y unos pocos miles de elementos.

También reconoce que las señales no son una bala de plata: Floem, con todas las celdas leyendo una única señal global de revisión, es el resultado más lento de la gráfica. El equipo de React llegó a la misma conclusión desde el otro lado: en un benchmark con una única entrada gigante, un runtime estilo señales decepcionó, y Joe Savona concluyó que el modelo de datos es igual de importante, quizá más, que el algoritmo. La forma del estado tiene que parecerse a la forma de las lecturas.

Conclusión

La crítica no es que GPUI sea lento. Es más incómoda: GPUI es rápido en el caso que muestra y deja de serlo cuando la UI se parece a una aplicación real, y el arreglo, retener más y ser más granular, te obliga a escribir a mano justo lo que hacía atractiva su API. Lo mismo aplica a egui y a la arquitectura Elm de Iced.

Para un founder, la lección es de asignación de recursos. Si tu producto es una herramienta de escritorio con listas largas y estado compartido, el framework no te va a resolver el problema de rendimiento: te va a dar un punto de partida cómodo y una deuda de granularidad que aparece cuando el producto crece. Elegir Rust nativo por memoria y arranque tiene sentido, y Discord lo está haciendo con números concretos, pero conviene saber de antemano qué parte del trabajo te queda a ti.