Desktop web-apps won. Simply because native UI libraries never evolved past their 90s days. Either the UI is defined in some DSL, that's loaded (or compiled) and then you spend most of the time writing getElement(pathToElement) and wiring it up, or you have to boilerplate create each element and parent.addChild(element).
And wiring it up is also a pain. Send a signal or event, add a listener or slot, or whatever fancy name each framework comes up with, and if you have to modify another element, it means querying for it, or having a singleton, or passing a reference/pointer, or whatever. It's so friggin-old school.
In the meanwhile, the web discovered reactivity, components, declaring the UI and having the logic in the same file, live debugging, tight development loops, and so much more.
Is it just too difficult for native frameworks? Is it a sunken cost issue or fear of breaking backwards compatibility? Why can't native UI development be as easy and approachable as web dev?
Don't get me wrong, I need webdev like a child needs cancer, but I've tried Slint, imGUi, Qt, Gtk, wxWidgets, and more and the experience makes me want to blow my brains out every single time. I dread writing any native GUI that I got desperate enough to try writing a TUI but that's unbelievably worse!
It's gotten so bad, that Tauri and Dioxus are now on the menu. I never wanted to mix web dev into my native applications, but it feels like the abominably anachronistic state of native UI development is just forcing not only me, but anybody who wants to have a good experience writing native UI apps (especially those that are multi-platform), to use a fucking web view! A memory-hogging web view!
What didn't you like about imGUI? Just curious
Maybe I used it the wrong way, but it had to pass down the UI and state object into every method that wanted to draw or update anything. It felt like it required a singleton or some other global object. Basically, that shared global state felt like a really great way to introduce bugs.
And for battery-powered applications, recalculating every single thing every time feels like a battery-hog. But that's a problem with immediate mode in general, not imGUI itself. Maybe there's ways to reduce framerate or introductle conditional rendering, but that would go counter to immediate mode.
The first problem is a you problem though. There's nothing stopping you from dividing your global god-class into smaller ones. For example, you can have one state struct per windows. So windows wouldn't have access to the state of other windows.
The second problem is also the reason I don't often use imgui. Imgui is great for introducing UI to applications that would re-render every frame, like a video game. But for every other application, it feels like a waste. If I wanted to waste resources I would write it in python or JavaScript.