The Dear ImGui readme is a good starting point:

https://github.com/ocornut/imgui

...now of course Dear ImGui is a specific implementation of the immediate mode UI philosophy, but the general ideas transfer to other imguis as well.

There is also microui, which I like[0], it's much smaller but still gets the job done.

Which I forked to work with SDL2[1], no guarantees. It's fun to hack on.

[0]https://github.com/rxi/microui

[1]https://github.com/kennethrapp/microui

It is not synonymous, but you are right that they are very similar concepts.

React's VDOM actually works just like immediate mode, updating it all on every "re-render" (with diffing taking care of updating only the parts of DOM that actually need an update). So it's a bit like "immediate on top of retained mode".

popular imgui toolkits like dear imgui (fortunately, nobody yet argues that dear imgui isn't really imgui) also actually retain some per-widget state

i would say that the key question is whether widget deletion and updating is implicit or explicit; it's a question about how the api is designed, not how it's implemented

with immediate-mode graphics like <canvas> or windows gdi, if you update the screen and forget to visit a certain rectangle, that rectangle disappears from the screen. the same thing happens in an immediate-mode gui if you are drawing a window and forget to visit a certain checkbox. both whether it appears or not, and everything about how it's drawn, are guaranteed to be up-to-date with your

with retained-mode graphics like svg or tk canvas or current opengl, if you update the screen and forget to visit a certain rectangle, by contrast, that rectangle stays exactly the same as it was before. the same thing happens in a retained-mode gui if you are drawing a window and forget to visit a certain checkbox: the checkbox is displayed in the same way it was displayed before, and it may be outdated with respect to the program data it's nominally supposed to represent

omar's explainer at https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi... pretty much agrees with the above, though he goes into a lot more detail. similarly casey's talking-at-the-camera video in which he popularized the concept https://youtu.be/Z1qyvQsjK5Y?t=6m30s

so it should be apparent that react falls solidly on the imgui side of the line, which is why people use it

React maybe to a point but in general no.

Immediate means you get to decide (or even *forced*) how each and every frame gets drawn. Its opposite is retained GUI which means you have a set of data structures that are automagically drawn by the GUI library. Immediate GUI libraries work with functional-like types while retained GUI uses more data-oriented / object oriented types. Immediate mode is imperative, retained mode is declarative.

Immediate can offer very low level control and easier combination of various drawing interfaces. Wanna put a button on top of your game canvas? It is basically inserting more code / function calls that just draws the thing in an event loop. However you're again responsible for parsing input (helper functions exist of course) and directing things to correct place yourself.

In retained GUI you define you need a canvas such and such place and a button with red borders and a click() callback that gets called automatically. The GUI framework does all the routing and drawing for you. If it doesn't support putting a button over a canvas, you have to do 5x work to customize it and add a new component type.

Immediate mode seems the way to go isn't it? But now you have a huge event loop that you have to split and organize. It usually takes weeks to onboard newbies and you have to write everything yourself (with the help of the libraries). If you mess up the organization, you'll have to search what exact bit of code draws what. Refreshing the UI and looks will require many manual modifications rather than a simple stylesheet change. And immediate GUI has no caching implemented. You are responsible for implementing any such thing. Otherwise you'll learn about the thermal and power limits of the system very quickly.

At its very core all GUI is immediate. Because a GPU is still a processor. A very special one that's optimized for doing mostly branchless and mostly simple arithmetic but still a processor with a machine code and memory. So all retained GUI libraries have a immediate drawing core.

Immediate mode is a fuzzy concept, as witnessed by this writeup: https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...

Immediate mode means instead of changing the state of UI widgets individually, the entire UI is redrawn with the current state. Afaik this has slightly worse performance but can simplify the code because the UI itself doesn't hold any state.

> because the UI itself doesn't hold any state.

...which isn't actually true in most immediate mode UI frameworks. They absolutely do persist state between frames. That state is just on the other side of the API invisible from the API user.

'Immediate mode UI' is only an API design philosophy, it says nothing about what happens under the hood.

> 'Immediate mode UI' is only an API design philosophy, it says nothing about what happens under the hood.

Well, if you have a traditional immediate mode API like:

    if (button("Start"))
        start();

Then it's not just about the API philosophy: at the very least, it ties the event handling to the drawing.

Which kinda makes sense, because a non-existing button usually isn't clickable, and also wouldn't be able to emit events in an event-driven API ;)

Btw, the drawing doesn't happen in the button function, it just tells the UI system that there exists a button with the label "Start" in the current frame. The rendering usually happens much later after the UI system has collected the entire UI description for the frame, otherwise rendering would be very inefficient.

In graphics programming, immediate mode is the legacy, manual way of drawing.

You'd have code that would "draw thing 1", move, then "draw thing 2".

Modern pipelines instead have you upload your vertex data to the GPU and write shader code that tells the system how to draw it. They become managed by the GPU and your code cares less about explicit drawing.

Another way to look at this is that "immediate mode" feels much more imperative than the modern asynchronous graphics pipeline. You tell the system to draw or render something, and it immediately does so.

This post has another good explanation with simple code:

https://stackoverflow.com/questions/6733934/what-does-immedi...

It's much easier to wrap your head around immediate mode though, and several tools with this imperative/immediate philosophy (such as imgui) are popular.

Edit:

Here's a fantastic comparison: https://cognitivewaves.wordpress.com/opengl-vbo-shader-vao/

(See "Immediate" vs the more modern code that follows.)

Any decent immediate mode framework, including Dear ImGUI, has backends which just send quads to the GPU. The code is imperative but it just winds up filling a vertex buffer.

Despite both having "immediate mode" in the name, immediate mode OpenGL and immediate mode GUIs share very little in common. Pros/cons definitely don't carry over at all.

Apart from most of your comment being irrelevant for immediate mode UIs, the rest is also at best misleading, since in modern 3D-APIs draw commands are also issued from scratch each frame (if only to kick off GPU shader code).

The very early D3D versions actually had an optional 'retained mode API' in the mid-90's, but that quickly went the way of the Dodo.