Live data from Hacker News

AMP: the missing controversy

ferdychristant.com

141–143 of 143 posts

Re: AMP: the missing controversy

#141

Earlier quoted context omitted.

> It won't fix this. The only thing it will do, it will let browsers show the original link, not the AMP link, and fix the UI. The problems described in the article will not go away. No, it does more that, it does away with the need to use iframes which break scrolling, and it allows all sites to use preloading without violating privacy see https://redfin.engineering/how-to-fix-googles-amp-without-sl... "If other bro…

> TheVerge.com non-AMP > yada yada For some reason you think that the solution to that is "let's do a standards-incompatible aggressively preloaded slimmed down page that will live on our ultra-fast CDN/cache servers". Can you see the problem? Also, can you see why web packages don't solve the problem (hint to start you thinking: not everyone can run their pre-rendered pages off of Google's CDN. Even Google's own AMP…

> "let's do a standards-incompatible aggressively preloaded slimmed down page that will live on our ultra-fast CDN/cache servers".

How can it be standards incompatible if it works in existing standards compatible browsers?

> Also, can you see why web packages don't solve the problem (hint to start you thinking: not everyone can run their pre-rendered pages off of Google's CDN. Even Google's own AMP isn't fast if it's not preloaded from Google's cache)?

Did you read the Redfin article? The point isn't for you to run the CDN or do the prefetching, the point is, how do people find your site and articles? Either they find it through Google/Bing/Baidu/etc, social network sites (Twitter/Facebook), or aggregation sites (Reddit, HackerNews, etc). The point is, for large aggregation sites with a lot of traffic to roll out preloading on CDNs. So for example, Cloudflare already supports AMP-Cache, and Reddit could roll out prefetching if desired.

And you completely missed the point that, getting publishers to adopt AMP gets them to slim down their sites even if you don't use the AMP cache or preloading. Something everyone has been trying to get them to do for years, including Google, who has been trying to penalize slow sites for years (https://www.linkedin.com/pulse/20140827025406-126344576-goog...)

So hurray for you making a slimmed down page, but you're not the target audience, the huge number of other sites that have for years, bloated the Web and haven't responded to previous attempts to force them to go on a diet are the target.

Re: AMP: the missing controversy

#142

Earlier quoted context omitted.

Let me ask you the question I've tried to get the AMP tech lead to answer a couple of times: Why won't Google hand AMP over to the W3C? Bear in mind, in discussions with the AMP tech lead, I've discovered AMP4Email isn't even being approached as a standard. Gmail is implementing it as a proprietary fork of email, and the AMP Project is just deciding whether or not they'll support it directly. It seems to me that Goog…

I don't know the answer, I'm not involved in those things, as I say in my profile, my opinions are mine. In my opinion, it might be better to do this through the W3C or IETF, but I don't have the context, so that's an ill-informed gut opinion. Perhaps there's a perception that the W3C is premature at this stage, as things are quickly evolving and standards committees usually standardize stuff after there's been some…

Some of us don't really look to W3C for guidance or support any more : https://www.reddit.com/r/javascript/comments/5swe9b/what_is_...

I'm not a fan of some of the aspects of AMP, but I feel like somebody needs to try something new and stir the pot a bit.

Re: AMP: the missing controversy

#143

Earlier quoted context omitted.

> TheVerge.com non-AMP > yada yada For some reason you think that the solution to that is "let's do a standards-incompatible aggressively preloaded slimmed down page that will live on our ultra-fast CDN/cache servers". Can you see the problem? Also, can you see why web packages don't solve the problem (hint to start you thinking: not everyone can run their pre-rendered pages off of Google's CDN. Even Google's own AMP…

> "let's do a standards-incompatible aggressively preloaded slimmed down page that will live on our ultra-fast CDN/cache servers". How can it be standards incompatible if it works in existing standards compatible browsers? > Also, can you see why web packages don't solve the problem (hint to start you thinking: not everyone can run their pre-rendered pages off of Google's CDN. Even Google's own AMP isn't fast if it's…

> How can it be standards incompatible if it works in existing standards compatible browsers?

You really have no idea how the web works, do you? Browsers do a best effort to display any page. Even if the HTML is totally absolutely invalid, the browser will go out of its way to display at least something.

The mere fact that something is displayed by a browser doesn't make it standards-compliant.

AMP is standards incompatible because:

- its HTML is not valid HTML 5 (just a few examples here: https://news.ycombinator.com/item?id=16467873)

- whatever extensions to HTML 5 they bring are not a part of any HTML standard, past or present. And it doesn't look like Google is interested in making them a part of any future standard.

> So hurray for you making a slimmed down page, but you're not the target audience, the huge number of other sites that have for years

That's not the point, is it? Google will still penalise my page even if it's way slimmer than a standard AMP page. And since I cannot afford to run a Google-scale CDN, it will perform worse than an AMP page.

So here's what we have in the end:

- Google (and Google alone) decides what AMP will look like. There are no discussions with the web community at large or the standards committees.

- Google (and Google alone) decides that only AMP pages end up in its own proprietary AMP cache. (Other "big aggregators" may/will also decide that only AMP pages can be in their proprietary caches)

- Even if a web developer follows all of Google's performance tips (https://developers.google.com/speed/docs/insights/rules) the page will still be penalised because it's not an AMP page (i.e.: not a page developed using whatever a big corp has decided, and running from a big corp's CDN/cache)

- Even Google's own page speed tools tell you that AMP is not fast, and yet everyone (even 100% optimised slimmed down pages) is penalised if you're not running the page from an overpowered private cache

A lot of mental gymnastics and total ignorance of how the web works goes into calling this an open, extensible web that will benefit everyone.

Post reply on HN