← notes

Everybody just wants immediate mode

2025-09-10

In retained mode, you build a tree of persistent UI objects. Create a button, add it to a panel, add that to a window. When something changes, find the right object and update it. The DOM, Win32, Qt, GTK, Cocoa--all retained mode.

In immediate mode, you redraw the UI every frame as a function of state. No persistent objects. Just "if this condition, draw a button here." Dear ImGui is the canonical example.

Why care? Immediate mode makes UI = f(state). Your UI cannot desync from your data because there is no separate UI state. An entire class of bugs becomes impossible.

This is why everyone loves React. It brought immediate mode thinking to the browser--components as functions of props and state, the virtual DOM handling mutations. The browser is fundamentally retained mode, and React makes it feel like it isn't.

The endless churn of JS frameworks is developers searching for better immediate mode semantics on a retained mode platform. I don't think this framing comes up enough. When people ask "why do we need yet another JavaScript framework?" the answer is rarely framed this way. But that's the core of it.

This lens explains the 2010s. Desktop UI was "solved"--Qt, GTK, WPF all worked. Yet developers reached for Electron despite the bloat. There are many reasons: cross-platform, web talent pool, npm ecosystem. But immediate mode is underappreciated. Developers will pay a real cost to avoid retained mode. The new generation of native frameworks--Flutter, SwiftUI, Jetpack Compose--all converged on declarative, immediate-style rendering.

I love immediate mode. For technical applications, Dear ImGui is hard to beat. Your entire UI defined in one place as a function of data. No scattered callbacks or state sync bugs. Just draw what you need.

When developers add complexity to "solved" problems, ask what abstraction they're escaping. Often it's retained mode.