NeWS wasn't "meant" to replace X11 either, which as I mentioned didn't exist when it was designed. And it wasn't meant to replace X10 either, which hardly anyone used at the time.

It might be slightly more historically accurate to say that NeWS was "meant" to replace SunView or Andrew, but that wasn't its goal either.

From the horse's mouth, NeWS was "meant" to be viewed as "speculative research into the right way to build a window system", and its definition and goals didn't depend on its relationship to any version of X, but instead on PostScript as a Turing-complete extensible network protocol.

As the SunDew paper by Gosling and Rosenthal that I referred you to said, these were the goals of NeWS, an none of them had anything to do with replacing X10 or X11:

http://www.chilton-computing.org.uk/inf/literature/books/wm/...

>GOALS

>A clean programmer interface: simple things should be simple to do, and hard things, such as changing the shape of the cursor, should not require taking pliers to the internals of the beast. There should be a smooth slope from what is needed to do easy things, up to what is needed to do hard things. This implies a conceptual organization of coordinated, independent components that can be layered. This also enables being able to improve or replace various parts of the system with minimal impact on the other components or clients.

>Similarly, the program interface probably should be procedural, rather than simply exposing a data structure that the client then interrogates or modifies. This is important for portability, as well as hiding implementation details, thereby making it easier for subsequent changes or enhancements not to render existing code incompatible.

>Retained windows: a clean programmer interface should completely hide window damage from the programmer. His model of a window should be just that it is a surface on which he can write, and that it persists. All overlap issues should be completely hidden from the client. I believe that the amount of extra storage required to maintain the hidden bitmaps on a black and white display is negligible - based on the observation that people generally do not stack windows very deeply. The situation is somewhat different with colour, but there are games to be played. Retained windows is one way of hiding window damage, but we do not want to commit to a particular solution to this problem at this time.

>Flexibility: users need to attach devices, change menu behaviours and generally modify almost all components of the system. For example, the menu package ought to be independent of the particular format or contents of the menu, thereby allowing the user to develop his own idioms without having to reimplement the entire system.

>Part of flexibility is device independence: SUN provides a spectrum of display devices to which clients need consistent and transparent interfaces. This leads directly to portability, which we also need to achieve.

>Users should be able to make various tradeoffs differently than in the standard system, because of either particular hardware or performance requirements. For example, if the system provides retained windows because we believe that the cost in terms of memory usage is worth the performance improvements, a user should be able to make this tradeoff differently, for example if he has less memory.

>This extreme flexibility might appear to be at odds with having a clean, simple, well-abstracted programmer interface, but we do not believe that it is.

>Remote access to windows: in the kind of distributed networked environment that SUN promotes, it is natural to want to be able to access windows on another machine as naturally as the NFS promises to support accessing remote files. We believe that this will fall out of any reasonably designed system.

>Powerful graphical primitives: the primitives that the Macintosh provides should be considered as a lower bound. Curves and colour need to be well integrated. Attention should also be paid to what CGI [30], GKS [28], CORE [24] and PHIGS [6] need. A consequence of an emphasis on power and flexibility is the ability to emulate other window systems, eg it would be very valuable to be able to provide an emulation of the Macintosh toolbox.

>Exploit the hardware: in particular, none of the systems mentioned above deal well with colour. In the future, colour is going to play an even larger part in display design. One can view black and white as a temporary technological stopgap, just as happened with television. Besides, SUN makes some pretty good colour displays, so the window system should exploit them. One implication of this is that the font file format must completely hide the details of the representation of characters, since we might eventually want to support antialiased text, and even illuminated monastic typefaces.

>Perform well: the performance of the current window system should be considered as the minimum acceptable level. Performance in the common cases is especially critical. The new system should perform faster than the current system on such common operations as repainting and scrolling of text.

And years later after that was written, X11/NeWS didn't try to replace X11 with NeWS -- just the opposite: Sun put a huge amount of effort into integrating them together and supporting them both. If Sun meant to replace X11 with NeWS, they would have kept on developing NeWS instead of making X11/NeWS.

NeWS was actually able to complement and improve X11 by implementing superior window management, by wrapping X11 client windows in NeWS window frames, which could be arbitrarily shaped, with tabs, pie menus, etc.

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

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

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

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