GPUI y egui se enfrentan a un callejón sin salida en aplicaciones de escritorio complejas

A Critique of GPUI

GPUI y egui se enfrentan a un callejón sin salida en aplicaciones de escritorio complejas

El autor sostiene que los modelos de estado de GPUI y egui no escalan para aplicaciones de escritorio complejas. Con benchmarks, muestra que un cambio de estado en una UI grande cuesta milisegundos proporcionales al árbol, no al cambio: 8,4 ms para una etiqueta con 3.000 filas, y 92 ms sin caché. Argumenta que la solución de retener vistas choca con la API simple de GPUI, y que los signals son la alternativa más precisa.

Mantén la API agradable y obtienes actualizaciones del tamaño de una vista. Toma la precisión y pierdes la API agradable.
  1. virtualritz

    El argumento central, reiterado innumerables veces a lo largo del artículo, es "no escala".

    A lo que respondo: "¿A quién le importa? La gran mayoría de las apps no tienen interfaces de usuario complejas".

    Y si las tienen, puedes ingeniártelas con un workaround como el que hizo rerun para egui (descrito en el artículo).

    Ejemplo concreto: mi mayor proyecto de tiempo libre "sugerido" es una app híbrida de modelado 3D que ahora tiene 500k LOC. Usa egui.

    Diría que en cuanto a funcionalidad de modelado está en algún punto entre Grasshopper/Houdini, cerca de 200 nodos de serie + cualquier número de personalizados.

    Eso te da una idea de la UI: grafo de nodos, edición de parámetros, superposiciones de widgets, gizmos. Muchos nodos tienen widgets personalizados, editores de rampas o curvas, etc.

    No es una UI simple en absoluto.

    Pero no perdí ni un segundo preocupándome por el rendimiento del enfoque de egui. Y aunque la UI aparece en mis estadísticas por frame, es insignificante.

  2. x-complexity

    Esto es un anuncio de zgui, disfrazado de artículo crítico.

    Del propio artículo:

    > Declaración: porté el renderizador actual de GPUI para Linux a wgpu2, construí el arnés de benchmarks usado abajo, y trabajo en zgui, un framework de Rust basado en señales que aparece en los gráficos.

    https://github.com/zortax/zgui

    zgui acaba de lanzar la versión 0.1.0 el mes pasado, con 3 meses de historial de desarrollo. Y es su única versión.

    https://github.com/zed-industries/zed/tree/main/crates/gpui

    https://crates.io/crates/gpui/versions

    La última versión de GPUI fue la 0.2.2, hace 1 año.

    La madurez del framework es un factor contribuyente inevitable a la hora de elegir dónde portar tu aplicación.

    ¿Eso significa que solo pueden elegir frameworks de 10 años? No, pero tampoco deberían ir detrás de proyectos de 1 mes.

    Hay mínimos y máximos, y el mínimo está en "definitivamente no proyectos de 1 mes con solo 1 release pública".

  3. jharsman

    El tema es interesante, pero el texto generado por IA es muy difícil de leer y me hace cuestionar si el autor realmente pensó en el problema. Si pensaste en esto, escríbelo tú mismo.

  4. faangguyindia

    Entonces, ¿cuáles son los frameworks GUI más avanzados que han existido, y por qué son superiores a GPUI o egui?

    ¿Qué empresa en el pasado necesitaba una GUI más que Microsoft? ¿Quizás ellos tienen la respuesta? ¿O Apple?

    No creo que las apps de redes sociales sean lo suficientemente intensivas en GUI como para haber desarrollado algo avanzado en este campo.

    La complejidad de la GUI y la complejidad de la aplicación son dos cosas diferentes.

    Los argumentos del artículo suenan razonables pero la conclusión está equivocada.

  5. bluegatty

    Parece divertido, pero Rust es menos adecuado para UX que otros lenguajes: estructuras de datos basadas en árboles, mucho estado feo, orientado a eventos, muy async, y naturalmente todo el json y otras cosas que entran en esa capa no tienen librerías 'muy agradables'.

    No aprovecha muy bien las ventajas de Rust en absoluto, así que el sobrecoste extra es difícil de justificar.

    Creo que definitivamente hay algunas librerías clave que funcionarían bien con Rust (¡wgpu es genial!), pero el lenguaje central en sí idealmente no sería Rust.

    Obviamente, se puede hacer, y estoy seguro de que es muy divertido para algunos devs, pero creo que esto es meter el círculo en el agujero cuadrado. (Edición: es gracioso decirlo porque 'meter el círculo en el agujero cuadrado' es literalmente como decirle '¿paseamos?' a un perro, o sea, '¡levántate, un problema que resolver!', pero creo que a eso me refiero, como que lo que mueve la cola no es necesariamente la mejor opción).

Más de este día

2026-11-09