Oh, come on. I'm all into retrocomputing, and think there's a place for riced-out Apple ][ emulators, but X-Windows was terrible in comparison to other window systems 20 years ago, and it still is.

microM8 Apple II Emulator: https://paleotronic.com/software/microm8/

The X-Windows Disaster: https://medium.com/@donhopkins/the-x-windows-disaster-128d39...

X window managers are as complex and dug into a pit of pointless complexity as the Space Shuttle: https://news.ycombinator.com/item?id=5861229

The fundamental problem with X is that it ignored the brilliant idea behind "AJAX", that you should send not a fixed protocol but executable code (like PostScript or JavaScript) to the server to be interpreted in a sandbox.

Plus the fact that it has a terrible antique-device-dependent imaging model that views every device like a MicroVAX framebuffer on acid.

At the time of the transition from X10 to X11, all these problems and solutions were well and widely known and debated, but X11 chose to ignore those ideas.

But other competing window systems like NeWS didn't have those problems, and used much better solutions, which were only later re-discovered, re-implemented and re-branded in yet another layer with the advent of web servers, browsers, HTML, JavaScript, canvas, and "AJAX".

https://news.ycombinator.com/item?id=13783967

NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

- used PostScript code instead of JavaScript for programming.

- used PostScript graphics instead of DHTML and CSS for rendering.

- used PostScript data instead of XML and JSON for data representation.

But now that there's another Web Browser layer slapped on top of X-Windows (and the terms "client" and "server" switched places), you're stuck with two competing mutually incompatible window managers nested inside of each other, one for the outside frames around apps, and one for the inside tabs around web pages, that don't cooperate with each other, and operate uncannily differently.

So none of your desktop apps benefit from any of the features of the web browser (unless they include their own web browser like Electron).

And you can't write lightweight apps in a couple pages of script like "Big Brother Eyes" that run in the shared window server, without requiring their own separate external app with a huge runtime like Electron.

https://www.donhopkins.com/home/archive/news-tape/fun/eye/ey...

Nor can you easily integrate desktop applications and widgets and web pages together with scripts, the way HyperCard, OpenDoc, CyberDog and HyperLook enabled.

https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...

Here's how the web browser and window manager should work together seamlessly:

https://news.ycombinator.com/item?id=18837730

And this is why a modern window manager should be written in JavaScript, leverage HTML, Canvas and WebGL, and support Accessibility APIs, as well as screen scraping, pattern recognition, screen casting, virtual desktops, overlays, drawing and image composition, input event synthesis, journaling, macros, runtime user customization and scripting, programming by demonstration, tabbed windows, pie menus, etc:

https://news.ycombinator.com/item?id=18797587

Think of it like augmented reality for virtualizing desktop user interfaces and web pages.