I love the developer experience of Dear ImGUI, even though I use it through Python wrappers that confuse things sometimes. It just slices like a sword through several layers of often-pointless abstraction and puts the control over the main loop right in your hands.
And when you need to read the source to figure something out, it's just a few files of pretty self-evident C-ish code.
It should be the go to for general purpose cross-platform application UI development (instead of Electron,) and it's unfortunate that something so good and so useful is only meant for debuggers and editors.
On the flip side, targeting developers tightens the scope quite a lot! If nothing else, it massively increases the chance your target audience can at least get by with left-to-right text and 7-bit ASCII...
>general purpose cross-platform application UI development
because of the immediate mode paradigm it's not really a general purpose framework. The constant redrawing is just a complete resource hog in non real-time applications. The reason other graphics frameworks retain internal state (which Imgui exactly avoids) is to only redraw components when necessary. In theory you could write yourself some sort of widget state manager on top of it but then you've just reinvented react or Qt or what have you.
It's so popular in games and real time visualization because that's one of the domains where you redraw constantly anyway.
You don't need to have a constant redraw and IMGUI libraries do keep internal state. In fact both of these are explicitly mentioned in the linked article:
> IMGUI does not mean that the library doesn't retain data.
> IMGUI does not mean it needs a continuous loop nor need to refresh continuously.
First off, Dear ImGUI is not very non-English friendly. CJK, left-right (Arabic), emoji, are all problematic. It's also got issues with accessibility. Sure it's great, for it's intended purpose, game tools. But it's not so great for a banking app.
Second, Electron is not just UI. It's networking, file access, 2d drawing API, vector graphics, video conferencing, video playback, audio playback, video capture, audio capture, USB access, image decompressing, WebGL, WebGPU, WebAssembly, and many other things in a cross platform package.
It's trivial to make an app on one OS and ship on the other OSes without actually owning those OSes or even if you do own those OSes it requires almost zero knowledge of those OSes quirks and tools to make an app. Compare that to most other native cross platform frameworks and that's rarely true. Learning XCode on Mac, GCC/make/autotools on Linux, Visual Studio on windows, etc...
I think fassssst means controls common across applications in how, e.g., in macOS and Windows many applications use the same controls for labels, buttons, checkboxes, radiobuttons, listboxes, editor boxes, etc with a consistent look and feel/behavior (something at especially on macOS people do appreciate).
It's not just that. The OS adds features into the native widgets. Spell checking, translation, IME support, definition lookup, reconversion (CJK). You get them all for free and the OS can add more with every version, the least being password insertion. Render your own UI and that can't happen. That's one reason why Flash died. It meant that a new platform (mobile) couldn't give the user new ways it interact where as HTML could because it was up to the browser/OS to provide the low-level widgets, not the app itself.
And when you need to read the source to figure something out, it's just a few files of pretty self-evident C-ish code.