> Yes, X11 tunneling exists, but the experience has always been abysmal for me for anything not hosted on a machine that sits on the same LAN as the client.

Good performance with X11 is possible if you avail yourself of the X11 primitives.

This is where Lilith Nyan-Nyan (she/they/it, mastodon lilith@catbox.gay), core Wayland developer, pipes up and says "OwO nobody develops like that anymore :3 everything is rendered client-side on the GPU, and then zero-copy transferred to the compositor for display... really that's the only function the X server has anymore, and wayland is a better architecture for this uwu"

But what Mx. Nyan-Nyan, and a lot of developers of her/their/its generation don't realize, is that in the past Unix developers strove to write programs with UIs that were usable across network lines, and availed themselves of the X11 protocol's graphical primitives to do just this. Emacs, for example—particularly emacs-lucid—is incredibly snappy even when an Emacs in the cloud is rendering to your local X server. If you write things the modern way, which developers largely do assuming a 100% local display, then in the remote case the X client will have no choice but to ship uncompressed pixmaps of each frame over the network to the X server, which greatly slows things down.

What we are seeing is that "the modern way" is beginning to be applied to terminal apps as well! Claude Code, for instance, has a React-based layout and rendering flow (does it use Ink?), and (until recently?) redrew the entire chat history on each update, leading to the slowdown and flicker problems it had. It would be absolutely unusable over, say, the kind of 9600-baud link that was commonplace back when people used actual terminals to connect to large systems (and ran full-screen apps in those terminals!). It's only a bloat cycle or two more before these programs start to struggle over a typical ssh link, too!

We've utterly lost the plot when it comes to software.