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

81–90 of 143 posts

Re: AMP: the missing controversy

#81

Post by Too »

hdra wrote: post #60

Only thing I can't figure out is why is anyone buying into it in the first place? Has the publishers not learned anything from Facebook taking their content and readers hostage? Sure, it gives you traffic boost in the beginning, but sooner or later it will force you to play by their rules and generate content for them .

It's funny because publishers are otherwise quick to sue Google for their other aggregator and caching features such as Google news and recently the "view image" removal. But with amp they happily bend over.

Re: AMP: the missing controversy

#82

Post by Sylos »

kllrnohj wrote: post #49
ddmd1 wrote: post #11

Google can't "simply preload resources of non-AMP pages". Using a CDN means they can get more consistent load times and avoid the inevitable privacy concerns that come with loading 3rd party content the user may never actually click on.

Chrome has been prefetching & prerendering links since 2013. IE11 has also been prefetching & prerendering as well since 2013 ( https://blogs.msdn.microsoft.com/ie/2013/12/04/getting-to-th... ) So it's not only possible to do, they've literally been doing it for 5 years now. Firefox doesn't appear to do prerendering, but it will happily prefetch as well and has since Firefox 23. AMP's cap on file sizes and other limi…

> Firefox doesn't appear to do prerendering, but it will happily prefetch as well and has since Firefox 23.

Don't know, if it's necessarily "happily" in the case of Firefox. It's hardly optional, if you want to compete at all in terms of speed with browsers that are doing the full prerendering. And they are aware of the implications, which is why they're not doing it fully.

Re: AMP: the missing controversy

#83

Post by cromwellian »

Sylos wrote: post #80
akras14 wrote: post #76

Cache is part of AMP spec. What author seems to refer to is only a 2/3 of AMP spec - Subset of HTML and JS library. Since the beginning AMP team was clear that AMP is not very useful without cache. I do agree with all of the concerns raised, but wanted to point this out as to not get sidestepped from the main discussion. https://www.alexkras.com/i-had-lunch-with-google-amp-team/ https://www.ampproject.org/learn/overv…

> Since the beginning AMP team was clear that AMP is not very useful without cache. I don't see that at all. Even just calling it a "specification" is misleading in the worst ways. You don't need a spec for caching. Nor do you need a spec to tell you that you shouldn't include a ton of CSS and JS. Nor was it ever the plan of Google to actually see others implement this spec.

Actually, the IETF would often issue BCPs to go along with RFCs, because people do need to be told the right way to deploy things in the presence of foot-guns.

Re: AMP: the missing controversy

#84

Post by cromwellian »

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…

The real problem is, no one has proposed an alternative solution that solves the same problems. Either people claim it's not a problem (slow loading mobile sites driving people away from the web and onto mobile), or people claim it'll just fix itself because everywhere will just make fast pages if they're incentivized to (penalized SEO, users leaving their sites to use Facebook/Apple News) But that has been tried, and it didn't work, and you had people desperately blocking all JS, or going to native apps.

My suggestion is, if you don't want people to use AMP, provide an alternative Web framework that provides similar performance, show in a side-to-side demo you can meet the same performance, take it to the W3C or IETF getting Mozilla to push it. No one on a crappy 3g connection really cares about the nuances of the politics here, they don't care bout Web vs native, they care only that their phone seems slow as molasses.

If there is no Web solution, then you're going to see native apps with proprietary formats, in essence, non-standard RSS readers. And honestly, I really don't want to download the WashingtonPost, NYT, or Verge App to read articles less painfully.

AMP is just JS using the Web Components spec, and some tools, the purveyors of JS frameworks like Vue, Ember, or various Bootstrap-like templates, could ship their own competing proposal.

The way standards used to work on the internet is rough consensus and running code. People would propose multiple specs and implement them, working groups would evaluate the various solutions, and the best proposals would be folded in. Provide some competition for AMP and maybe there will be a different outcome. Google shipped NaCL in Chrome, and Asm.js defeated it. Google shipped SPDY, and it won and became HTTP/2.

Less talk and politics, more shipping code.

Re: AMP: the missing controversy

#85

Post by kuschku »

lern_too_spel wrote: post #75
quanticle wrote: post #72

Earlier quoted context omitted.

That attitude is what allowed Internet Explorer to become the dominant browser. What are you going to do when Google gets bored of supporting Chrome and disbands the team, leaving your web pages tied to a stagnating browser?

> What are you going to do when Google gets bored of supporting Chrome and disbands the team, leaving your web pages tied to a stagnating browser? The whole point is that AMP works on all major browsers as they exist today. Waiting for a new standard and then waiting for Apple to implement it is a non-starter.

Sure, just like Google Earth works on any browser, or Hangouts, or ...

Google's always only supporting competing software just as much as absolutely necessary

Re: AMP: the missing controversy

#86

Post by sseth »

AMP is one of a long series of Google's efforts to ensure the web remains competitive with walled gardens and native platforms. Chrome (with the V8 engine), NaCl, SPDY, QUIC, PWA, Dart, Certificate Transparency ... the list goes on and on. Some have succeeded (SPDY became HTTP/2) and some have failed (Dart, NaCl), but it has been consistent at least.

Standards cannot become a strait-jacket. In many cases (such as HTTP/2) the standards have come much after the concept was proven. Though Dart and NaCl failed, they triggered improvements in Javascript and also led to WebAssembly.

AMP was created as a response to Facebook's Instant Articles. If anyone supports the open web, then it is hard to see how things become better if the web stays stuck as more content moves into walled gardens, or the web remains unusable on mobile phones in large parts of the world.

Maybe there is no controversy, because there is no need for one.

Re: AMP: the missing controversy

#87

Post by maxyme »

akras14 wrote: post #76

Cache is part of AMP spec. What author seems to refer to is only a 2/3 of AMP spec - Subset of HTML and JS library. Since the beginning AMP team was clear that AMP is not very useful without cache. I do agree with all of the concerns raised, but wanted to point this out as to not get sidestepped from the main discussion. https://www.alexkras.com/i-had-lunch-with-google-amp-team/ https://www.ampproject.org/learn/overv…

But a important point is that you don't get to pick the cache. The website linking to the AMP resource chooses and currently that will always be Google.

Re: AMP: the missing controversy

#88

Post by lozenge »

dragonwriter wrote: post #54
tankenmate wrote: post #42

Earlier quoted context omitted.

HTTP/2 servers can preload (if they choose).

Doesn't that require same origin, and thus AMP-style central caching?

Google is pushing "HTTP origin signed responses" which will mean Google or any other implementing server can cache responses from other (willing) origins and push or offer them. Then, the address bar can show the actual origin, instead of www.google.com/amp as the origin.

Re: AMP: the missing controversy

#89

Post by ino »

kzrdude wrote: post #22

Side note, install this extension to make medium pages readable by removing the useless top and bottom bars: https://github.com/thebaer/MMRA

Better yet, use reader mode in firefox/safari. Or stop visiting medium until they stop these user hostile practices.

Re: AMP: the missing controversy

#90

Post by spc476 »

IlPeach wrote: post #47
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…

I don't even think AMP is the problem. It feels more like an symptom. So the question really goes as: what's the actual problem? To keep it very short, it really does feel like to be around how the ad revenue works on the web. But maybe I'm just mistaken and I'm missing some pieces of the puzzle.

I think the problem is Google. Between Page Rank, QUIC, HTTP/2.0 and AMP, Google is pretty much now dictating the terms of the Internet.

For instance, how much longer before Google only accepts email from the "Big Players?" (or drastically lowers the performance/acceptance of email from smaller sites?)

Post reply on HN