AMP is built on WebComponents, an open HTML5 platform. Google's AMP Cache service isn't even exclusive as Cloudflare offers one as well. What "lock-in" are you talking about?
As for a "degraded experience" that's subjective, but users seem to far prefer it.
If I can't get from the search engine to the source page, that's a degraded experience. If I can't copy-paste the url but there's some ridiculous browser-defined JS method for inserting whatever the site host says the link is into my clipboard, that's a degraded experience. And we'll see further degraded experiences as Google turns "We screwed up web linking!" from a despised practice into a first-class, browser-supported practice.
The Google AMP viewer/cache is how AMP works in reality. Google has indicated that they are not willing to turn the cache off so it's fair to evaluate AMP in that context.
I don't see anything in AMP syntax to turn off the cache or choose which one is used. For links coming from Google search, Google's AMP cache will be used.
It's the same way you get any page into Google's search results. You can either wait for it to be indexed, or submit it manually. As long as you're supporting the protocol, there shouldn't be a problem. AMP pages have a custom attribute in the <html> tag that lets Google distinguish them.
You can also link your pages explicitly, as described here.
My understanding is that this markup will trigger Google to add the page to their own cache and present a link to the page in their cache in the search results. (The search result pointing to "google.com/amp/...", the page showing the infamous header, etc.)
I don't see how you can use that to get other caches (or even just the original AMP page) into Google's search results.
(Sorry if I'm mistaken though)
> The cache acts as a CDN to improve page speeds, but isn't a requirement for indexing.
How, as a site author, would you control that?
Is there a way to use AMP but explicitly opt-out of caches? I'm not aware of one. (Short of deliberately violating the AMP spec, but then you can't really say you're using AMP anymore)
By having the "desktop" version of the site (which has a high PageRank) point at the AMP version of its pages using rel="canonical", perhaps? (And then the AMP version could redirect desktop viewers back to the desktop site.)
What do Web Components have to do with anything? This seems like reading "Apple's App Store encourages lock-in and provides a poor user experience" and replying "The App Store is built on open standards like HTML, HTTP and URIs." None of that is untrue, but it's essentially talking around the point.
The criticism of AMP I keep seeing is that "because it uses weird HTML, it must be proprietary and designed for lock-in". But because WebComponents allow you to extend HTML by introducing new elements, it's actually completely standards compliant in HTML5.
Based on the parent comment's criticism that it's designed for "lock-in" (without any elaboration), that's the argument I was addressing.
Google, and solely Google, control what tags are allowed on AMP pages, and thus what advertising and analytics companies are allowed to compete on AMP sites. AMP also requires that every page depends on external JavaScript sourced from Google, which can explicitly change without notice, and thus can't be audited and locked via SRI hashes.
These points of centralization and control are antithetical to the premise of the Web as an open, inter-operable, democratic medium.
You could also serve the JS from your own domain if you prefer. Similar to Google's cache, it's something available as an option to you.
Regarding the Amp standard, that is indeed something controlled by Google. Particularly as it pertains to the SERPs. But because it's open you also have the option to fork it, or write a completely different implementation if you desire.
If you'd like to modify Amp but still stay within their standard, you can submit a PR as well. It looks like about 75% of PRs are merged.
> "AMP is an evergreen JavaScript library. We will not allow users to lock themselves into a particular release."
Which completely precludes using SRI.
Further, pages serving their own copy of the JavaScript "won't be considered valid AMP," and thus would be ineligible for the placement benefits afforded to AMP pages in Google results.
AMP's governance is not similar to HTML's. Changes to HTML require consensus between mutually competing browsers, while AMP is a single-vendor land-grab. That consolidation of power threatens to return us to the dark ages of Microsoft's sole dominance of the de facto Web.
As for a "degraded experience" that's subjective, but users seem to far prefer it.