5 ms·

That last paragraph absolutely nails it. Trying to re-implement the operating system as the browser is mutually exclusive with it being a good browser or standa

That last paragraph absolutely nails it. Trying to re-implement the operating system as the browser is mutually exclusive with it being a good browser or standard for webpages. > 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”. To put it simply, websites and webapps are not the same thing, nor should they be. Yet the conflation of a platform for hypertext and a platform for applications has confused thinking, and led developers with prodigious aptitude for JavaScript to mistakenly see mere websites of text as a like nail to their applications hammer.

andylynch 7y ago
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.
- lucasverra 7y ago
  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
nitwit005 7y ago
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.
- skunkpocalypse 7y ago
  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.
  - zozbot234 7y ago
    Um, they did exactly that via HTML canvas. Replacing the main use cases for both Flash and Java applets.
- zmix 7y ago
  > 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.
nathell 7y ago
Related: http://blog.danieljanus.pl/2019/10/07/web-of-documents/ http://blog.danieljanus.pl/2019/10/07/web-of-documents/
- cousin_it 7y ago
  Need more specifics how to keep the "web of documents" from being outcompeted by the modern web again.
  - eitland 7y ago
    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.")
shakna 7y ago
> 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.
- saagarjha 7y ago
  Can you just print the PDF and get something reasonable out of it?
  - shakna 7y ago
    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.
al2o3cr 7y ago
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)_Processing https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Pr...

andylynch 7y ago

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.

lucasverra 7y ago
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

nitwit005 7y ago

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.

skunkpocalypse 7y ago
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.
- zozbot234 7y ago
  Um, they did exactly that via HTML canvas. Replacing the main use cases for both Flash and Java applets.
zmix 7y ago
> 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.

nathell 7y ago

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

cousin_it 7y ago
Need more specifics how to keep the "web of documents" from being outcompeted by the modern web again.
- eitland 7y ago
  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.")

shakna 7y ago

> 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.

saagarjha 7y ago
Can you just print the PDF and get something reasonable out of it?
- shakna 7y ago
  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.

al2o3cr 7y ago

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)_Processing https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Pr...