Dear ImGui – Bloat-free graphical user interface library for C++

"Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user)."

For those who may be unfamiliar with the "immediate mode" vs "retained mode" terminology here, an aha moment for me was realizing frameworks like React are essentially immediate mode APIs (such as declarative JSX) abstracting an underlying retained-mode system (the DOM).

It may not be a perfect analogy, but seems to be basically true.

Any internal tool or debug GUI has reasonable odds of becoming a user-facing tool eventually, and it's a matter of time until you end up needing to support staff/customers in territories with RTL languages or ideographic character sets. At that point, you end up regretting most of the corners you cut.

I built lots of internal developer tools for a mid-sized western studio and it wasn't long until I had to go back and patch in a bunch of localization support because it turned out the publishers overseas needed to be able to use it and not all of their staff spoke English. Any blind employees were probably completely out of luck (maybe not, I did use Win32.)

i am so curious about your use of colon to pluralize initialisms (which i've always found awkward to pluralize, especially in lower case). is that cultural? an intentional choice?

Dear ImGui is amazing software with great ideas, but at this point I feel like the "immediate" is a problematic lie much like how "immediate mode" graphics rendering hasn't been immediate in years. I think the most appropriate way to describe these libraries is "imperative", because you're constructing retained state by running imperative code and the library is responsible for figuring out how to do what you want it to do.

Any properly functioning UI with the features needed by more than a handful of users ends up having to retain a considerable amount of state. This doesn't mean that you need to construct a huge graph of interconnected object goo, but a bunch of C/C++ calling functions every frame with no retained state won't cut it. Libraries like Dear ImGui and Nuklear largely solve this with a combination of wasted energy (by running your code repeatedly) and magical hidden state (managing retained state in the background for you automatically).

The fact that retained state does end up existing but behind the curtain means that annoying problems manifest themselves due to it being out of your control. For example, a textbox needs to maintain the current selection along with a scroll offset in its viewport, along with an undo/redo history. You might decide to drop some of that but some of it has to stick. In Nuklear's case, it relies on stb_textedit to do a lot of the heavy lifting (great library!) and retains state for you behind the scenes. Because the state management is automatic based on the small amount of information Nuklear has, doing something like collapsing a hideable panel makes the textbox "disappear" at which point the scroll offset, selection and undo/redo history vanish. The user may have accidentally collapsed the panel (or the program did it for them), and you've now responded to that input by throwing away something very important. You certainly could retain all this state inside your application (whether or not there's an API for it in the library is another question), but now you have to come up with a solution for tracking and storing all that state.

Other comments have already mentioned the "page tearing" problem (needing an extra frame to respond to state changes, etc) which is one manifestation of this fundamental issue - that retained state is in fact necessary and hiding it creates new problems - but there are other challenges that are easier to ignore. Accessibility is a major one, and current IMGUI libraries are entirely ill-prepared to address it. Another issue is internationalization - not only is RTL text an issue, but complex character sets require shaping (an expensive operation) which also requires caching and additional infrastructure that is going to clash painfully with the very simple "just draw some text" model used by most of these libraries. International text input is also very stateful and you'll find that interacting with IMEs is quite difficult if you aren't careful about things. (This is especially bad because SDL2 itself has a botched IME implementation, so users of non-western character sets are screwed right out of the gate.)

I've been using Nuklear over the past couple years for some development tools and the experience soured me on IMGUI libraries in general because I kept running into these problems that, in retrospect, should not have been a surprise. The UI had lots of rough edges you'd feel when using it, it was ugly (until I aggressively patched it to address this), it was slow, etc. Dear ImGui is likely higher quality than Nuklear (not that I can say for sure, because I never got it to work due to integration problems) but the fundamental design principles are largely the same and it has its own set of limitations. I'm hopeful that as time passes these libraries will continue to improve, but I've personally moved on to accepting that a good UI needs retained state and I'm focusing on ways to make constructing that state as easy as possible without leaving users who need accessibility or foreign character sets out in the cold.

Some less relevant footnotes:

* The performance obsession demonstrated in some of these libraries is an active hindrance and in some cases actually sabotages performance. Text rendering in Nuklear is "simple" but for remotely adequate performance you end up having to build your own layout cache and take other steps to compensate for the fact that text is not "simple" at all. To avoid running out of memory, you need to come up with a GC for your layout cache. Solving various problems like page tearing will require you to run the whole layout/rasterization process for your UI multiple times, so now your fast "immediate mode" code is actually doing all its work repeatedly, burning CPU. So far tearing out Nuklear and replacing it with my own retained mode framework has improved performance and reduced code size.

* The degree to which Dear ImGui and Nuklear value convenience is, in my opinion, counter-productive - for example the ability to just drop it in and get a vertex buffer + texture pair with text is great but it turns out to mean that the library is doing a bunch of stuff (like font management) itself and replacing that with something modern is actually... very hard. I think the correct approach here is to take steps to make integration easy instead of going for full 'just clone the repo and run make' convenience. I had to aggressively modify Nuklear to have any hope of integrating proper text support at all (and then I couldn't upstream my changes because it turns out that the "single-header" Nuklear library is not actually single-header. another convenience-oriented lie... we're programmers, we can handle extra header files, can't we?)

* Accessibility is really, really hard. More people need it than you'd expect. You need to plan for it in advance, and if you didn't it will be very hard to fix after the fact. I can't say for certain whether Dear ImGui will be able to transition smoothly into an accessible world, but Nuklear's design is woefully unprepared. Every element ideally has a human-readable description (for screen readers) and role (button, etc), and your UI needs to have a coherent structure that can be explored by a screen reader. For users with diminished vision you need robust support for adjustable sizes and theming (so you can improve readability and contrast). You also need to consider alternate input methods - full keyboard, game controller, touch - while these libraries are mostly designed for keyboard+mouse.