In the former case, AMP caches are a reasonable compromise since it's really just a free CDN. In the latter case, that cache is annoying because of how it needs to fit in the design of the contemporary web. See the last paragraph of https://amphtml.wordpress.com/2017/01/13/why-amp-caches-exis... for some ideas on how to improve the platform so the caches wouldn't be necessary for much of AMP.
The correct way to fix these problems would be to teach people how to make their sites faster rather than enforce restrictions on how they create and monetize their online publications.
"Pinboard founder Maciej Cegłowski already recreated the Google AMP demo page without the Google AMP JavaScript and, unsurprisingly, it's faster than Google's version."
https://www.theregister.co.uk/2017/05/19/open_source_insider...
He solved a different problem.
I don't think anybody at AMP claims that fast pages aren't possible. Their claim is that there's a need to enforce certain rules to achieve a certain quality of service.
> teach people how to make their sites faster
In a way, that's what AMP is doing. It picks a subset of HTML5 that can be rendered efficiently, and - for now - uses javascript to fill in the blanks (eg. where desired capabilities are forbidden due to how they're commonly implemented: provide build a polyfill that's better suited) and for enforcement of these rules.
As linked in my parent post, there are already efforts to offload some of these constraints into standards to be enforced by browsers - I fully expect the AAMP scaffolding to let go of that soon after (or revert to shims)
If speed is the answer, then sure offer AMP, but also offer a lightning bolt next to pages that load within 'x' milliseconds. Reward speed regardless of implementation
It's only going to get worse with voice interfaces, see what Echo now does (https://www.youtube.com/watch?v=BXEu8RcneZQ).
A vibrant ecosystem is key to competition, it's not in our long term interests to let the web consolidate into an oligarchy
Here are some recent articles about it:
https://www.theregister.co.uk/2017/05/19/open_source_insider...
When such an AMP search result is opened from the aforementioned Google Search source, it will open in a Google Search-wrapped frame reader, such that the outside is Google Search -- although this is not visually obvious to the user -- while the inside the AMP article. The browser-level URL for this endpoint begins with 'google.com/amp/'. While it's now possible to get the article's original link from this viewer, this was not present at launch, and it was a frequent source of criticism.
This is a brief restatement of a more in-depth description I gave in a different thread [1].