Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMP: the missing controversy

ferdychristant.com

Post reply on HN
Print view View original

121–130 of 143 posts

Re: AMP: the missing controversy

#121

Post by cromwellian »

fchristant wrote: post #118
cromwellian wrote: post #115

Earlier quoted context omitted.

The article is wrong, as no amount of preloading will make the non-amp Verge fast to load as it runs too much JS to block the initial render. You could provide a mobile framework and tools for publishers that helps sites create pages that render fast by putting them on rails. AMP is that framework, other people could similarly introduce tools to help. Chrome DevTools and Google has long offered the Page Speed tools a…

You're missing the entire point. It is fine to have a framework like AMP that puts up technical constraints leading to a performance-friendly web page. The problem is the cache and specifically the preloading of it. This gives AMP an unfair advantage of multiple seconds over anything else.

That's why Redfin (https://redfin.engineering/how-to-fix-googles-amp-without-sl...) pointed out that the Web Packaging spec could fix this. But before you have a general purpose spec that fixes something, you need a specific embodiment that does. asmjs came before WASM. SPDY came before HTTP/2. Flash came before HTML5. I didn't like Flash, but would you have suggested Adobe worked with browser vendors for years to bring the Web up the capabilities needed and never having shipped Flash?

Still, even without the AMP-cache, mobile sites were loading way too much JS, even after Google penalized them. The effect of AMP showing how sites could be loaded as fast as native Apple News/Facebook Instant, has finally gotten publishers to strip down their sites. You might not like the way it played out, but the end result is that not only do end users get AMP-cached fast loading, but they also end up download far less data, because the sites themselves have been pared down.

Re: AMP: the missing controversy

#122

Post by ocdtrekkie »

cromwellian wrote: post #116
ocdtrekkie wrote: post #112

Earlier quoted context omitted.

The problem isn't the code, Ray. The problem is the monopoly forcing people to adopt it. If AMP wasn't a search incentive, nobody would be upset about it. It would just be a trashy thing you can opt into if you want. But by tying AMP to Google's monopoly, all other options to solve this problem became non-viable, because they don't come with Google's search ranking blessing.

Google shipped NaCL built into their browser and Web store and it didn’t take off. Mozilla shipped a subset of JS just like AMP is a subset of HTML and then they put special accelerated support for it if it validated as asmjs. This won and forced everyone else to adopt it even before it was a standard. Eventually, everyone got together and WASM superceded asmjs. Eventually, something will super-cede AMP, but AMP is t…

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 Google only submits to the W3C when it needs other browsers to implement something. Whenever Google's monopolies can handle it, they keep it proprietary.

Re: AMP: the missing controversy

#123

Post by ocdtrekkie »

fchristant wrote: post #119
ocdtrekkie wrote: post #2

We were discussing with the AMP project tech lead over on GitHub trying to suss out details about governance and the like, and it's even scarier than we thought when it came to AMP4Email: Gmail is implementing AMP in email "the way they want to", and AMP Project is just deciding whether or not they want to support it/publish a 'standard'. I strongly recommend this for reading: https://github.com/ampproject/amphtml/is…

hi, I'm the author of the article. I have no idea how to stop it. Bad press doesn't seem to matter, as this has been around for years. One longshot I could think of is reporting it to the EU as anti-competitive behavior. In the case of exclusive AMP preloading on a dominant market (search), it's not that far fetched.

As much as I'm really glad the EU is taking a stand on this, they're also taking too long. The shopping case took a number of years to conclude, and the Android case, still ongoing, has been an infringement Google has operated for nearly a decade now. Suffice to say, if we are waiting for the EU to stop AMP, the Internet will be almost entirely AMP-based before the EU forces them to stop.

Similarly, in the US, by the time Microsoft lost it's antitrust case, Microsoft's dominance in a lot of ways was already cemented, and in those ways, still is. (While obviously the mobile shift has cut them out, almost every desktop PC in every business on the planet still runs Windows.)

Re: AMP: the missing controversy

#124

Post by cromwellian »

ocdtrekkie wrote: post #122
cromwellian wrote: post #116

Earlier quoted context omitted.

Google shipped NaCL built into their browser and Web store and it didn’t take off. Mozilla shipped a subset of JS just like AMP is a subset of HTML and then they put special accelerated support for it if it validated as asmjs. This won and forced everyone else to adopt it even before it was a standard. Eventually, everyone got together and WASM superceded asmjs. Eventually, something will super-cede AMP, but AMP is t…

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 proprietary experience.

The W3C might not even be the right venue. For example, changes to JS go through TC'39, whereas changes to protocols go through IETF. Lots of XML/SGTML spec work has been done outside the W3C. I don't feel knowledgeable enough to make an informed comment.

Re: AMP: the missing controversy

#125

Post by dmitriid »

sseth wrote: post #114
dmitriid wrote: post #100

Earlier quoted context omitted.

AMP is not open web though. It's Google's own walled garden under the guise of an open web.

As a javascript library it is pretty much as open as React or any other javascript platform. It is the caching where the discussion lies - effectively Google is providing a CDN for AMP pages and I agree this needs some improvements. But these should in the realm of technical discussions rather than looking for conspiracies.

AMP is designed by Google, and implemented almost exclusively by Google. It is also used in the most popular search engine in a way that makes AMP feel like it's fast.

Meanwhile:

- it's not fast without Google's overpowered cache/CDN (that no one has a chance to replicate)

- it's not even valid HTML

- it's entire design and development is governed exclusively by Google, with no external input, and all external input is discarded and discouraged. See top comment: https://news.ycombinator.com/item?id=16455593

The fact that it lives on GitHub doesn't make it open.

Re: AMP: the missing controversy

#126

Post by fchristant »

ocdtrekkie wrote: post #123
fchristant wrote: post #119

Earlier quoted context omitted.

hi, I'm the author of the article. I have no idea how to stop it. Bad press doesn't seem to matter, as this has been around for years. One longshot I could think of is reporting it to the EU as anti-competitive behavior. In the case of exclusive AMP preloading on a dominant market (search), it's not that far fetched.

As much as I'm really glad the EU is taking a stand on this, they're also taking too long. The shopping case took a number of years to conclude, and the Android case, still ongoing, has been an infringement Google has operated for nearly a decade now. Suffice to say, if we are waiting for the EU to stop AMP, the Internet will be almost entirely AMP-based before the EU forces them to stop. Similarly, in the US, by the…

Agree with all of that, indeed it is a longshot. This leaves us pretty much with the 'awareness' option.

I'm not hopeful. Even if you're lucky to have a person in your organization that morally objects to AMP, that person will likely still do the commercially most attractive thing when enough pressure is applied.

Re: AMP: the missing controversy

#127

Post by dmitriid »

cromwellian wrote: post #115
dmitriid wrote: post #92

Earlier quoted context omitted.

Have you even read the article? The only reason AMP is perceived as better than anything out there is because Google aggressively preloads it. At best it's not better than anything else out there. Solutions to slow loading pages are well known and have nothing to do with AMP or "other web frameworks". Even Google themselves lay out the solutions: https://developers.google.com/speed/docs/insights/rules . Nowhere does…

The article is wrong, as no amount of preloading will make the non-amp Verge fast to load as it runs too much JS to block the initial render. You could provide a mobile framework and tools for publishers that helps sites create pages that render fast by putting them on rails. AMP is that framework, other people could similarly introduce tools to help. Chrome DevTools and Google has long offered the Page Speed tools a…

> The article is wrong

In what part is the article wrong?

> You could provide a mobile framework and tools for publishers that helps sites create pages that render fast by putting them on rails. AMP is that framework

You clearly didn't read the article. AMP is not fast. The moment you load it from anywhere else but Google's cache, it's not faster than any other webpage with a similar amount of Javascript and other code.

Even Google's own performance measuring tools say that AMP isn't fast.

> Chrome DevTools and Google has long offered the Page Speed tools and others to audit your code for slowness, but curiously, no one seems to use them or care, which is why we ended up with millions of slow ass mobile sites shoehorned with megabytes of JS.

That is really besides the point. You bemoan that "there's no mobile framework and tools for publishers that helps sites create pages that render fast"? Oh look, there are plenty of those frameworks, and there are tools like Google's own tools.

And those tools say one thing:

- AMP is not fast

- Google lies about the speed of AMP by aggressively preloading AMP pages from it's own overpowered CDN/cache

- It's entirely possible to create fast pages with existing technologies without AMP. Google has extensive documentation on how to do that (and obviously it never mentions AMP). However, Google will penalise those pages even if they are faster than AMP.

Re: AMP: the missing controversy

#128

Post by fchristant »

cromwellian wrote: post #121
fchristant wrote: post #118

Earlier quoted context omitted.

You're missing the entire point. It is fine to have a framework like AMP that puts up technical constraints leading to a performance-friendly web page. The problem is the cache and specifically the preloading of it. This gives AMP an unfair advantage of multiple seconds over anything else.

That's why Redfin ( https://redfin.engineering/how-to-fix-googles-amp-without-sl... ) pointed out that the Web Packaging spec could fix this. But before you have a general purpose spec that fixes something, you need a specific embodiment that does. asmjs came before WASM. SPDY came before HTTP/2. Flash came before HTML5. I didn't like Flash, but would you have suggested Adobe worked with browser vendors for years to…

The main objection I have to AMP is preloading, it is a demonstratable case of an unfair level playing field, that cannot be excused by any technical reason. On slow 3G, where performance matters most, it gives an advantage of several seconds.

Because of preloading, not because of AMP in itself.

This makes the whole "the web is slow" discussion irrelevant. If I would now build the fastest website in the world, it would not be preloaded, and would STILL be slower than AMP. It's a skewed playing field in which you cannot compete, whether you strip down your site or not.

Re: AMP: the missing controversy

#129

Post by dmitriid »

cromwellian wrote: post #121
fchristant wrote: post #118

Earlier quoted context omitted.

You're missing the entire point. It is fine to have a framework like AMP that puts up technical constraints leading to a performance-friendly web page. The problem is the cache and specifically the preloading of it. This gives AMP an unfair advantage of multiple seconds over anything else.

That's why Redfin ( https://redfin.engineering/how-to-fix-googles-amp-without-sl... ) pointed out that the Web Packaging spec could fix this. But before you have a general purpose spec that fixes something, you need a specific embodiment that does. asmjs came before WASM. SPDY came before HTTP/2. Flash came before HTML5. I didn't like Flash, but would you have suggested Adobe worked with browser vendors for years to…

> Web Packaging spec could fix this

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.

> But before you have a general purpose spec that fixes something, you need a specific embodiment that does

AMP isn't that spec though. It does nothing special. And the only reason it's fast is because Google aggressively preloads it.

> but the end result is that not only do end users get AMP-cached fast loading, but they also end up download far less data,

Are they though? When for every search google preloads tens of AMP sites to make them "fast"?

Re: AMP: the missing controversy

#130

Post by ec109685 »

Too wrote: post #79
ec109685 wrote: post #56

Earlier quoted context omitted.

Yes, exactly. They (Google, others) cannot instantly load arbitrary websites because those sites would have access to the google.com domain in an unsafe manner. That is why AMP is “different” than other HTML. It is a safe way to allow Google, Twitter, Bing, Yahoo Japan and others to cache pages and preload/prerender them in the background before the user clicks.

If Google had genuine interest in just speeding up page loads after search they would let the client prefetch the page (amp or not) straight from the original domain instead of their own cdn.

That would mean the third party website would get traffic without the user having clicked on a link, creating a privacy issue.
Post reply on HN