The AMP brand is only toxic on HN, among iOS users who don't know any better. The article itself perpetuates a common mistaken belief among iOS users — that AMP implements its own scrolling. The problem stems from the root source of all of the author's listed problems — that AMP uses iframes. Mobile Safari had a bug where iframe scrolling is different from scrolling in the rest of the system. On every Android browser, it works just fine.

Similarly, that Mobile Safari's reader mode doesn't work with AMP is simply because it doesn't understand iframes and doesn't work on canonical URLs, unlike every other reader mode (both websites like outline.com and browsers like Firefox) I have used.

The real issue is that Safari is such a buggy, rarely updated browser that publishers have to choose between speed or UX.

(Author here.) I think the AMP brand is toxic roughly everywhere.

Many users don't know what AMP is, and don't really care—in fact, there's some evidence that users like AMP in search results, or at least they like the performance—but as far as I can see in tech communities like HN and Reddit, the vast majority of people who know what AMP is also know that they hate AMP. (Scroll up and down on this thread a bit!)

As for why it's toxic, I don't think we have to agree about that, but it's not just the UI problem. The URL problem (AMP URLs point to google.com instead of the original site) is a real, significant problem in its own right.

The URL problem is the root of the claim that "AMP is Google's attempt to take over the open web."

IMO, if it were just an iOS scrolling issue, AMP would just be controversial: love the speed, hate the scrolling, eh, it's a wash. But the URL problem is what really gets the flamethrowers running!

They're actually going to fix the URL problem once and for all using [Cross-Origin Server Push][1] in the upcoming Signed HTTP Exchanges standard. Here's their blogpost on that: https://amphtml.wordpress.com/2018/01/09/improving-urls-for-...

[1]: https://tools.ietf.org/html/draft-yasskin-http-origin-signed...

(Author here.) The "Signed HTTP Exchanges standard" is part of the Web Packaging standard, which is, indeed, the whole point of the article. https://github.com/WICG/webpackage