my personal theory is that it's a cultural problem. same reason web apps are such memory hogs. front end web devs, as a culture, do not care about performance, but they really care about developer experience. the opposite is true of systems developers

You know what's funny? I've concluded that godotengine is probably the best option for people who just want to make a graphical program without having to spend more time learning the GUI part than the actual logic, and as a bonus you can use it to build for multiple platforms as well.

As a developer who has mostly worked with web, but also dabbled in some native app work: It's not that the web UI frameworks are so much nicer. The native libraries I've used, at least, are actually much nicer to work with. I've worked with Delphi, Java Swing, various Windows frameworks, etc. React and friends are a chaotic mess in comparison and HTML was not designed for app development. You want a button? Here's a div, go ahead and style it. Thanks, let me add 500 npm packages to my project.

No, the main reason I prefer to develop web apps is because they're effortlessly cross-platform and automatically updated and distributed. No maintaining multiple versions. Updates are basically instant and happen across your user base. No code signing or paying to compile code on a Mac. No asking for install permissions on stupidly locked down enterprise workstations. Just deploy and go.

I can count on one hand the number of times I've needed to create a native app due to some restriction like local file access or device access. Most of the time you're just entering values into a database, so that can just be a website. PWAs are a pain to develop but they are much easier to deal with once they're in the wild.

YMMV of course.

Graphics in computer operating systems are, as a rule of thumb, a nightmare to program. My best experience with that was Delphi/Lazarus, which is a simple drag and drop to build the program window, though being Pascal, it's verbose as fuck.

SDL provides you a framebuffer with 640x480 pixels and 24-bit color, with a delicious pixel-perfect 8x12 monospace font, on every OS and every device, and this is everything you will ever need. Titlebar? Close button? Your app is perfect, it needs no close button. It will be running 24/7 in a fullscreen mode, and the user will be happy! Other apps? Pah! Let them run on a second, smaller monitor!

What didn't you like about imGUI? Just curious

I'm pretty sure that most developers that use web UIs do so for portability.

There are non-Web-based cross-platform GUI toolkits, like Java's Swing.

As to why cross-platform desktop toolkits haven't really caught on...I'd say that it's because there are things that you can't really abstract all that well. There are ways that a well-written MacOS app should function, ways that a well-written Windows app should function, ways that a well-written GTK app should function, and so forth.

EDIT:

I dread writing any native GUI that I got desperate enough to try writing a TUI but that’s unbelievably worse!

Honestly, the same is true of TUIs, too. Like, MS-DOS/Windows TUI conventions and Unix TUI conventions aren't really the same. Like, in a typical Unix TUI program, I expect "q" probably quits. At text prompts, I expect that I probably have readline support and likely the vi/emacs key support there. It probably defaults to white-on-black. In an MS-DOS TUI program, Escape probably exits, and I'm probably using white-on-blue. I'm probably using Code Page 437 box-drawing characters.

EDIT2: ncdu on Unix:

WordPerfect for DOS:

I wish the desktop react native renderers took off. I definitely do prefer the react style of colocating everything + reactive state, and being able to swap different renderers for actually native feel doesn't really seem like a goal for any maintained projects anymore. on that note, you could write your tui in react with ink or opentui if you want to go that route

dioxus does have a native renderer (in the not webview sense, it still draws it's own components, but most of the options do). if you're looking at rust already, iced seems pretty close to react style, and has a decent number of things written in it already. relm4 is a different style rust framework for gtk that you might like as well.

again not native appearance, but avalonia funcui can be pretty close to the react feel too if you're open to f#

I usually reach for JavaFX because I know it well (or Fyne if the app is very simple), but these days I'd start with Avalonia first. But that's for a very generous definition of "native" basically meaning "not web"

I feel you. I don't particularly like any frontend work, but desktop frameworks can go to hell. No wonder why electron apps took off in the last decade, despite all its problems.

I share your frustration, so I am also interested in seeing some responses here.

The closest I have got is trying out flutter.

I had my own library for UI that tried to have a element model, but it was bloated and didn't scale well. Now im drawing everything via vulkan compute shaders and its fast and looks great.

I think the philosophy needs to switch from elements back to pixels, atleast that is what worked for me.

i dare to say its as easy as webdev

snippet from my game:

DrawMenuButton(buf, btnExit, "Exit to title", exitHover, exitHover && window.mouseLeftHeld, false, font, topFontPx, exitCol);
DrawMenuButton(buf, btnSave, "Save changes", saveHover, saveHover && window.mouseLeftHeld, false, font, topFontPx, saveCol);
PushPanel(buf, titleRect, panelBgColor, 6.0f * s);
PushBorder(buf, titleRect, borderColor, 6.0f * s, 1.5f * s);
DrawText(buf, "OPTIONS", titleRect.x + titleRect.w * 0.5f, titleRect.y + titleRect.h * 0.5f + topFontPx * 0.32f, font, topFontPx, textUnfocusedColor, TextAlign::Center);

this is in the draw function, and along with the other code produces this menu:

Mac UI development was the nicest last i tried. Even that has a slow dev loop compared to Web.

I did ok with GTK plus a nicely fixtured launcher. Cut the cycle time down to dozens of seconds. But still... Meh.