I Switched from Flutter and Rust to Rust and Egui

Original Article ↗ Hacker News Discussion ↗

Immediate-mode GUIs, egui, and accessibility

  • Several commenters note immediate-mode toolkits (egui, Dear ImGui) often have weak accessibility compared to native toolkits or web+ARIA.
  • Reasons given:
    • Implementing full accessibility is “a lot of work,” and browsers/native stacks already invested heavily here.
    • Many immediate-mode toolkits target games/prototyping where accessibility was historically low priority.
    • Accessibility frameworks expect stable identities and trees; immediate-mode UIs conceptually “rebuild” trees each frame, so you need diffing logic to map UI changes (e.g., reordered list items) into minimal a11y updates.
  • Others argue this is less about “immediate mode” and more about custom rendering that bypasses native widgets, especially on the web.

Performance, redraw behavior, and app lifetime

  • One view: egui is ideal for short-lived tools and overlays; “visual scripts” where rapid iteration matters more than polish.
  • Counterexamples: people report building complex apps (word processor, molecule viewers, plasmid editors) successfully with egui.
  • Redraw behavior is debated:
    • Some worry about constant re-rendering and idle CPU/GPU use.
    • Others clarify that with the common backend, egui only repaints on input or animations (“reactive” mode), with an opt‑in “continuous” mode; manual re-render triggering is possible but likened to “manual memory management.”
  • Concern from game developers about egui’s feature growth (multi-pass-ish layout, richer widgets) increasing overhead and technical debt, drifting from the original “<1% frame time overlay” goal.

Flutter vs egui: complexity vs simplicity

  • Flutter is praised for robust, cross‑platform, single‑codebase UI and strong accessibility, but its state management ecosystem (setState, hooks, BLoC, etc.) is seen as complex with many pitfalls.
  • Some argue you effectively must become a state‑management expert in Flutter; with egui, state handling is more straightforward and often implicit.
  • Shipping Flutter+Rust via FFI is viewed as adding complexity (FFI types, glue code), which egui avoids by keeping everything in Rust.

WYSIWYG designers vs code-first UIs

  • Nostalgia for classic WYSIWYG tools (WinForms, Qt Designer, Visual Studio) and their speed for “ugly but functional” internal apps.
  • Critiques:
    • Hard-to-merge generated files, XML ugliness, difficulty with responsive layouts across devices.
    • Many modern stacks favor code for flexibility, maintainability, and better tooling.
  • Others insist WYSIWYG remains dominant where visual design matters (web builders, mobile, game engines) and suggest:
    • Live previews as a middle ground.
    • Stronger Figma‑to‑code pipelines.
    • Opportunity for AI‑assisted drag‑and‑drop UIs that generate layout/code.

Rust GUI ecosystem: alternatives and trade-offs

  • Slint: declarative DSL, live previews, embedded focus, aiming for native-looking widgets and including desktop staples like menu bars. Criticisms center on licensing (GPL3/credit/commercial), and some missing or hard‑to‑style widgets in earlier experiences.
  • iced: Elm‑style retained-mode GUI, considered mature and cross‑platform (desktop + WASM). Some users report laggy behavior on Linux, others say it’s very fast and not immediate‑mode; vsync settings can matter. Recently gained hot reloading.
  • gpui and Dioxus get positive mentions: gpui as an impressive new toolkit; Dioxus for a React‑like, full‑stack Rust approach with shared client/server code via rsx! macros and cfg features.
  • QML is praised as an elegant, reactive language for UIs; some note the main reason it’s less visible is industry’s move toward the web.

Other technical points

  • egui explicitly does not aim for a native look; Slint does.
  • Benefits of “one-language” apps (e.g., all in Rust with egui) are highlighted: unified tooling and debugging, no FFI boundary.
  • On the web, people exploring “IMGUI in the browser” note DOM/VDOM architectures don’t map cleanly to immediate mode; VDOM is seen as an extra indirection. Mithril.js is cited as “closer” (manual redraws) but still VDOM-based.
  • Several comments digress into using Protobuf/gRPC (or JSON/IPC) between Flutter and native backends to keep UI and business logic cleanly separated, with discussion of ports, security, and streaming performance.