People have been proposing building "X12" and "Y-Windows" since the day after X11 came out 39 years ago.
Not gonna do it. Wouldn't be prudent at this juncture.
https://www.youtube.com/watch?v=4QHHGHve_N0
X-Windows Disaster:
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
Myth: X Demonstrates the Power of Client/Server Computing
At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They’ve become unwitting pawns in the hardware manufacturers’ conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!
The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slices the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.
The fundamental problem with X’s notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program’s state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.
The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.
As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client can download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.
Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun’s TNT Toolkit). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that is both consistent across applications and customizable. With NeWS, the window manager itself was implemented inside the server, eliminating network overhead for window manipulation operations — and along with it the race conditions, context switching overhead, and interaction problems that plague X toolkits and window manager.
Ultimately, NeWS was not economically or politically viable because it solved the very problems that X was designed to create.
Today it'd perhaps be even easier to do. Both X and Wayland protocols are extensible and so adding a way of uploading extensions is simple enough. You'd run into "political" roadblocks, perhaps if you try to standardise it, but someone could just do it. A web assembly profile that provides a way of exchanging messages to allow you to build classes could easily be made to optionally either run over the network (maybe mostly for dev/debugging) or internally within an Xserver or Wayland compositor.
I think the biggest challenge today is that people would be more likely to just use a web browser for most of those things that would benefit most from working over the network, and latency for locally run software isn't a big deal (my wm, which I've mentioned elsewhere, is written in Ruby and spews about a dozen lines of debug output to the terminal for every mouse move during resize and drag at the moment, and yet it's smooth enough).
It'd be fun to try, though.
[EDIT: One simple/fun idea as a starting point for something like that would be to simply add an extension that injects such a wasm binary as a "filter" between inbound requests and outbound events/replies]