When you've got good service they load quick without annoying popups / ads.
If people hate amp, maybe it’s time to adjust the web standards to enable amp experience with the html6 web.
(Disclaimer, I do work at Google)
Make site load speed a significant factor in search results ranking and the entire web would get faster without the duplicate work of maintaining AMP pages.
Also let's not forget that Google's Doubleclick (the most popular adserver) is the biggest and slowest component of most pages on the internet.
If some of you remember it, it was just another level of awful compared to regular ads and even pop-ups.
AMP is build on top of the web standards. It does nothing technical a normal webpage can't do. It's almost purely a political thing: It helps push these technologies by framing it as this cool and important new thing from Google (which many responsible for websites feel like they have to follow for SEO etc) instead of simply good engineering, which is a boring thing that nobody cares about if marketing wants to add another set of javascript to a site. In turn, it kind of punishes websites that already are efficient when they do not use AMP to achieve that.
What does that mean exactly?
One advantage of a setup like this would be the possibility to instruct your browser to reject any non-AMP pages (or make them click to play, or otherwise indicate them), if you were on rural internet and didn't even want to bother loading a slow page.
I have noticed HNers conflate AMP the standard and Google Search's caching behaviour and/or ranking of AMP pages. I love the former, and not the latter. They really ought to make it possible for mobile search users to opt-out of getting AMP results.
I'm not one to write much about AMP, but I don't see why simultaneously disliking page bloat and AMP is confusing. I simultaneously dislike (or like) many pairs of things that are apparently at odds with one another.
The charitable reading of those of us who dislike AMP and page bloat simultaneously is that we want developers (and, importantly, the people who give direction to those developers) to economize on their own. Stop adding every hip third-party script, social sharing widget, tracking library, and framework to your otherwise simple webapp. It's quite easy to trim the fat from a webapp; you just need the organizational conviction to do so.
AMP is a trojan horse, in more ways than one. One good: It uses a compelling marketing message to deliver much-needed trimming. But two things are obvious to most developers: (a) it's not necessary to adopt AMP to make your app trim and (b) AMP comes with a lot of baggage. So the message from HN is: there are better options, and they're not even technically difficult.
I hate page bloat because it's slow.
I hate AMP as it's an obvious, extremely damaging, land grab.
It is reasonable and correct to hate both web page bloat and Google's so-called "solution" that breaks the web.
And the pages aren't hosted by Google.
What are the chances that Apple would allow me to change the default browser on iOS?
I'm just hearing about amp tonight and trying to understand what it is. Why are people saying it ruins the URL? Does it change the website address to a google URL? Why are people criticising it saying "hosted not cached"?
I gather the caching works similar to Akamai, with a configurable TTL on file types for the origin server?
This is because the way Google gets those lightning-fast results for AMP pages is to rehost them onto their own server and background-load them while you're viewing the search page. It's even a reasonable position -- they want to do the background-loading safely, so having known-good content helps them.
People are calling this rehosting because, well, your content is hosted on Google's servers, in a very visible way to anyone who sees the URL. If you share it, that's the URL that goes to other people rather than the canonical one.
That said, non-Google browser makers have been doing things to mitigate this. iOS Safari notices when you're trying to share an AMP URL and figures out the canonical one for you to share instead. (I hear Firefox does this, too, on Android as well.) It's a bit silly that the major browsers are all adding in Google-AMP-specific hacks like this, though.
Isn't copying the canonical URL the correct behavior? I've just checked and the AMP page you linked has the correct canonical tag set.
The normal behavior of "share sends the precise page I am currently viewing" has the advantage that you know what you're sending, whereas trusting the website's rel="canonical" opens up some potential confusion. (And, I guess, sneaky attack vectors, though someone who wanted to exploit that could do so easily enough via JS redirects on non-referer visits anyway.)
The Google Amp people certainly think that's the right way to do it, as we can see here: https://news.ycombinator.com/item?id=15085159
EDIT: Actually, I'm seeing some claims that iOS Safari is just generically doing share-is-rel-canonical now. I haven't tested it personally, but...
So for instance if a user clicks the "comments" link on a blog post, it won't then skip the article when people view it.
Though I can also see downsides. For instance you might click on a specific version of a product on an ecommerce site. If you share it and say "I love this version!", that information could be lost in the process.
And besides, I'm still for expanding 3g coverage instead of starting to experiment with / roll out 5g as they are... we don't need new tech (in this regard), we need to roll shit out and do shit properly.
(I don't work at Google or Facebook or wherever)