4 ms·

If you write real HTML then an archiver only has to retrieve the HTML in order to be able to save the a future-proof representation of the content. (Edit: I'm t

If you write real HTML then an archiver only has to retrieve the HTML in order to be able to save the a future-proof representation of the content. (Edit: I'm talking about text-first documents, not interactive webapps here). But if the content doesn't render at all without javascript, and if the archiver wants to index page or preserve it for posterity, it needs to retrieve all the external assets, and then execute them (because it may asychronously loads further scripts whith are required to load the content). And then wait for it all to execute. This means that archiving services need do to a lot more expensive work. It raises the bar to exclude smaller, more diverse web crawlers and indexers. And regardless of that, it's a big gamble to hope that the third-party CDNs that you rely on will continue to host exactly the same JS libraries ad infinitum.

paxys 6y ago
Lots of different things being mixed up here. To archive a web page you need the source code, all assets, a layout engine and a JavaScript engine. Search engines and archival tools can handle all this very well today. Yes, if a site loads a ton of external content it has the potential to break. But that doesn't apply to just JS but also images and all other static assets. If a JS-heavy site is hosted completely from its own domain there's nothing stopping easy archival of it.
- afandian 6y ago
  We're talking about mostly-text-pages which have no sensible reason to rely on JavaScript to render, not rich webapps. In these cases I consider the text to be a meaningful representation for the purposes of indexing or archive. I don't agree with this: > Search engines and archival tools can handle all this very well today. I think most developers have been in a situation where they had to explain to users that a moon on a stick isn't easy just because Google can do it. It may be commonplace, but it's not easy or cheap. The difference between real HTML and JS execution is orders of magnitude of time, expense, maintenance, and stuff to break. That really can't be underestimated. It's the difference between a 500 millisecond call to curl and a whole headless browser and a 5 second wait. I hope you don't think I'm putting this too strongly, but this raised bar is a force in the monopolisation and de-diversification of the web.
asddubs 6y ago
>and then execute them (because it may asychronously loads further scripts whith are required to load the content). And then wait for it all to execute. not to mention potentially rewrite the executable code to still work on the archive copy, or potentially end up with a copy where all clickable links are broken depending on the specifics (and sometimes also content further down the page if scrolling triggers dynamic loading). And if the site doesn't update the URLs to be unique for each "page", well good luck finding that dynamically loaded content in the archive at all to begin with.

paxys 6y ago

Lots of different things being mixed up here. To archive a web page you need the source code, all assets, a layout engine and a JavaScript engine. Search engines and archival tools can handle all this very well today. Yes, if a site loads a ton of external content it has the potential to break. But that doesn't apply to just JS but also images and all other static assets. If a JS-heavy site is hosted completely from its own domain there's nothing stopping easy archival of it.

afandian 6y ago
We're talking about mostly-text-pages which have no sensible reason to rely on JavaScript to render, not rich webapps. In these cases I consider the text to be a meaningful representation for the purposes of indexing or archive. I don't agree with this: > Search engines and archival tools can handle all this very well today. I think most developers have been in a situation where they had to explain to users that a moon on a stick isn't easy just because Google can do it. It may be commonplace, but it's not easy or cheap. The difference between real HTML and JS execution is orders of magnitude of time, expense, maintenance, and stuff to break. That really can't be underestimated. It's the difference between a 500 millisecond call to curl and a whole headless browser and a 5 second wait. I hope you don't think I'm putting this too strongly, but this raised bar is a force in the monopolisation and de-diversification of the web.

asddubs 6y ago

>and then execute them (because it may asychronously loads further scripts whith are required to load the content). And then wait for it all to execute. not to mention potentially rewrite the executable code to still work on the archive copy, or potentially end up with a copy where all clickable links are broken depending on the specifics (and sometimes also content further down the page if scrolling triggers dynamic loading). And if the site doesn't update the URLs to be unique for each "page", well good luck finding that dynamically loaded content in the archive at all to begin with.