And you want to integrate it with other rendering, but you have to set it up in the engine phase, so you write a callback "control" (which sets hidden state) that escapes the IMGUI display list and runs your special rendering function:

If you're following along at home, you can see that by the time you have a full featured UI, you have a lot of hidden state inside the IMGUI context.

So IMGUI is no simpler to implement well (and nobody seems to be claiming it is). But is it simpler to use?

It's very explicit, and many programmers like that. You can see what is drawn, and when. Data binding can be just as explicit and easy: a slider control could take a pointer to a float and modify the value directly.

But any sane UI implementation, including IMGUI, needs to retain state. It needs to render and cache text. It needs to know where it last put a control so it can put the next in the right spot. It needs to store skin parameters like fonts and colours, if those are configurable. It needs to know, from frame to frame, what state it can keep and what it can discard, which means that the API must accept that state every frame and check it against the last state every frame.

We are now left with an "IMGUI" wrapper around a retained-mode UI. In other words, we have a retained UI in which the layout data is encoded as function parameters, and the layout must be re-evaluated every frame.

IMGUI is a solution to the problem of UIs that hide an unreasonable amount of complexity for what they do. If you make an IMGUI try to do too much, you get the same complexity, only it's not hidden. It's in all your code that calls the IMGUI.

You can roll a decent UI from scratch. I will attest to this; I've done it twice now.

When

you need that UI in a hurry

it's strictly for debugging

it's about developer convenience

go IMGUI and regret nothing.

When

you need that UI to be user-facing;

you need it to be reusable;

you need to be able to serialize it;

you can anticipate being frustrated at a lack of separation of concerns and having to write MVC wrappers,

bite the bullet and acknowledge that the retained model fits your problem better.

That's the genesis of RUI, a C99 UI library I'm currently whipping into shape, and I'll talk more about it when maturity warrants.