For starters, I do agree that the X11 model is fundamentally broken on the modern computing platform.
However, sadly, I'm beginning to think that Wayland has made some fundamental architectural choices that are not fixable and are also broken on the modern computing platform.
The biggest problem is that Wayland takes the "compositor" route and turns it up to 11. Unfortunately, nobody does multi-window compositor to application integration well--Apple is the best, but by no means good. Even Windows drops to software rendering on resizes and actually integrating with the compositor needs a whole host of new Windows calls that nobody ever uses.
The whole "You need link a library and draw your own decorations" is, put simply, ludicrous. You don't draw them on Windows, macOS, iOS, or Android. Yes, that means you can't change your window manager, so be it. Look at the contortions and dependency chain that the winit package on Rust has to keep in order to communicate with Wayland.
The fact that I need 50,000 lines of code called wlroots is nothing short of a travesty. Even if I use a language which is much better for security, that 50,000 lines of code is a shambling security disaster that will bite me in the ass.
And that's before we start talking about some of the architectural design decisions made in wlroots. The design decisions are so anathema to something like Rust that people have given up and been forced back to C:
http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...
(Side note: this is one of my perennial hot buttons, and Wayland isn't the only guilty party. "Everybody Wants To Rule the Event Loop" by "Tears for Engineers" has become ingrained in programmers, and it's a BAD thing. Event loops don't compose and you wind up with callback hell trying to put two of them together. Polling does compose (ie. “readiness” rather than the “completion”), but it's a lot more work on both sides of the programming equation--the application and the library--to get it right.)
There's also some strangeness about hiDPI and scaling in Wayland that just seems to be wrong. But maybe my brain's just too small, and I don't have enough context--it wouldn't be the first time.
Of course, it's easy to armchair quarterback and difficult to construct. This is hard, grungy work and the Wayland guys are putting in the elbow grease. Until I'm willing to pick up an editor, my opinions aren't worth much.
Overall, though, I see myself staying on X11 until I simply can't anymore.
If the GNOME project were a corporation with non-technical management and a PR department, some higher-up would have ordered the devs to just add server-side decorations to Mutter already, regardless of how it complicates the code or compromises their design vision, to fix the bad PR. Of course, at least one such corporation, Red Hat, is already funding a lot of the development on GNOME. Maybe the Red Hat higher-ups are giving their desktop developers too much autonomy.
I've read the thread. I think the GNOME developers have logical reasons for their position. But it still makes them look bad, particularly since every other Wayland compositor supports SSD.
However, sadly, I'm beginning to think that Wayland has made some fundamental architectural choices that are not fixable and are also broken on the modern computing platform.
The biggest problem is that Wayland takes the "compositor" route and turns it up to 11. Unfortunately, nobody does multi-window compositor to application integration well--Apple is the best, but by no means good. Even Windows drops to software rendering on resizes and actually integrating with the compositor needs a whole host of new Windows calls that nobody ever uses.
The whole "You need link a library and draw your own decorations" is, put simply, ludicrous. You don't draw them on Windows, macOS, iOS, or Android. Yes, that means you can't change your window manager, so be it. Look at the contortions and dependency chain that the winit package on Rust has to keep in order to communicate with Wayland.
The fact that I need 50,000 lines of code called wlroots is nothing short of a travesty. Even if I use a language which is much better for security, that 50,000 lines of code is a shambling security disaster that will bite me in the ass.
And that's before we start talking about some of the architectural design decisions made in wlroots. The design decisions are so anathema to something like Rust that people have given up and been forced back to C: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...
(Side note: this is one of my perennial hot buttons, and Wayland isn't the only guilty party. "Everybody Wants To Rule the Event Loop" by "Tears for Engineers" has become ingrained in programmers, and it's a BAD thing. Event loops don't compose and you wind up with callback hell trying to put two of them together. Polling does compose (ie. “readiness” rather than the “completion”), but it's a lot more work on both sides of the programming equation--the application and the library--to get it right.)
There's also some strangeness about hiDPI and scaling in Wayland that just seems to be wrong. But maybe my brain's just too small, and I don't have enough context--it wouldn't be the first time.
Of course, it's easy to armchair quarterback and difficult to construct. This is hard, grungy work and the Wayland guys are putting in the elbow grease. Until I'm willing to pick up an editor, my opinions aren't worth much.
Overall, though, I see myself staying on X11 until I simply can't anymore.