Lower level, but there's also a Wayland compositor being written for the web. Many caveats apply, different effort, but also interesting, https://github.com/udevbe/greenfield https://news.ycombinator.com/item?id=29239781
All in all, the basics of Wayland are a pretty tight package. https://wayland-book.com/ goes through the pieces, and it's not a super thick read. The system of passing around surfaces is comprehensible, tight, makes sense, and there is very little fluff or barriers here, imo.
Wayland has a common core, but absolutely I'd grant that the various protocols do indeed make it a much less tightly coupled thing, with different compositors having different sets of protocols they support. So yes, some apps that require advanced capabilities run much better in some compositors than others; the compositor choice matters. Sometimes there are multiple competing protocols for the same feature-sets, but usually/historically, wayland-protocols hammers stuff out reasonably quickly & most of this is a matter of time.
Still, this is often easier than the past, where apps would have to each test for extensions & have various fast/regular/fallback codepaths depending on available extensions; not necessarily a hindrance to the window-manager, but a bundle of complexity for everyone else trying to use X11 adequately. The Wayland common primitives, on the other hand, are fairly universally performant & well chosen.
Returning to complexity for window-manager/compositor, the situation is not unlike X11 itself, where yes, a simple window manager (or compositor) is possible to spin up relatively quickly, but where there is a sea of different standards to implement to do a good job. Window manager hints, extended window manager hints, and a plethora of other standards existed around X11 that were up to the window-manager to tackle, and implementing each of those took a lot of time too, if you wanted good support for all apps. Different Wayland compositors also have different support for different protocols, and those are a bit deeper rooted capabilities, less superficial than many of the X11 hints (which, if ignored, were less likely to impede use), but the idea is the same: real support to really be decent took work in X11, and it takes work in Wayland to implement a good suite of protocols here too.
Where I disagree highly is calling out the hardware here. Wayland is closely tied to kernel fundamentals; any reasonably supported video card will perform adequately under any competent/non-specialist compositor today. (Certainly some compositors could demand higher standards, such as some of the experimental compositors requiring Vulkan, but generally compositors have very similar, very common requirements.)
> I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
I like where we are, where there are various toolkits/libraries for accelerated implementing. Wlroots, which underpins chiefly Sway (the i3 replacement), has given rise to a variety of other compositors, spanning the gamut from quick/fast/experimental to rich/deep/powerful. libwayland still defines some core ideas, if not compositing implementations, to speed development somewhat. Weston is still available as a reference compositor, although yes it's designed (more or less) to be forked & enhanced, not built to be preserved & built (extensibly) on top of. Wlroots & other alternative toolkits fill this need, & provide a diversity of ideas for how we might get going. Projects like Greenfield, the HTML5 compositor (https://github.com/udevbe/greenfield) demonstrate the diversity we get from not having a single common core technology, are possible because of this belief in protocol & standards over implementations, eased though implementations might be from promoting something like Weston to the one-and-only implementation.
> The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there.
We can't look at a anti-plays-well-with-others entity like Nvidia to assess what is/isn't a good idea. Nvidia spent nearly a decade stomping their feet & demanding only their way was ok. The fact that Embedded OpenGL itself, what the rock their obstinacy was built around (EGLStreams), is quite heavily on the way out further should stress how foolish & self-centered this vendor has been. This discompatibility indicates nothing, is no sign, except an indicator of what kind of a company Nvidia is/was (one that obstructed any implementations of well known & common kernel constructs).
But even with Greenfield, getting things rendering & drawing is going to be a big challenge. Total Annihilation probably runs an old directx for graphics. We'd need some way to support that.
There's projects like DXVK[2] and VKD3D[3] to run directx 9/10/11 and 12 atop Vulkan. These are probably too new for a classic like Total Annihation, but would support many games. Yet, the web doesn't have Vulkan- it has a similar but different/less capable WebGPU. Perhaps someone could craft/hack-out another adapter layer, a Vulkan-atop-WebGPU translator, that could be stacked up. Or we could build WebGPU backends for these adapters. This is a pretty non-trivial effort. It's notable that projects like wgpu exist to provide a cross platform support for WebGPU, so if one were to build a DirectX-on-WebGPU translator, wgpu would let that game run on basically any platform: it'd be way cool. But again, that sounds like hella work.
There's a ton of other technical problems. Huge challenge #2 is that most games are precompiled for x86. Ideally we'd need to recompile them for webassembly, but it's unlikely many games would ever get ported. They could run at radically reduced speed via some machine-translation and games like TA might even work ok that way, given how much faster even a cellphone is than the pentium166 i rocked TA out on.
Challenge #3 is platform. These games rely on an native platform support for files, sockets, and dozens of other event loop & other concepts. Given time & effort, doubtless many of these could be platform libraries could be re-implemented. Projects like UMass's Browsix[4] purported to create similar platform libraries web-natively, creating a Linux-y/POSIX-y environment in the browser. This could perhaps be mated to something like Emscripten to expand the platform offerings significantly. Emscripten itself has adjacent projects for some platform support. Oh, wow, TIL it has OpenGL->WebGL conversion layers: some games could concievably be recompiled with emscripten without too too much fuss & work. But this would not be a Linux desktop, it would be just the game, in a canvas. There are projects such as QuakeJS[5] that appear to do just this!
The web itself is evolving many similar-ish capabilities for this #3. WebTransport is a better WebSocket that comes closer to being a viable network layer, and one day may perhaps, if we're all really really lucky, become a transport for WebRTC as well (fingers crossed). There are various File System API and File System Access API proposals going around for talking to files, which are only kind of semi needed, as a virtual filesystem is probably fine.
[1] https://github.com/udevbe/greenfield https://news.ycombinator.com/item?id=29239781 (71 points, 3 months ago, 26 comments)
[2] https://github.com/doitsujin/dxvk https://news.ycombinator.com/item?id=16199332 (216 points, 4 years ago, 51 comments)
[3] https://wiki.winehq.org/Vkd3d
[4] https://browsix.org/ https://github.com/plasma-umass/browsix many popular discussions, 5~6 years ago: https://hn.algolia.com/?q=browsix
[5] http://www.quakejs.com/ https://news.ycombinator.com/item?id=22797060 (357 points, 2yr ago, 158 comments)
Edit: also this one somebody wrote in HTML5 and typescript https://github.com/udevbe/greenfield
There's a similar thing for Wayland too: https://github.com/udevbe/greenfield
And GTK has yet another way to do this built-in, that uses its own protocol: https://developer.gnome.org/gtk3/stable/gtk-broadway.html
GNOME: https://wiki.gnome.org/Projects/Mutter/RemoteDesktop
KDE: https://userbase.kde.org/Krfb
Sway/wlroots: https://github.com/any1/wayvnc
Generic: https://gitlab.freedesktop.org/mstoeckl/waypipe/
Web-Based: https://github.com/udevbe/greenfield
You can also still use your X11 programs remotely within Wayland, by using XWayland, which is supported by all the major implementations.
Unrelated to Wayland, there is also backend support in GTK3/4 for rendering to a web socket: https://developer.gnome.org/gtk3/stable/gtk-broadway.html
This is kind of a joke answer but the real answer is: This depends on the compositor you're using. So Wayland may not be network transparent, but it's possible to implement equivalent functionality on another layer of the stack.
Somebody has actually done this!
Erik De Rijcke put together Greenfield [0], which is a Wayland compositor that relays surfaces with H.264 or JPEG over WebRTC. It is exactly as cool as it sounds, and it seems like it actually might work pretty well. It's the sort of thing that could be standardized, with a bit of work.