Immediate Mode GUI Programming

High-level: immediate vs retained mode GUIs

• Immediate mode: UI is described every frame in straight-line code (e.g., if Button(...) { ... }). No explicit widget objects or installed event handlers in user code; state is often hidden inside the framework.
• Retained mode: UI is a tree of widgets/objects with their own state and callbacks; the toolkit “owns” the event loop and redraws as needed.
• Several commenters stress that the distinction is mostly about the public API, not whether state is retained under the hood.

Event loop, control flow, and debuggability

• Supporters like having a single main loop and linear, debuggable control flow, rather than scattered callbacks.
• Critics argue you never really “get rid of” the event loop; the OS still drives events, and most IMGUI backends expect a traditional event loop pattern.
• Some see the simplification of control flow as enabling faster development, especially for developers who dislike traditional UI programming.

Performance, battery, and redrawing

• Skeptics: constant full-screen redraws and per-frame layout can waste CPU and battery, especially on laptops and mobile. Examples given of IMGUI tools chewing noticeable CPU at idle.
• Others counter that:
  • You can block on events and only repaint on interaction.
  • IMGUI frameworks can track “interactive rectangles,” dirty regions, and cache state.
  • Some libraries already repaint only on changes, though there are open issues and PRs around “power saving modes.”
• Disagreement remains over whether these optimizations are inherent or just extra complexity pushed onto the app/framework author.

Complex UIs, layout, and state

• Pro-IMGUI experiences from game dev tools: complex editors, inspectors, profilers, and debug UIs have been built successfully, benefiting from tight integration with engine logic.
• Critics report pain when moving beyond “hacky debuggers” into full tools: people start emulating retained mode, holding lots of state and layout logic manually, leading to messy code.
• Layout is a major flashpoint:
  • Immediate mode is seen as great for simple layouts and manual positioning.
  • Responsive, multi-pass constraints (e.g., wrapping text, centering multiple widgets, dynamic resizing) are harder; some libraries (e.g., certain Rust IMGUIs) have notable limitations.
  • Others describe multi-pass layout algorithms working fine in IMGUI; the challenge is performance and the need to re-run layout every frame.

Use cases and suitability

• Strong fit:
  • In-engine tools, debug overlays, game editors, simple internal tools, graphics-heavy apps where a render loop already exists.
• Weaker fit / skepticism:
  • End-user desktop apps where users expect native look, low idle CPU, and strong platform integration.
  • Mobile apps, where power, performance, platform conventions, and accessibility are critical; several urge using native or native-backed toolkits instead.

Relationship to web/React-style UIs

• Some see React, Flutter, SwiftUI, Streamlit, etc. as “immediate-like” because UIs are re-declared on each render; React’s VDOM is described as “immediate on top of retained.”
• Others note differences in event flow and state management, but broadly agree there’s conceptual overlap.

Accessibility, completeness, and reinvention

• Critics emphasize that serious apps need localization, accessibility, and rich widgets; rebuilding all this on IMGUI is a large effort and risks repeating mistakes solved in mature toolkits.
• Examples exist of IMGUI frameworks integrating accessibility layers, showing it’s possible but not common.
• Several conclude that both paradigms are tools; IMGUI’s main advantage is developer productivity for certain classes of apps, not a universal replacement for retained GUIs.