[lern_too_spel]

> It's not an open alternative. All decisions on what AMP should look like and what it supports are done by Google behind closed doors. See, for example, AMP 4 Email [1]

Your examples predate https://www.google.com/amp/s/blog.amp.dev/2018/11/30/amp-pro... and no longer seem to apply.

> The only reason AMP exists is because Google needed its own way to control content.

That's nonsensical. Why then does Bing use it?

> Because you're forced to compete against the behemoth on the behemoth's terms.

Why are they forced to use it? I would really like to see your position stated coherently.

> AMP's problems are well documented.

How do you propose to achieve instant loading web pages, while working around all of iOS's bugs?

> It is not like RSS in any way, shape, or form.

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.

[dmitriid]

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

[lern_too_spel]

> Advisory Committee has no say in anything that AMP does.

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.

[dmitriid]

> Why did you focus on one irrelevant aspect of that document?

Because that irrelevant part was the only one that would give AMP any semblance of being open.

> iOS had broken iFrame scrolling for years. If you can implement safe instant loading while working around that iOS bug, let's hear it.

I advise you learn something for yourself. Several fixes were provided to AMP but they were rejected without discussion.

> Exactly the same as RSS.

Let's see how AMP is "exactly the same as RSS":

- RSS is a feed, AMP is not

- RSS feed is discoverable via a meta tag, AMP pages are not (you have to search in a search engine, or have a cache of pages)

- RSS is a simple format that can be trivially parsed to retrieve data such as: author, publish date, url to original page, description, and content. AMP requires a near-full HTML parser with AMP-specific extensions: AMP is not valid HTML 5, AMP validator will allow some non-valid HTML5. Additionally, AMP relies on custom elements.

- Any and all RSS readers and aggregators link to the original website in a trivial and discoverable way. There's no url hijacking. AMP all but requires AMP Caches to be fast, and AMP Cache design all but requires to display content not at the original link, but at the Cache's URL. For several years the "open" AMP would deny this was a problem and pretended "it was an implementation detail that AMP is not concerned with" and "we will work with browsers on how to present the canonical URL". And even now the largest AMP cache regularly employs dark patterns to prevent users from visiting the canonical URL.

So yeah. I see how AMP is exactly like RSS.

[lern_too_spel]

> Because that irrelevant part was the only one that would give AMP any semblance of being open.

No, that is the only part of the document when taken out of context that gives AMP any semblance of not being open. The TSC is what makes AMP open, and you ignored it and continue to ignore it after I explicitly called it out.

> Several fixes were provided to AMP but they were rejected without discussion.

Where?

> RSS is a feed, AMP is not

You need to work on your reading comprehension. That quote that you took out of context says that AMP is exactly like RSS on that particular point. I have repeatedly explicitly pointed out that AMP is like RSS items, not like RSS feeds.

Let me know when you're ready to continue the discussion in earnest instead of going to great distances to strawman every point.