Hacker News Reader

Comment by cramforce | Hacker News Reader

You might get it :) There isn't that much to it. AMP is as much about technology as finally getttig that tech adopted. Since AMP is built on web tech there is nothing in it that you cannot chose to do yourself

The problem we are solving is that many sites don't.

View on HN

So what's with the approach then? Why would websites choose to use AMP (whatever "using AMP" means), when they don't apply common sense in the first place?

Forgive the skepticism but this screams XKCD927.

One of the things that AMP allows is to know that is it save to prerender a page. Documents can be instructed by a viewer to e.g. only load resources visible above the fold and absolutely no external JS.

With general web content prerendering is pretty dangerous and you certainly cannot do it with say more than 1 doc at a time because it may use arbitrary bandwidth and CPU.

That allows for instant feeling loading of pages (because they are already loaded when the user clicks) which in turn makes users happy :) While all web pages can be fast, AMP allows proving that they are which makes such a feature possible.

A referrer like Twitter or Pinterest or Google could e.g. indicate: Clicks on these links will be super fast (because they are AMP docs). If users click them more (because they like fast) there is a strong incentive for everyone to be fast – and then we all win.

I don't think XKCD927 applies, because we only combine existing standards and restrict ourselves voluntarily to a subset of those. Its still just HTML, CSS, JS. Browsers do not need to change. 't

You're not "combining" standards though. As other comments pointed out, this is not a subset of html. It's a separate spec, based on a subset of html, which is different enough that it's not quite compatible. For example, what's with the amp-prefixed tags? Why amp-img instead of img with data-amp- attributes?

You also didn't address my first point: If you're building this for people who don't make the effort right now, why would they suddenly make a seemingly bigger effort to support something they haven't even heard of before today?

I think the other comments are wrong. Custom elements are a part of the web platform http://www.w3.org/TR/custom-elements/

We use amp-img instead of the img tag to be able to control when resources load (read not load them unless actually needed). Doing this with a different hack like <img data-src="foo"> is possible but a less explicit hack.

To your first point: It might have been just the right point in time, but maybe it isn't. I argue that if adoption is good users will win. It could totally fail, but then it was still worth trying.

In case you haven't tried, check out this video https://www.youtube.com/watch?v=i2_lAEzmOPo&feature=youtu.be I so much want my experience to be like that (or try g.co/ampdemo on your phone yourself).

Good demo. The benefits are indeed attractive, but you still have not sold me on why this is a better approach than ... well, everything that's been suggested in this thread. This stuff is possible without what you're proposing, as you yourself admit. What I see amp giving is a framework in which it is impossible to "mess up", which can be beneficial but I agree with the general sentiment here: New tech has a cost to it. Learning it has a cost. Implementing it in browsers has a massive cost (because I'm sure this will eventually find its way in Chrome, which means Firefox will follow suit, which means a larger potential for technical debt and a higher bar to developing a web browser from scratch).

Like someone else said: If Google wants performance, Google can start aggressively penalizing article-type websites which make unnecessary requests etc. I know you guys already penalize slow sites, so what's wrong with that approach? Especially since such an approach has a much higher chance of actually working.

I totally agree that the "penalizing" approach is important.

But I like to present both a solution "this is how you make it fast" as well as the penalty.

If you only take AMP as a guide or tutorial that puts current best practices in a neat package that is fine with me. We are totally not claiming to have invented a new wheel.

Browsers could do what AMP does (e.g. super lazy prerendering) but I'm an impatient person and I don't like waiting for what a browser with a yearly release cycle might do.

The custom-elements document you linked to is a W3C Working Draft, not a Recommendation. It might someday be part of the Web platform (w.r.t. standardization), but for now it's just under discussion.

It has an implementation in Chrome and Firefox and both Microsoft Edge and the WebKit teams have indicated that they will support it. On top of that there are 2 super excellent polyfills.

In the world of the web platform it doesn't get much more standard than that.

> One of the things that AMP allows is to know that is it save to prerender a page. Documents can be instructed by a viewer to e.g. only load resources visible above the fold and absolutely no external JS.

Which begs the questions: Who prerenders and on what criteria?

Assume page A which has a link to AMP-forked page B.

Does that link need rel=prerender for every browser? Does one need to query the AMP-ness of every page one links to? Does one need to be Googles page cache to link to AMP-pages and get in the benefit of prerendering?

Or is the prerendering implemented in the AMP runtime? Does it only work if page A and page B are both AMP-enhanced?

Reply on news.ycombinator.com