Not OP, but modularity. An X11 WM is just a WM. You can choose compositor, bar, shortcut daemon, etc. With Wayland, a single implementation holds most of that, and more. If you need a specific feature from your display server, you are stuck on WMs that support it. This has forced me to use KDE for Wayland on my main workstation, and although it works well, it’s not my prefered WM/workflow.
Alongside that, no clones of several X11 WMs exist. bspwm for example. Riverwm exists, but has major limitations, and the workflow isn’t the same.
In practice wayland is way more composable that one would, at first glance, expect, and even accidentally so, because DEs are made up of different components often sharing common interfaces, so the cosmic task bar will run under the sway compositor and suchlike. Not just “run” as in “not crash” but “actually display tasks based on information from the compositor”. I expect further standardisation there once the ecosystem matures a bit more. Just because you can include a task bar directly in the compositor process doesn’t mean you have to, and the same goes for window rules, window decorators, whatnot.
The status bar example holds for xorg as well… What wm doesn’t ship its own bar nowadays? The only one I can think of is bspwm. But nothing stops you from disabling the native bar and using your own
With a library like Wlroots you almost get that, it’s just in-process rather than out of process. The real problem there is doing some fancier things requires nonstandard Wayland extensions with low support across the ecosystem.
Not OP, but modularity. An X11 WM is just a WM. You can choose compositor, bar, shortcut daemon, etc. With Wayland, a single implementation holds most of that, and more. If you need a specific feature from your display server, you are stuck on WMs that support it. This has forced me to use KDE for Wayland on my main workstation, and although it works well, it’s not my prefered WM/workflow.
Alongside that, no clones of several X11 WMs exist. bspwm for example. Riverwm exists, but has major limitations, and the workflow isn’t the same.
In practice wayland is way more composable that one would, at first glance, expect, and even accidentally so, because DEs are made up of different components often sharing common interfaces, so the cosmic task bar will run under the sway compositor and suchlike. Not just “run” as in “not crash” but “actually display tasks based on information from the compositor”. I expect further standardisation there once the ecosystem matures a bit more. Just because you can include a task bar directly in the compositor process doesn’t mean you have to, and the same goes for window rules, window decorators, whatnot.
The status bar example holds for xorg as well… What wm doesn’t ship its own bar nowadays? The only one I can think of is bspwm. But nothing stops you from disabling the native bar and using your own
With a library like Wlroots you almost get that, it’s just in-process rather than out of process. The real problem there is doing some fancier things requires nonstandard Wayland extensions with low support across the ecosystem.