Yes, I use Raylib for toy games, and for toy apps. Raygui, the Raylib gui library, is an immediate-mode-gui. It doesn't seem to hog any resources for the frame updates, but I lower it for apps where I don't need very high refresh rates on state changes such as moving stuff around or changing an input in a dialog or text box. I've been playing with immediate-mode-guis for years (nuklear, imgui, etc.), so I wasn't sure what was novel about this. There are tricks to store scenegraphs and only update what changes, which pushes you away from true immediate mode anyway. I am more curious about how you render fonts at scale. Do they implement sub-pixel rendering or SDFs to achieve variable resolution clarity?

I think the point here is that we've worked ourselves into a corner with web technologies. The web is very reliant on GPU rendering, but when building an app with DOM + CSS, you don't have direct access to all that power. You have to be very careful to construct your application in such a way that it can be efficiently rendered, and actually use that GPU power.

Basically, they're getting rid of the middleman: the web. Think about most modern web frameworks (React, Angular, etc.), they're basically immediate mode GUI frameworks, but we do "virtual diffing" in order to translate our immediate-mode-like code into DOM (a retained mode UI framework), then the web renderers the DOM via immediate-mode-like patterns again. Pretty strange if you think about it.

Our stacks of technology are getting in the way of creating good software. So yeah, it's on old idea, but in light of the state of the art in IDEs and Text Editors today, this is an interesting approach.

Note, this is a problem in the first place because of how good the web is. The web has so much tooling, cross-platform support, and documentation / learning resources that it's being overused in places where it's very inefficient, simply due to momentum and mindshare. When you have a hammer...

Now, one of the biggest reasons for the success of the web is cross-platform support, but it's not just cross-platform support. It's the only write once run anywhere platform, truly. Most other cross-platform frameworks require you to think about the native environment at some point, but it's very rare on the web because of the robust standard library including Media access, Networking and even more rarely used APIs like WebMIDI. Not to mention that web design culture allows you to ignore the ui patterns of the native OS you're targeting, allowing more cross-platform savings.

If we can somehow manage to throw away the DOM + CSS (except, perhaps, for decoration) and replace them with immediate mode frameworks, combine that with WebAPIs for interfacing with hardware, and decouple those from JS (maybe via WebAssembly), then we have a competitor to the web for complex cross-platform software that is actually interesting. Perhaps Zed and their Rust-based GUI framework could help push us in that direction.

Edit:

Another aside, the performance of immediate mode GUI. You could argue that retained mode UI can be made to have better performance than immediate mode, but I think the right combination of caching and framework-level optimizations to allow for partial updates are the solution.

You might say "that's not immediate mode though?", and sure, but what we care about here is fast applications that are easy to build. We've discovered that writing code via declarative patterns has huge benefits over "object-soup", so our goal should be to make those patterns as fast as possible. I think the DOM and retained-mode GUI is a just a result of the Java style of Object Oriented obsession.