It's worth remembering that, because there were no Javascript or HTML APIs for many things people felt their pages needed, a huge portion of the web was loading up flash, silverlight, or java applets.

Now, maybe they never should have allowed Flash and friends, but the genie was well out of the bottle. You could either have HTML and JS based functionality, or the plugins.

> It's worth remembering that, because there were no Javascript or HTML APIs for many things people felt their pages needed

The OA states in his article, that he is fine with many of the new APIs. It's not HTML5 vs. XHTML, it's 'applified web' vs. 'document web'. And I agree.

WHATWG should have published a standard to replace Flash -- all the same goals as Flash, but a clean-slate standards-driven design.

Instead they infected the HTML standard with everything Flash was being used for.

Um, they did exactly that via HTML canvas. Replacing the main use cases for both Flash and Java applets.

I’ve seen PDFs like these- it’s one way for publishers of (costly!) industry research reports to allow limited downloads and still track who’s reading them (the kind where a copy is listed at 5000 USD for non subscribers). And they are horrible to use, but do serve a purpose.

what is interesting to notice is that is the research industry that gave birth to the web that this article rightfully wants to differentiate from document/application web

> If anyone constructed a PDF, which was itself blank but, via embedded JavaScript, loaded parts of itself from a remote server, people would rightly balk and wonder what on earth the creator of this PDF was thinking — yet this is precisely the design of many “websites”.

Unfortunately, this is also the case for many PDFs amongst some of the more niche use-cases. Like NDA-bound many-thousand paged specifications. The PDF standard lets you do it, so some do. Not all readers actually support embedded JS, but most do in some limited capacity.

Can you just print the PDF and get something reasonable out of it?

Yes and no. Whatever prints the PDF has to be able to run the JS payload.

In the case of a physical printer, it's usually set up so there's [redacted] instead of blankness (that the JS replaces), so you get redacted images and paragraphs.

In the case of software printing to a static PDF which you can then print, the JS payload is generally set up to embed a series of rather obvious markers so that if the static copy is ever publicly revealed, they can go after you (DRM is easy when you only have a dozen customers in the entire world), but most PDF software that supports JS also supports JS disabling printing features so that little disincentive is unnecessary.

Related: http://blog.danieljanus.pl/2019/10/07/web-of-documents/

Need more specifics how to keep the "web of documents" from being outcompeted by the modern web again.

If it is 10 times faster on average, safer and generally less annoying it might have a natural advantage.

We could get some of the advantages if we just started shunning JS and telling people ("Proudly Javascript-free and free of third party trackers! You might have noticed that this site loaded quicker than other sites you have seen lately. Mostly this is because we don't bug your machine with insert-carefully-crafted-explanation-here.")

I don't follow how an XML advocate can complain about other things loading parts of themselves from remote servers:

https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Pr...