This principle is also true when writing web pages; if you load an external resource, you need to check for and handle the case where that resource might not be available. Failing to load a resource can happen for many different reasons, not just someone blocking it with their client. Proper handling the error depends on what the resource is: display the content that is already available (perhaps in a less than ideal state), or if that isn't possible displaying an appropriate error message. This includes cases where the Javascript itself isn't available (for any reason).

Networks are not reliable or universally available. Quality programming understand that and does the best it can when failures happen.

All three cases are actually covered (full-script support, partial-script support, and noscript support). That's more resilient than most apps.

It is sad when the brightest minds in the world decide that the fix for "flash of unstyled content" is to show no content at all for close to 10 seconds.

Seriously: 8 seconds mandatory waiting would have been considered slow even 10 years ago and the only reason it passes now is because Google got a stranglehold on most of the web.

Edit: improve last paragraph

(Disclosure: I work at Google on making ads be AMP)

Perhaps a better option is finding ways to prevent content jumping around so much while assets are loading.

That 8s timeout is for loading the AMP JS from the CDN. You want a time limit that separates "you're on a slow connection, keep waiting" and "just give up, it's not worth it". I suspect it was set by looking at network graphs, but I don't know.

What the OP is doing, blocking JS and also ignoring <noscript>, is bizarre, and something you should expect to break sites.

> Perhaps a better option is finding ways to prevent content jumping around so much while assets are loading.

AMP does that very well, but only by taking control of the process of rendering, which requires JS.

(Disclosure: I work on making ads be AMP.)

My complaint is not the use of CDN, it is the forced delay to load a page when the CDN is not available or certain resources are blocked. This is a direct form of punishment from Google: refuse to let us track everything you read, we will make it uncomfortable for you to read anything.

Disabling the phone-home feature is nothing like poking holes in the fuel tank.

Then why the complaint about "phoning home"? Analogies are imprecise and brittle.

>This is a direct form of punishment from Google

If you show me some proof I'll be glad to believe you. Occam's razor says it's a simple fallback for unexpected results.

>Disabling the phone-home feature...

Blocking a required library? Who is straw-manning now?

Calling the phone home feature a required library is part of the malintent from Google. Most websites I interact with don’t need a Google Analytics in order to function, for example. If I block a Google Analytics they refuse to work. The simplest explanation here is that time-short programmers just copy the code presented by Google, who in turn want everything to report back to them so they can monetise third party sites.

Building your site for AMP and blindly using the 8s timeout from the Google copy and paste archive is exactly the same story. You don’t need that much time to load all the assets, that timeout is there only to punish people who block the AMP resources.

It is code required for the WebComponents to function. It's also charged with optimizations such as sandboxing of iframes, making requests synchronous, and calculating layout to reduce paints.

Clearly it's not "phoning home". The script provides clear actions, as laid out on the amp project website.

>You don’t need that much time to load all the assets

On American broadband, perhaps. Other countries do not have the same infrastructure.

>that timeout is there only to punish people who block the AMP resources.

Citation, not speculation, needed.