That's just wrong. X11 was designed from the ground up to be used on the network. It just happens that nowadays requirements are different from when it was originally designed.
Running X11 on the network was quite a thing in Unis all over the world, where you could have dedicated dozens of X11 graphic terminal servers (tektronix used to make good ones) connected (100Mbits) to a single mainframe, and everyone running an Xemacs session without slowdown.
Wayland design is all about framebuffers, which clearly shows how focus has shifted. X11 was not designed for pixmap heavy, shader heavy scenarios.
Serving X applications (eg: Chromium) from the Raspberry Pi I'm targeting to the Mac I'm developing on is an exercise in futility, even if it does make 'download this to the target' easier. It's a lot faster to run Safari on the Mac and scp the download to the Pi, just because of interface latency issues.
Granted though, it does nothing for apps using Electron. However, try e.g. the Dolphin file browser on a 4K display over the network, and you'll find it is clearly faster than should be possible.
Probably I should've made it clearer, but imo the bigger problem is that tweaking Waypipe to replace old uses of ssh -Y shouldn't be needed; it should be possible for it to determine what possible options can be used and switch things around to deal with CPU or network bottlenecks most effectively. Easier said than done. There's also still some bugs under Waypipe; it's an understandably challenging problem.
Remote X over fast low latency networks is fine, a near local experience-- even running things like firefox or gimp. (And for classic apps it's indistinguishable from local). The wayland world alternatives like using RDP are painful to the point of usability even over a 10gigbit network, peg the cpu... and are really only good for rescuing something that's stuck or providing a bit of tech support.
Yes, over a high latency network remote X is sucky but seldom much worse than RDP.
That's very wrong, the whole point was to run over the network.
It worked exceedingly well even in the earliest 90s (modulo bandwidth expectations of the time) and continues to work wonderfully 30+ years later.
Modern apps draw all their UI client-side onto a surface which is then sent to X for display. IF ONLY we had a windowing system that was based around simply compositing together the various surfaces that the apps draw into a complete image of the desktop. Since this is a step away from the complexity of X, we could give it a name starting with W...
Don't know what to tell you, your experience is different.
Many of my computers are on a rack and I run everything on them over X displaying to my desktop. Works just fine.
Excuse me, but BS. At least for anything of actual relevance.
X11 networking works okay for stuff that looks like a classic X11 app. That's things like xcalc. Any modern text editor, web browser, or anything else is going to be dog slow.
X11 has a bad networking protocol that's way too latency sensitive, and as a result is nigh unusuable without something like NX, which puts a local cache in front to get rid of that latency.
No, I'd say X11 wasn't designed to be run on the network, in that no particular care seems to have been taken to deal with latency and bandwidth issues. It's more of a feature that could be had for free, because if you can use an UNIX socket, you can also use a TCP one with minimal work, so might as well allow it.