I used to run everything over 100Mbps ethernet. It worked just fine. Two biggest issues: Ssh without tuning settings, and modern X applications increasingly doing client-side rendering into bitmaps and so being far more bandwidth hungry and not tested over the network. If it's the latter, VNC or XPRA are much better suited if what the app ends up doing is streaming bitmaps anyway, as they're actually optimised for that.

It’s usually SSH that’s the bottleneck though. If you just expose your local X11 TCP server port and connect to it from the server (X11 client) by setting the DISPLAY env properly, it will be much more responsive. Often indistinguishable from local apps. Secure the port with Wireguard, if you want to be a bit more responsible and still have good performance. Checked with Firefox, which works like a charm this way, but is unusable over SSH.

> If you just expose your local X11 TCP server port and connect to it from the server (X11 client) by setting the DISPLAY env properly, it will be much more responsive.

That's fine on a LAN with low or sub ms latency. If you need to connect to a server on the other side of the country, you'll want a less chatty protocol, e.g. X2GO (which gives additional benefits, e.g. of restartable sessions).

> can you imagine a browser this way?

It in fact works perfectly fine.

The catch is latency. In my case both hosts are on the same colo.

I remember, 20+ years ago running quake3 over remote X to my roommate machine and I was surprised that glx actually worked over the network with no issues.

It depends on how the client was written. If you build around asynchronous operations, you can get good throughput, and if you always stop and wait for a reply, you'll get bad throughput. If you buffer your output and don't actually send it for a while, that can also make the experience poor. Xlib pushed you in both those directions, but you can make terrible clients with any library.

My personal experience with Oracle products has always involved terrible UX, so I'm not surprised they built a terrible X client.

I've run browsers over X, sometimes actually remotely, and it's OK, but not great. I wouldn't recommend it for video, audio is out of scope, and start up can be very slow sometimes. It's something that used to work better, IMHO. Sometimes you need to try a couple browsers and see which one works better. As a sibling notes, it all feels untested, and I'm sure if developers were testing, they'd fix some of the things that are easier to fix.

X over SSH works really well for me as long as I enable SSH compression. At least for my usage, I can't tell it apart from a native window but then again I'm not running sophisticated programs which update frequently.

Until fairly recently I used to use Quartus on a headless box with ssh -X

It worked really well up until a certain version (18, I think) - after which something changed in the UI toolkit and it was suddenly much more laggy. I'm guessing the UI toolkit's newer incarnation required a lot more round trips.

x2go is a bit smarter than pure x-forwardning and also allows you to resume a session at a different time (or on a different machine) similar to something like tmux. Much much better performance and does pretty well even on cellular.

A bit rough around the edges but brilliant for some usecases.

The use case was a whole bunch of cheap display server machines in a computer lab at a university with a very powerful machine running the computation-expensive client programs. You didn't need SSH for that and the only real problem was contention on the token ring (ah, the old days...)