At least JS had the excuse of being designed and implemented by a single developer in three weeks. X Windows was part of Project Athena, a $50 million project from MIT, DEC, and IBM with a five-year schedule.
Here's a nice little article from 1989 telling just how great it was for the time:
The layers of abstraction are there because X is such a godawful piece of shit. Sure, your application will be fast if you only use XCB or Xlib (and XCB is just a modern replacement for Xlib, made because of how deeply flawed Xlib is, and it can’t even fully replace Xlib). But few people are willing to put in the blood, sweat, and code to write something that is pure X.
So if X worked great for what it was aiming to do, it was aiming to do the wrong thing.
Sure, if you're using it to connect to a box in Canada over a satellite connection in Johannesburg during 1995 with countless abstractions, you're going to have a horrible time. Use the right tool for the job.
The X-Windows Disaster
https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
>X: The First Fully Modular Software Disaster
https://news.ycombinator.com/item?id=17056516
John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;)
https://web.archive.org/web/20171008204348/https://minnie.tu...
X and NeWS History
https://news.ycombinator.com/item?id=15325226
Jon Steinhart wrote:
>XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two.
>The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there.
>The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added.
>The bit encodings should be part of a separate language binding, not part of the functional description.
>Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls.
Recommendation: People who like saying "X-Windows" also enjoy saying "Project Anathema".
Those others I think get it wrong with their "whole desktop" sharing. The experience of having X clients streamed as they are launched and the local WM gets to manage decorations - I like that model a lot more, for say the scenario where I ssh into a machine and launch a GUI program.
RDP is much faster than X. It had the benefit of being designed later I guess.
VNC usually feels laggier than X to me somehow. As if there is a cursor sync issue.
These are just my observations as a user.