[bsder]

The problem right now the separation of concerns for GUIs is a complete shitshow on ALL platforms.

Even such "simple" tasks as how to composite a window, a video in that window, and a floating menu over that window are not very well specified in any OS (try resizing that window and watch the fun). Or, for example, your floating menu--should the parent window resize itself and paint with transparent pixels in the extra area or should that menu be a separate "window"? And, what does being a "window" even mean?

Add into that the fact that we really should be making multithreaded GUI systems at this point and it's very clear that GUIs are stuck in a local minimum that's really hard to get out of because GUI systems require so many lines of code.

[meindnoch]

Window resizing works perfectly fine on macOS if you use the native AppKit framework. It’s only when you try to embed a whole different world (Qt, GTK, Flutter, Electron) in your window via an opaque OpenGL/Metal surface that things break/lag/distort on resizing the window, which again is another reason to stay away from these cross-platform GUI shims.

I don’t really see the reason for multithreaded UIs either. A single UI thread works perfectly fine if you move your business logic off to a separate thread. Most people are just too lazy to do that, and start developing their app with the business logic running synchronously on the UI thread; which works for a while, but eventually reaches a point where it starts blocking the UI event loop; then they try bandaging it by moving certain pieces to a background thread and they shoot themselves in the foot with thread-safety issues. The way to solve this is not by making the UI framework multi-threaded… Simply be disciplined with UI ↔ business logic separation from the get go and all these problems go away. Yes, I know it’s so tempting to call the database directly from the button click handler - but don’t do it.