Ha. That's like removing a bunch of methods from a program and claiming it's broken when it crashes. What did you expect to happen when blocking half of a site's libraries?
News sites are hypertext, also known as formatted text, and not web-apps or programs which download and render websites. I expect news sites to load properly in the absence of the AMP CDN (not "half the methods"), not deliberately hide content from users. (I feel the same way about blocking page rendering when web-fonts don't download when their http connections hang instead.)
EDIT: I just moved to desktop. If I block all scripts in uMatrix, OP's URL loads immediately (albeit with a full page of garbage above page content). If I block external scripts in uMatrix, I have to wait 8 seconds before anything appears.
>News sites are hypertext, also known as formatted text, and not web-apps or programs which download and render websites.
No, there are many thousands of websites that render their content dynamically on the client - news or otherwise. Facebook, Twitter, and Reddit all make use of client-side rendering (and all provide news services).
>not deliberately hide content from users
Your browser also "deliberately hides content". It waits a few hundred milliseconds before triggering a paint, just to avoid content from jumping around. AMP pages do the same -- unless you break the mechanism of course.
> Facebook, Twitter, and Reddit all make use of client-side rendering (and all provide news services)
Oh, come on. You and I both know that those are social media apps which act as news aggregators, and are not themselves sources of textual news articles. _fbpt was clearly talking about the latter.
What is the meaningful distinction between news websites and non-news websites? Client-side rendering is just a technique which isn't specific to any industry.
This is like a car that tries to phone home every time you start it, so either you keep the phone service active and get a salesperson talking to you while driving, or you disable the phone and the car leave the immobiliser active for a minute each time you try to start the car.
Using a CDN isn't the problem on it's own; the problem is the (unfortunately common) shoddy programming practice of assuming error never happen. Good programming almost always involves checking for and properly handling errors. Using the returned value from fopen(3) without checking if it was NULL probably results in the program crashing when displaying a simple "file not found" error message would have been more appropriate.
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.
I agree with you. However understand that AMP actually does have a failsafe here, and it's exactly what the OP is complaining about. After a timeout (to allow for shoddy network conditions as you described) it will load the content as best it can.
All three cases are actually covered (full-script support, partial-script support, and noscript support). That's more resilient than most apps.
Agree. To put it another way in hope of driving this home:
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.
If you turn off all scripts AMP has a <noscript> block that disables the 8s timeout. The OP is blocking only external scripts, which not surprisingly looks a lot like a very bad network connection.
(Disclosure: I work at Google on making ads be AMP)
> Why 8s though? That’s well into “give up on loading this page, close the tab and try somewhere else” territory.
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.
No, the page loads perfectly fine if Javascript disabled. It's only if you go out of your way to break the page in the most difficult way possible that the script will fallback to having a delay.
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.
Phoning home is where a web site uses Google Analytics for example, while a CDN is where the assets you actually want are loaded from a server with large links to Internet backbone near you. Completely different things, which are sometimes conflated by people confused about the nature of the argument.
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.
>Calling the phone home feature a required library is part of the malintent from Google.
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.
