Immediate-Mode Graphical User Interfaces - 2005

in 2016 Casey Muratori wrote a few words about his old video "IMMEDIATE-MODE GRAPHICAL USER INTERFACES (2005)" -- apparently he'd been using the technique for years by then and had coined the, now commonly used, imgui acronym -- see: link and if you dive into that video at 16:50 you'll see a very elegant description of minimal state immediate mode button logic; direct time link: ▶ this video

imgui is a general approach to designing gui libraries proposed by casey muratori in 02005 ▶ this video the particular library in question is omar cornut's 'dear imgui' a gui that would use 100% of cpu on an 0.52-mips mac 512 link would probably use about 0.02% of cpu on one 2201-mips core of a raspberry pi 3 link if you pessimistically multiply that by 32 to account for having 32 bits per pixel instead of 1, and by 12 to account for 1920×1080 instead of 512×342, it comes to 9%. of one of the cores! also it would run in 0.5% of the pi's ram so, to a significant extent, the struggle is no longer to get something approximating your desired user interface running, but to imagine a user interface that's worth people's time to use. so it makes sense to trade off cpu consumption and ram usage for faster experimentation in a lot of cases

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 link 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 ▶ this video so it should be apparent that react falls solidly on the imgui side of the line, which is why people use it

ImGui is engine/GPU agnostic Themeing isn't a just a retained mode thing, you can do wonders with immediate UIs, even though (dear)ImGui doesn't provide much, you can still do wonders: link The gaming cheating community is quite creative as well: link More on that topic: ▶ this video

Funny you mention this. I used to think the same way, and would constantly trip up managing state, until a co-worker who had worked in video games for two decades introduced me to the concept of the Immediate Mode GUI (IMGUI). Casey Muratori first spoke about IMGUI back in 2005, but didn't actually implement it practically: ▶ this video In around 2013, Omar Cornut wrote an incredibly high quality practical implementation of Muratori's concept called _Dear ImGui_: link Using both Cornut's library and Muratori's mindset is incredibly powerful and liberating. Things that would require days of work and multiple files in Qt or Cocoa can be finished in four hours and a couple of hundred lines of IMGUI code. It also uses an order of magnitude less CPU/memory resources (which was an issue for us as we were rendering and displaying RAW video footage in real-time). I find it amazing that this way of thinking hasn't completely dominated frontend programming by now. There is literally no downside to using the IMGUI concept - entire classes of bugs disappear, and your code is simultaneously smaller, easier to maintain and more logical in flow. It's also a shitload more fun to write (something I think that SWE culture overlooks too much) - you spend the majority of your time writing code that directly renders graphics to the screen, rather than fixing obscure bugs and dealing with the specifics of subclassing syntax.