ImGui is great if you need an ad-hoc UI for development/debug tools, but it's not meant to be used in actual applications aimed at end-users. I can't speak for other devs but I certainly wouldn't want my development tools waste time with pointless animations. I hope this doesn't encourage even more devs to build inaccessible software featuring ImGui's idiosyncratic, non-standard UX.
I agree with your points about ImGui's intended use case, though I think the landscape is a bit more nuanced. You're right that ImGui excels for dev tools and that its non-standard UX isn't ideal for end-user apps. That said, devs reach for ImGui in end-user apps because lightweight cross-platform alternatives are scarce. Qt is heavy, Electron is heavier, native toolkits mean multiple codebases.
I built a techy tool with ImGui (JSONL Viewer Pro) and it works well enough for users who care more about functionality than polish. Not saying it's right for consumer apps, but for technical tools it can be pragmatic.
I've thoroughly enjoyed using ImGui for tooling around image processing, computational geometry, a bunch of 3D projection stuff. The fact that it's based on OpenGL or Vulkan or whatever backend you want is a big win for this kind of work. I can just take a bunch of pixels, throw them into a texture, and render some quads with those textures painted on them after going through some 2D transformations or 3D projection/transformation. It's quite beautiful for all of this. ImPlot for doing basic data plotting and the built-in ImGui widgets for controlling the whole thing.
Exactly, I was working on a little client for a self-hosted server app. Imgui is a rare mix of fast, lightweight, trivially cross-platform and stable, so I went with it and had the client easily compiling for Windows, Linux and browser, while being trivial to work with.
I have otherwise mostly given up on making GUI applications because I simply don't have time to pick up a bunch of UI toolkits for all the different platforms, pulling a massive dependency into my project and requiring constant maintenance to keep the program working.
It also have bindings for a ton of languages, so for people who jump languages a lot, it's always nice to be able to reach for something more familiar that you can learn across different codebases but same concepts. Same thing for the backend/engine, UI code remains the same, but easy to switch to others or even wrapping it yourself for platforms that are under NDA.
I know that at least one modding framework for a certain online game makes use of ImGui (or some equivalent thereof). Given the use case it does make a lot of sense, considering they're essentially strapping a third party UI onto an existing 3D accelerated application, not sure what else you'd use for that. Since the users are technical enough to install the mod framework anyways, they tend to be the sort that can handle the UI.
It can be a bit wonky though, I regularly spot UI/UX decisions that seem to map more closely to what the developer is doing under the hood, or their own mental model of the problem, than what one might consider to be an intuitive way of interacting with the system.
IME, it's great for building full standalone applications. I've used it to build several internal tools for non-engineers. A tool like that doesn't need to work with a screen reader, or have native buttons, etc. It needs to be easy to build and iterate on.
This isn't to say a tool for non-engineers should have animations to make it useful. ImAnim should probably be used sparingly, if at all.
If you need the features of a full GUI toolkit, then by all means use Qt or wxWidgets etc, but that's a very big jump in project complexity.
For applications where the aim is high sales volume and low support, you're absolutely right.
But "development/debug tools" is actually just a subset of professional or industrial utility applications where user count is low and support is on the extremes (either "capable self-support" or "Yes, Bob, of course we'll add that for you").
And in those utility applications, you probably don't need the noisy toy animations associated with modern consumer software, but animated data representations can be really valuable.
imgui success is a silent protest from tons of C++ developers, fed up with the over-engineering and enterprise-ification of everything in this bloated ecosystem.
>I certainly wouldn't want my development tools waste time with pointless animations.
On one hand I agree. On the other: where are these high performance real-time GUI kits these days? If it came down to IMGUI or shoving Electron into my app...
I somewhat mirror this opinion, but I would like to point out that there are scant alternatives that meet the intersection of attributes ImGui possesses. The best alternative I've seen as of late is Slint[1]. It's early days but it's looking very promising and is light enough to work on embedded systems.
ImGui is just very weird. For the intended use case it is quite good, but for more general applications it is just not a good UI library.
It is popular mostly because all alternatives are really bad, if "all" you want is a functional GUI to deliver some developer tool. Qt means you have to dive really deep into a C++ project. The web technologies are all far too heavy and complex and you don't really any of the power. There also are many other alternatives, none of them really do what ImGui does.
I depends on the field. On VFX/Game world, Dear ImGui seem to be the way to go. Almost all news comer in this field sells Dear ImGui based software. It's fast and light and trivially profilable that's what matter matter for real time applications. And bonus can be integrated in any platform in few hour of devs. Before having any ui in VR or game console (not necessary debug/dev tool) in Qt or anything else it will take ages.
I’m still waiting for the day for someone to get a clue and build a pro or prosumer level LLM front end with Imgui. It’s the perfect use case for imgui to have a “blender” type product.
