[pgeorgi]

It really depends on what you want to do: disseminate information (with a canonical URL that you control) or shovel users to your server?

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.

[ENGNR]

But it is an attack on the open web, Google is now sealing off the 'user leak' holes like Facebook did to keep people within their ecosystem. That's all well and good for Google, but we all rely on a relatively neutral search engine and we've relied on Google not to come back down the abstraction levels and into the application space. From a business point of view the game has changed and Google need to be treated as hostile even if they don't know it yet

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

[JoshMnem]

AMP isn't really about speed -- it's about the appification of the open WWW.

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...

[pgeorgi]

> Maciej Cegłowski already recreated the Google AMP demo page

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)