[nightpool]

From a technical perspective, AMP had two, intertwined goals: 1) allow third parties to safely rehost your page, so that they could provide a seamless preloading experience—fetch & render the page in the background, and display it to the user immediately when they click a link. This massively improved the time it took to load search results on mobile web, since it moves the request out of the critical path and allows Google's CDN to serve your assets. 2) Provide a front end framework that focused on performance and UX, forcing developers to get rid of layout shifts, weird scroll effects, and other things that made mobile web browsing a nightmare. This framework allowed for a limited subset of HTML and CSS, but no custom JS, allowing it to enforce these rules for all rehosted pages.

[acdha]

> This massively improved the time it took to load search results on mobile web, since it moves the request out of the critical path and allows Google's CDN to serve your assets

Kind of, some of the time. In practice, that massive amount of render-blocking JavaScript made it slower - I noticed this on a daily basis using the web on the subway here in DC. The Washington Post loaded consistently faster without AMP, but the big win was the long tail where you could read content on normal pages but AMP was either blank until you reloaded, or took 5-10 seconds longer because once the AMP JS loaded it then had to fetch all of the resources it’d blocked behind a lazy-loader.

[Sohcahtoa82]

> Provide a front end framework that focused on performance and UX

And this is huge.

Non-technical users that don't care about the shady things Google did involving AMP probably think AMP is a godsend, if they even know AMP is even a thing.

AMP pages load incredibly fast, are incredibly responsive, and are far less annoying. Your typical end user will likely prefer AMP.

Thing is...we don't need AMP to get those features. But somewhere along the last 10 years, web developers lost the plot and now seem to think a static blog needs to serve several megabytes of JavaScript. They think they need to implement smooth scrolling in code, when every browser already does it natively.

[rsanheim]

AMP pages have been far more annoying in my experience. It breaks the standard web controls (ie no tap on the top to scroll to top), breaks copying links, and locks you into the google ecosystem at the user's expense.

Thank goodness its falling out of favor.

[notreallyserio]

IMO the issues with controls are worth the tradeoff. The alternative ends up being annoying sites like arstechnica (non-AMP) which relocates content while you're reading it.

[nightpool]

> Thing is...we don't need AMP to get those features.

I addressed this in another comment thread (https://news.ycombinator.com/item?id=29269423), but I disagree. The fundamental problem is one of incentives—individual companies don't have the leverage to fight back against ad companies and advertisers that want to implement bad user experiences and slow loading JS. Google's adoption of AMP forces publishers and ad networks fall into line, by enforcing limits on floating ads, popover, interstitials, custom JS, etc. Is this self-interested on Google's part? Maybe. But it's hard to argue that it's not ultimately better for the consumer.

[dbbk]

Core Web Vitals achieves this anyway. Which is why Google is switching to using those signals instead of AMP in its search ranking.

[kevin_thibedeau]

> AMP pages load incredibly fast, are incredibly responsive

Compared to an unfiltered web experience. AMP content is still burdened with mountains of unnecessary JS that hurts performance.

[dbbk]

> are incredibly responsive

That's not my experience. Every time I try reading a long article on an AMP page, the experience basically crashes. Text rendering stops and you're just scrolling through a blank white pages.

It tries to be too clever with its rendering. And it fails almost every time.