Maybe it's just a personal experience thing? I came across both ways of thinking as a junior dev, so to me retained mode was just a footgun rich environment.
I could imagine if you had decades of experience using retained-mode, though, then you'd find that way of thinking more natural.
This affects all GUIs, if you have a lot of elements then you have to be careful not to propagate complex updates through the whole tree because it kills your performance. There are various tools to deal with this, one of them is making it retained mode, but I would say basically all of those tools come with more footguns in that the GUI can easily end up in an inconsistent state. That's what you trade for performance.
I've heard that argument before, yet for almost all apps I've used in real life the opposite is true.
Game UIs are (from what I understand) written almost exclusively ImGui-style, with every single widget being fed updated state data every single frame as part of the game loop.
Yet, for whatever reason, even crazy-complex UIs like SupCom's seem to have no issue rendering in realtime with an entire 3D game running in the background, while simply resizing the window I'm typing into right now (a single textedit on a static HTML page) creates visible lag and chews up full CPU on a 2015 Macbook.
That's not to say retained-mode GUIs can't be performant (embedded systems rely on retained-mode to have reasonable performance), but on a modern system it seems like the loss in performance caused by inefficiently synchronising state in retained-mode GUIs is several orders of magnitude higher than the losses caused by pushing a couple of hundred textures every frame in an ImGui context.
The thing is those are likely to be simple GUIs. Those are a great use case for immediate mode. But try it with something that has a lot of:
- Wrapping text labels
- Widgets that are similar to CSS flexbox where the size of elements depends on other elements
- List/tree widgets or text editor widgets with large datasets in them
And then you will notice performance tanks. Think of trying to build a text editor that way, if you opened a 5MB text file, you would have to rescan the whole 5MB and compute reflow for it every time.
Game UIs do not generally involve user interaction based on the position of a pointer within the 2D screen geometry. They generally have a very limited event/input system that only takes effect via an overlay. Objects do not come and go from the "model" as a matter of course. They certainly do a LOT of drawing, and they do it very fast, but the challenges of UI design (particularly toolkit design) don't really reside in "how do we draw this stuff really fast".
I do often reflect on how fast game UIs draw, and compare that to the headaches we have in the UI of a digital audio workstation. It generally seems almost inconceivable how we could be so slow in comparison. But then I think about all the ways the user has to interact with the actual UI (not the backend data model), and it starts to seem like a different sort of programming model entirely.
I play games very infrequently, but my anecdata is the opposite: games usually have laggy UI with an inconsistent reaction to input events, noticeable latency, frequent breakage and generally worse user experience (and of course mostly without the ability to resize anything, to compare with browser), even when compared to browsers and Electron apps.
I love the immediate mode style of developing, but ImGUI specifically, at least without third party patches and extensions, has very awkward and limited layout (for example, I'm still waiting for this to get merged[1], which would make it easier), its styling support is relatively minimal (but it can be made look pretty nice) and its accessibility support is non-existent. I also find the API slightly clunky, although its not bad once you get used to it.
Overall, I really like Dear ImGUI and I love how easy it is to expose data to a UI through it. Its much more pleasant to use than a traditional retained mode widgets API. But Dear ImGUI isn't a good general purpose UI (nor was it designed to be one), although I could see the immediate mode API work well for one. I started making a complex editor for a toy engine in it and while it worked ok, the reasons above made me cut it back to just some basic in-engine stuff and the rest is exposed over an optional embedded web server module and a react app as the editor. Its only a toy, but you would use the in-engine ImGUI editor to see the scene rendered in-engine, move objects around etc, but you would use the react app to edit object properties, add assets and behaviours and whatnot. It made it much easier to create rich editors for things like behavior trees, node graphs, etc. Although since its just a toy, I didn't implement a lot of this stuff yet and haven't had time lately to get back to it.
I could imagine if you had decades of experience using retained-mode, though, then you'd find that way of thinking more natural.