> AMP does not introduce proprietary browser extensions or syntax. It's a custom element framework,
That's not exactly true.
AMP is a proprietary Google product: All valid AMP pages must source remote resources from Google, and all 17 members of AMP's core team are employed by Google.
Specifically, the fact that valid AMP pages must load the framework from https://cdn.ampproject.org/v0.js creates a hard runtime dependency on Google servers. Developers are not allowed to self-host, fork, use an older version, or authenticate the library with a durable subresource integrity (SRI) hash while still remaining valid.
Meanwhile, AMP's governance ensures that Google maintains exclusive control as the sole arbiter of what is and is not AMP.
> There's a separate issue if your concern is Google SERP giving preference to AMP [...] but that's a political argument
It's unreasonable to dismiss the relationship between AMP and Google Search as a mere "political argument."
Google owns AMP, and Google uses Search as a cudgel to force its adoption. Every product manager I spoke with at AMP Conf last year implemented it solely for the special treatment in Google Search.
AMP's (legitimate!) technical merit is not what's driving its growth.
> Otherwise common inaccurate statements are that AMP Cache is Google-only, when in fact, it's a spec others can implement
I don't think you quite understand the concerns people have regarding Google's AMP Cache.
The issue isn't about the existence of other caches, it's about how Google Search only serves AMP documents from its own cache, and sites cannot opt out of that cache while still remaining valid AMP documents.
Concretely: If I published AMP documents, traffic from Google Search would not hit my server directly, nor would it hit any other AMP cache.
> perceptions that if you create a fast site that is AMP-like, but doesn't use AMP, you don't know how it's going to be scored
That's not the complaint. People are concerned about the most prominent, eye-catching, and valuable placement on SERPs being reserved solely for AMP documents. No matter how high my non-AMP document ranks, it'll never have the rich presentation afforded to AMP documents.
> r authenticate the library with a durable subresource integrity (SRI) hash while still remaining valid
According to the discussion, there's concern this creates large scale hard to fix security issues. The alternative is to build something like AMP into browsers themselves, and then the normal Chrome/Safari/Edge/Firefox release process could fix issues.
But in lieu of that, what's your suggestion? Wait years for standards committees to hash out something at the W3C so that browser vendors implement it, all the while users suffer and Facebook Instant Articles or Apple News soak up more and more web traffic into native, or, ship something that creates an unpatchable security flaw across the web without millions of pages being updated?
If not AMP, then what? XHTML Mobile? We've been down that route and it didn't work. Bring back RSS and force mobile publishing to just be RSS summaries for fast loading?
Lost in all of this geek fighting is the fact that there's a billion users out there who don't care about the Web vs Native, they only care that shit's slow as hell and their data plan is expensive, and despite all of this, there was apparently no forcing function enticing publishers to make their pages load faster, if anything, right before AMP, it seems each and every "redesign" of top level mobile sites got SLOWER and loaded even more JS.
I don't really care about AMP, I care about the Web and I hate closed App Stores soaking up content and making it DRM'ed. In my view, we were on a path to the web collapsing under it's own weight, and AMP is a much needed band aid.
If someone can produce a competing framework that does the same thing, can be easily and wildly adopted, and solves all of the problems people are complaining about, I'd wholeheartedly support it in lieu of AMP.
But what I don't want to see is more and more of my content forcing me to download stuff from the App Store, or run inside Facebook only. That's a far far worse situation than what we're in now.
That's not exactly true.
AMP is a proprietary Google product: All valid AMP pages must source remote resources from Google, and all 17 members of AMP's core team are employed by Google.
Specifically, the fact that valid AMP pages must load the framework from https://cdn.ampproject.org/v0.js creates a hard runtime dependency on Google servers. Developers are not allowed to self-host, fork, use an older version, or authenticate the library with a durable subresource integrity (SRI) hash while still remaining valid.
Meanwhile, AMP's governance ensures that Google maintains exclusive control as the sole arbiter of what is and is not AMP.
https://github.com/ampproject/amphtml/issues/534
https://github.com/ampproject/amphtml/issues/5846
> There's a separate issue if your concern is Google SERP giving preference to AMP [...] but that's a political argument
It's unreasonable to dismiss the relationship between AMP and Google Search as a mere "political argument."
Google owns AMP, and Google uses Search as a cudgel to force its adoption. Every product manager I spoke with at AMP Conf last year implemented it solely for the special treatment in Google Search.
AMP's (legitimate!) technical merit is not what's driving its growth.
> Otherwise common inaccurate statements are that AMP Cache is Google-only, when in fact, it's a spec others can implement
I don't think you quite understand the concerns people have regarding Google's AMP Cache.
The issue isn't about the existence of other caches, it's about how Google Search only serves AMP documents from its own cache, and sites cannot opt out of that cache while still remaining valid AMP documents.
Concretely: If I published AMP documents, traffic from Google Search would not hit my server directly, nor would it hit any other AMP cache.
> perceptions that if you create a fast site that is AMP-like, but doesn't use AMP, you don't know how it's going to be scored
That's not the complaint. People are concerned about the most prominent, eye-catching, and valuable placement on SERPs being reserved solely for AMP documents. No matter how high my non-AMP document ranks, it'll never have the rich presentation afforded to AMP documents.