| > Your examples predate <Advisory Committee> Advisory Committee has no say in anything that AMP does. Everything is designed and specced inside Google (or Google-dominated work groups) and then vetted by the Technical Steering Committee. Advisory Committee's findings and advise is non-binding: https://github.com/ampproject/meta/pull/37 And all the WG's are assigned projects that have already been accepted into AMP (such as AMP 4 Email). And yes, my example is important because it was a huge change that no one asked for, but now it's in AMP. As are all the other changes that already hurt the web. > Why are they forced to use it? I would really like to see your position stated coherently. Google has near monopoly on search. In order to compete with it you need to provide nearly all of the same features. > How do you propose to achieve instant loading web pages, while working around all of iOS's bugs? There are no bugs in iOS that preclude instant pages. And the bugs that AMP introduced are, well, the bugs that AMP introduced. AMP broke the behaviour on purpose and refused to implement any suggested fixes. > This just demonstrates that you don't understand AMP, don't understand RSS, or don't understand both. AMP allows the link aggregator to cache and directly serve the article contents, exactly like RSS does. I perfectly understand what AMP and RSS are. You don't understand what either one is. RSS was never about caching or link aggregators. RSS is a web feed. That has a standard XML format and can be read by anyone: a client app on your phone, a client app on your desktop, a link aggregator that can be built by a half-decent engineer in about two evenings. Additionally, it is trivially discoverable by including a standard meta tag on a page. Also, RSS always leads to the original URL. AMP is not a feed. It's a collection of specially constructed HTML pages (which are not valid HTML5, by the way). They are not "instant". They are underperformant by Google's own standards (try running Google's own Lighthouse tools report against one from cold cache). They are only "instant" when significant effort has been spent setting up an AMP cache so that some or all content is already on the client's browser before the client hits the AMP page. They are not discoverable. A meta tag linking to an AMP version will only link one URL, that's it. There is no feed. An AMP cache destroyes the very essence of the web: linking. You will not get the original URL, you will get the cache's URL. Implementing an AMP cache is a significant endeavour, and only a handful exists (as far as I know, there are no opensource AMP caches). |
Why did you focus on one irrelevant aspect of that document? The document also includes the Technical Steering Committee, a majority of whose members do not work for Google. That doesn't fit your narrative.
> In order to compete with it you need to provide nearly all of the same features.
In other words, users want it.
> There are no bugs in iOS that preclude instant pages.
iOS had broken iFrame scrolling for years. If you can implement safe instant loading while working around that iOS bug, let's hear it.
> RSS is a web feed.... There is no feed.
I was talking about items in the RSS feed as you quoted yourself in an earlier comment and then somehow forgot, but lets ignore this strawmanning and continue.
> That has a standard XML format and can be read by anyone: a client app on your phone, a client app on your desktop, a link aggregator that can be built by a half-decent engineer in about two evenings. Additionally, it is trivially discoverable by including a standard meta tag on a page.
So exactly the same as AMP.
> They are only "instant" when significant effort has been spent setting up an AMP cache so that some or all content is already on the client's browser before the client hits the AMP page.
Aside from effort, this is exactly the same as RSS. The additional effort is from doing things that RSS cannot do like monetization, interactivity, analytics, A/B testing, and above the fold optimizations. Cloudflare handles that effort fine.
> An AMP cache destroyes the very essence of the web: linking. You will not get the original URL, you will get the cache's URL.
Exactly the same as RSS. A link to an RSS reader is a link to the reader's URL, not the original URL.