https://en.wikipedia.org/wiki/NeWS

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.

FTFY:

Web Browsers were a mistake, as are all toolkit-in-browser JavaScript libraries

April 1, 2020

One of the great white hopes of the part of the Web world that never liked Gopher was Netscape's web browser. Never mind all of its practical flaws, all sorts of people held web browsers up as the better way and the bright future that could have been if only things had been different (by which they mean if people had made the 'right' choice instead of settling for Gopher). One of the reasons people often give for liking web browsers is that it put much of the JavaScript libraries into the web browser instead of forcing every server to implement it separately.

Unfortunately for all of these people, history has fairly conclusively shown that web browser was a mistake. Specifically the core design of putting as much intelligence as possible into the web browser instead of the web server has turned out to be a terrible idea. There are at least two big reasons for this.

The first is parallelization. In the increasingly multi-core world you desperately want as much concurrent processing as possible and it's much easier to run several web servers in parallel than it is to parallelize a single web browser. Even if you do get equal parallelization, separate web servers are inherently more resilient because the operating system intrinsically imposes a strong separation of address space and so on, something that's very hard to get in server where everything is jumbled together.

(I believe that this is one reason that modern HTML CSS rendering has been moved from the web browser to the web server. WebFont rendering is increasingly complex and CPU-consuming, so it's better to stick web servers with that burden than dump all of it on the web browser. After all, all Web Servers should have multiple GPUs for drawing and accelerating graphics and numeric computing for all their clients, but there is no rational reason anyone would ever want to program the GPU in the web browser, or push that processing off from the honking big accelerated server farms that you're renting from Amazon by the minute, to the millions of web browsers run by your users whose electricity you don't need to pay for. Plus, users enjoy waiting for their graphics to download over the internet in response to every mouse click and movement they make. It gives them time to think and reflect.)

The second is that if you put the toolkit in the web browser you make evolving the toolkit and its API much more complicated and problematic. The drawback of having everyone use the web browser toolkit is that everyone has to use the same web browser toolkit. Well, not completely. You can introduce a mechanism to have multiple toolkit versions and APIs all in the same web browser and allow web servers to select which one they want or need and so on and so forth. The mess of a situation with the current web browser and its JavaScript libraries make a very educational example of what happens if you go down this path; not very much of it is good.

(Some JavaScript libraries are in practice mandatory but still must be probed for and negotiated by the web servers, while others are basically historical relics but they still can't be dropped because some web server somewhere may ask for them.)

JavaScript libraries in the web browser push the burden of dealing with the evolution of the library into the web server. It is the CDN and web browser cache that carries around old or new versions of the library, with various different APIs, and you naturally have old library versions (and even old toolkits) go away entirely when they are no longer used by any active web servers (or even any installed web servers, when things get far enough).

(I'm ignoring potential security issues for complex reasons, but they may be a good third reason to be unhappy with browser-side libraries.)