Programación de GUI en modo inmediato

Artículo original ↗ Discusión en Hacker News ↗

Los frameworks de GUI en modo inmediato, como Dear ImGui y egui, prometen código de UI más simple y lineal al redibujar la interfaz en cada frame y evitar el cableado explícito de manejadores de eventos. Los comentaristas lo contrastan con los toolkits tradicionales de modo retenido (Qt, widgets nativos del sistema operativo, layouts web/CSS), argumentando que, aunque el modo inmediato destaca para herramientas dentro del motor, UIs de depuración y algunas apps de escritorio, tiene dificultades con layouts complejos, integración con la plataforma, accesibilidad y uso de energía, salvo que se reconstruyan eficazmente sistemas extra de estado y layout. Varios señalan que los sistemas “declarativos” modernos como React se sitúan en un punto intermedio, y que en la práctica la elección correcta depende menos de la pureza del paradigma y más de la madurez de las herramientas, las necesidades de rendimiento y cuánta complejidad y pulido de UI esperan los usuarios finales.

A alto nivel: GUIs de modo inmediato frente a modo retenido

  • Modo inmediato: la UI se describe en cada frame en código lineal (por ejemplo, if Button(...) { ... }). No hay objetos de widgets explícitos ni controladores de eventos instalados en el código del usuario; el estado suele estar oculto dentro del framework.
  • Modo retenido: la UI es un árbol de widgets/objetos con su propio estado y callbacks; el toolkit “posee” el bucle de eventos y vuelve a dibujar según sea necesario.
  • Varios comentaristas subrayan que la distinción se refiere sobre todo a la API pública, no a si el estado se conserva internamente.

Bucle de eventos, flujo de control y depuración

  • A quienes lo apoyan les gusta tener un único bucle principal y un flujo de control lineal y fácil de depurar, en lugar de callbacks dispersos.
  • Quienes lo critican sostienen que nunca realmente “eliminas” el bucle de eventos; el sistema operativo sigue impulsando los eventos, y la mayoría de los backends IMGUI esperan un patrón tradicional de bucle de eventos.
  • Algunos ven que la simplificación del flujo de control permite desarrollar más rápido, especialmente para desarrolladores a quienes no les gusta la programación tradicional de UI.

Rendimiento, batería y redibujado

  • Escépticos: el redibujado completo constante y el layout por frame pueden desperdiciar CPU y batería, especialmente en portátiles y móviles. Se dieron ejemplos de herramientas IMGUI que consumen una CPU notable en reposo.
  • Otros responden que:
    • Puedes bloquearte esperando eventos y redibujar solo ante interacción.
    • Los frameworks IMGUI pueden rastrear “rectángulos interactivos”, regiones sucias y cachear estado.
    • Algunas bibliotecas ya redibujan solo ante cambios, aunque hay incidencias abiertas y PRs sobre “modos de ahorro de energía”.
  • Sigue habiendo desacuerdo sobre si estas optimizaciones son inherentes o simplemente complejidad extra trasladada al autor de la app/framework.

UI complejas, layout y estado

  • Experiencias pro-IMGUI desde herramientas para desarrollo de juegos: se han construido con éxito editores complejos, inspectores, perfiles y UIs de depuración, beneficiándose de una estrecha integración con la lógica del motor.
  • Quienes critican informan de problemas al pasar de “depuradores chapuceros” a herramientas completas: la gente empieza a emular el modo retenido, manteniendo mucho estado y lógica de layout manualmente, lo que conduce a código desordenado.
  • El layout es un gran punto de fricción:
    • El modo inmediato se considera estupendo para layouts simples y posicionamiento manual.
    • Las restricciones responsivas de varias pasadas (por ejemplo, ajustar texto, centrar varios widgets, redimensionamiento dinámico) son más difíciles; algunas bibliotecas (por ejemplo, ciertos IMGUI de Rust) tienen limitaciones notables.
    • Otros describen algoritmos de layout de varias pasadas que funcionan bien en IMGUI; el reto es el rendimiento y la necesidad de volver a ejecutar el layout en cada frame.

Casos de uso y adecuación

  • Buen encaje:
    • Herramientas dentro del motor, overlays de depuración, editores de juegos, herramientas internas simples, apps con mucha gráfica donde ya existe un bucle de renderizado.
  • Encaje más débil / escepticismo:
    • Apps de escritorio para usuario final donde se espera aspecto nativo, poco consumo en reposo y fuerte integración con la plataforma.
    • Apps móviles, donde la energía, el rendimiento, las convenciones de plataforma y la accesibilidad son críticas; varios recomiendan usar en su lugar toolkits nativos o respaldados por nativo.

Relación con la web y UIs estilo React

  • Algunos ven React, Flutter, SwiftUI, Streamlit, etc. como “parecidos al modo inmediato” porque las UIs se vuelven a declarar en cada render; la VDOM de React se describe como “inmediato sobre retenido”.
  • Otros señalan diferencias en el flujo de eventos y la gestión del estado, pero en general están de acuerdo en que hay solapamiento conceptual.

Accesibilidad, completitud y reinvención

  • Quienes critican enfatizan que las apps serias necesitan localización, accesibilidad y widgets ricos; reconstruir todo esto sobre IMGUI supone un gran esfuerzo y arriesga repetir errores ya resueltos en toolkits maduros.
  • Existen ejemplos de frameworks IMGUI que integran capas de accesibilidad, mostrando que es posible aunque no común.
  • Varios concluyen que ambos paradigmas son herramientas; la principal ventaja de IMGUI es la productividad del desarrollador para ciertas clases de apps, no un reemplazo universal de las GUIs retenidas.