Then the noscript tag wouldn't fire here. But that's just shooting yourself in the foot. A page won't function with half its code running.

I think you might have missed the point of my comment. If you block AMP scripts, you will definitely encounter broken sites. The point I was trying to make are that those broken sites are mostly junk anyways. Overloaded with ads, tracking, and other manipulative content geared at turning me into the product. I haven't missed those sites any. However, I recognize that I'm not the average user, which is why these blocks are in my aggressive list. I initially put the blocks into my regular block list which is then consumed by Steven Black's hosts [1]. Very quickly a ticket was opened to whitelist AMP [2]. Funny enough, the user requesting that AMP be white listed posted screen shots of broken advertisements disguised as 'news' articles. To make everyone happy I moved it to my aggressive list which isn't included in Steven's project.

Anyways, long story short, I don't like AMP and don't mind the occasional broken site. But it's definitely not for everyone.

[1] https://github.com/StevenBlack/hosts

[2] https://github.com/StevenBlack/hosts/issues/657

AMP is shooting users in the foot. They are content-based pages with no reason for making users wait for 8 seconds if JS isn't loaded. See also:

https://developer.mozilla.org/en-US/docs/Glossary/Graceful_d...

@SquareWheel - there is no reply link on your comment, so I'm replying here. I read your comment and I understand it.

There is no reason to load any JavaScript on a page that only contains some text and images. If the goal is to speed up loading, then blocking unnecessary JS shouldn't break the page. It's clear that page speed is not Google's primary goal with AMP.

Clicking the permalink often brings up reply for lower nested comments.

>There is no reason to load any JavaScript on a page that only contains some text and images.

While I've not read through all of Amp's JS to know what it's for, I will say I've used JS to specifically speed up static pages before.

One example is the Filament Group's loadCSS script[0]. This allows for cross-platform asynchronous CSS loading.

Font loading is also another tricky subject. Linking non-blocking font assets while minimizing FOIT and FOUT is still not a solved problem. Smashing Magazine just had a 50 minute video presentation[1] on this problem. JS loaders are a common approach.

So I disagree with you that page speed is not the primary goal here, simply because I've run into these same kinds of problems myself and can relate. Google also has the advantage that their JS will almost always be cached by end-users.

[0] https://github.com/filamentgroup/loadCSS

[1] https://www.smashingmagazine.com/2018/07/smashingconf-videos...

> So I disagree with you that page speed is not the primary goal here

I think you're missing the bigger picture behind it. Google is making a power grab to appify the WWW on their own domain, and they are coercing publishers to implement it by giving lower search engine rankings to sites that don't go along with the scheme. It's an abuse of their position. It goes against the fundamental nature of the WWW and the basic ideas of decentralized technology.

Sorry, but that's a Gish Gallop argument. It's completely unrelated to what we've been discussing, and frankly those points have been argued over so many times already I see no benefit in repeating the exercise.

>They are content-based pages with no reason for making users wait for 8 seconds if JS isn't loaded.

I think you should read my parent comment a little bit closer.

With adblock, most pages are missing most of their JavaScript.

The JavaScript should create the fade style, then it will only happen if js is running.

I'm pretty sure the JS actually stops the fade. The inline CSS will be executed very early on in the page, before any assets are loaded.

Though it seems to me if the page is fast enough anyway (as amp pages claim to be), then this trick shouldn't be necessary anyway.