10 Misconceptions about AMP | Hacker News Reader

10 Misconceptions about AMP

paulbakaus.com

40 pointsdedalus48 comments

> #2: “AMP is a Google project”

This is not a misconception. Literally every AMP "Core Committer" is a Google employee, all contributions are subject to a Google CLA which includes a patent grant, every AMP page must include a third party script hosted by Google, and it's impossible to opt-out of Google's AMP Cache, which preferentially links to and re-hosts your content on Google's servers instead of allowing you to receive and analyze your own traffic.

AMP allows outside contribution, but it is absolutely a Google project.

Edit: This point seems especially disingenuous since the author is a Google employee in Developer Relations: https://paulbakaus.com/about/. His job role is literally "Web Advocacy lead for AMP" https://www.linkedin.com/in/paulbakaus.

Good catch. I started out by thinking you were being pedantic, but I can see that you're right. The author needs to be more transparent, and I didn't realise how much of a Google project it is. I had thought it was like Angular and Go.

Yeah, that went over the line of honest advocacy for me, too.

> the author is a Google employee in Developer Relations

Haha, wow. And I didn't even know about the caching behavior, that's ridiculous.

A good way to test the theory whether AMP is a Google Project is to submit a pull request to allow the import location of the AMP runtime to be configured.

This goes well beyond mere "advocacy" to overt dishonest propaganda. Points #2 and #7 are fairly inarguably, objectively false.

#2 AMP's primary requirement is loading a 3rd-party script from a Google-owned domain. First. In the head. It disallows local use of this script: it must come from Google. It further disallows any author-written JS so there's no way to make this Google-dependency optional for site visitors.

#7 See above on completely disallowing author-written scripts. All JS interactivity on your site must come through Google's domain.

Let's see if I got that right: Specification says I must load the AMP script from cdn.ampproject.org?

If yes, then there is no effing way that I will ever use this. I will NOT use something that forces me to load scripts from a host that I have no control over. Does nobody see what a HUGE security risk that is???

You got that right, and it's a fairly common critique of AMP.

The target group for AMP (traditional publishing sites) loads crap from all over the net in general and Google in particular anyways, so they don't care, but it leaves a very bad impression for an "open standard", yes.

Technically browsers could catch that include and replace it with local/cached logic, but I don't think that is happening or planned yet.

> Does nobody see what a HUGE security risk that is???

I dispute 'HUGE' (or even 'huge'). No more than using any CDN controlled by a large company.

1. You're welcome to say that CDNs are a risk in general but many reasonable people would disagree.

2. You're welcome to claim that Google is not to be trusted but it rather depends on your audience. If you're providing a platform for especially the especially sensitive (anything related to politics/human rights/government/medical/financial might warrant extra caution) then I'd agree but for the large majority of sites - loading javascript from Google is an acceptable trade-off.

So - I'm not disputing it's a security risk - I'm just not sure it's HUGE-in-capital-letters for most people.

Once AMP stabilizes, I'm hoping Google will encourage the use SRI to ensure that the content is what a site expects: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Still unacceptable as it would still cause my users to expose their IP address to someone else's server.

Unfortunately the ubiquity of FB and G+ buttons, Google analytics and CDN use has raised a generation of web developers who don't see that as a problem.

Certificate Transparency will reveal the domains you connect to over TLS to a Google server anyway. Assuming you don't already use Google's DNS, that is.

Google could and should change their requirement to be that the integrity value for the script must be in their approved list rather than requiring their path.

I recently started moving my static jekyll website to AMP. The biggest annoyance by far is that an AMP website requires javascript, and <img> tags are no longer valid. <amp-img> is required.

This means I now have to choose between blog posts that are valid AMP and valid (and rendering) in an atom news reader.

I sort of get why this is done on a technical level, but I prefer my HTML to follow HTML best practices. HTML will outlive AMP. Please just allow this and fix this in your AMP caching systems to automatically transform this.

That's exactly it for me as well. Several times I got prompted by articles like this to evaluate AMP, because I like the core idea – a defined subset of HTML tags for static content that can then be cached. And then I have to realize that this is not the core idea at all. Replacement of HTMl-Tags with AMP-tags, converting a static site to a site only working with javascript, javascript that can't be self-hosted – that is just an ugly and bad solution far from the claimed core idea.

How AMP should be: Define a subset of allowed HTML and best practices fit for static pages. Verify and cache the result. If doing crazy js-hacks, do that on the cache-layer as an add-on, like the image resizing.

Side project idea: a browser add-on that de-AMPs (dAMPs?) content back into standard HTML...

As extension to scripts like Noscript. Would be useful.

There's a lot of "reinventing HTML/JS" that goes on which irks me. Folks reinvent `<select>` in JS all the time. This stops type-to-search and mobile sites from working. The same goes for password fields (for password managers and "click to show" on mobile). The same goes for reimplementing scrolling in JS and text zoom. The same goes for onclick links (like twitter) and breaking ctrl-click and other linky things. The same goes for a million different features of the web and screen readers. And like you said, the same goes for img and feeds.

If you're going to reimplement something, bear in mind that it may have far more functionality than that for your primary use case.

You can create an AMP version of the page for each page and include that as the amp canonical tag on your normal pages. In that case people visiting from Google get AMP version. The normal site should still exist and it should continue to link to normal pages.

Surely it's a fairly simple technical problem to solve? Middleware or a build step in your static site generator could easily produce AMP and non-AMP-but-fast content from the same data and templates?

Why would you generate both? At what endpoints would you serve which? Which would you serve as the canonical version, and how would people reach the alternative?

If you're intending to content-negotiate for Googlebot I suspect you'll run into trouble.

AMP is designed to be served at alternative endpoints. The canonical HTML version gets a rel=amphtml header and the AMP page a rel=canonical.

https://www.ampproject.org/docs/get_started/create/prepare_f...

This I was completely unaware of. I'd read the majority of the docs, so this isn't really emphasised.

Tbh, if this had been front-and-centre when I started implementing AMP, I might have actually finished the job without balking at the hard Google dependency and abandoning the effort.

I'm still wary of it given the Google-hosting of AMPed pages accessed via SERPs, but this does make it slightly less awful I guess.

I'm more annoyed about inline CSS (which I understand is supposed to be better....but with Jekyll it gets complicated really fast to import my SCSS to CSS inline).

Did you have a look at email inliners (the premailer gem should be enough considering the AMP spec). You'll need to add a gulp or grunt task before publishing, though.

I was hoping to do it without any other gems (I'm not a Ruby dev, but I really like Jekyll because of it's support).

I followed the tutorial here[0], however, the issue is, my SCSS is stored into a seperate dir, and in order to inline it...I'd be forced to either

1. modify my entire project dir setup - something I don't want to do 2. start from scratch and create my own css inline.

Thanks to the above, my theme been stuck in limbo (AMP and Facebook Pages being a key feature I had created my theme for)

[0]http://www.kevinsweet.com/inline-scss-jekyll-github-pages

Curious, why did you want to move your site over? For small-ish sites with clean code I don't see any benefit of using AMP right now.

AMP sites get preferential treatment in Google search results: https://search.googleblog.com/2016/09/search-results-are-off...

Specifically, they're eligible for placement in the "Top Stories" header, and they get a special "️(!) AMP" flag alongside their entry in the search results.

I thought the "top stories" was only for "proper" news sites?

It would be interesting to see if the AMP marker has an effect on browsing behavior, it seems awfully technical to me.

Google gives preferential placement to AMP pages over non-AMP pages in mobile searches.

Experimentation. I use my blog to get experience with various technologies.

> Imagine you’re a tourist in Germany driving on the right lane of the Autobahn, not knowing the very left lane is a much faster option. AMP is the thing that forces you to stay on the very left lane of the Autobahn, and keeps your path ahead clear of obstacles.

Not a good idea unless you want to pay an 80€ fine: https://de.wikipedia.org/wiki/Rechtsfahrgebot

lol, fantastic catch :-D

For every one not familar with german laws: You must drive right unless you are overtaking a slower car that is in front of you. And you are only allowed to overtake on the left side of another car. So if everyone drives the left lane, there's no way of overtaking anybody - something that would drive (no pun intended) all the other drivers nuts and you start to honk like crazy (which you are not allowed actually) or to give signals with the lights (which you are also not allowed) to the car in front of you ;)

Number 8 is absurd.

> browsers and big platforms like Google Search today have no mechanism to prove that your site is indeed fast and user friendly. So by choosing to do it all on your own, you might create a super fast site, but there’s no way to know for sure. This validation aspect of AMP is what makes it so attractive for 3p platforms.

Ok, so... Google's been making a business saying your website IS or ISN'T fast enough for mobile. (I have 2 old client websites that Google yells at me weekly about 'not being mobile optimized' (thanks mom, I know). Why all of a sudden can they NOT PROVE your site is fast enough? if they've been claiming to say its fast or not fast all this time?

While I think the idea has merit, I think people are 'cooling' on AMP because it causes weirdness like the URL being hosted by google (??) and the original URL being hard to share, etc. They have to encourage browsers or publishers to find a way to go back to or share the 'canonical' URL, it doesn't seem to be happening. My understanding at this point is vague though.

(A few months ago I played around with making a WordPress plugin that hooks into the AMP plugin and redirects all mobile traffic including from FB, etc. to the AMP page. Didn't finish/release it yet though.)

> From those early beginnings it was developed hand in hand with publishers, ad vendors, technology providers and platforms besides Google such as Twitter, Linkedin and Pinterest

AMP is not pro-users -- and the above supports this. My opinion on AMP is that it is a piece in this overall goal out there to weaken the "user" part in "user agent".

I don't understand the example of design and amp. (#4) Is this some kind of a joke?

I hope in five years amp is another deprecated project of Google.

Google already knows sites loafing times. Just punish slow sites and give more to fast ones. Why reinvent the wheel? If the boss sees rankings dropping because of all of the tracking and ads, maybe they start thinking about making sites faster.

Eh, that would also heavily favor resource-rich, er, resources... Not all good content can optimize their sites or just add more servers, and a lot of bad content can afford to do that.

PWA = A Progressive Web App uses modern web capabilities to deliver an app-like user experience.

(for anyone else that didn't know.)

It's funny-

developers commenting here seem to hope it dies, feel it's terrible, think nobody actually likes it, etc.

Yet as an end user, I'm already in love with the little lightning bolt. Maybe your site is fast (is it? Is it really? Even on a crappy phone on 20kbit DSL?) but so many sites are dog slow, ten seconds or more to load on a fast connection on a fast phone.

Why flag it? I think a good way to cope with this kind of propaganda is to : 1- Change the title to something like "Google wants you to believe AMP is not a Google project" 2- Change the link to this thread. Namely : https://news.ycombinator.com/item?id=12708206

As a mobile phone end user, how do I send a link to an AMPed website to someone without it showing google.com?

It fels as though AMP is putting a wrapper on the internet. No thanks.

> Actually, no. AMP is really just that – a web components ecosystem.

Oh that's all???

AMP is the HTML the germans would have invented, if they would have invented HTML: fast, controlled, boring

p.s.: I'm austrian, it's ok-ish for us to make fun of germans.

I know German IT companies, and I can agree with "boring".

I know SAP, so I can't agree with 'fast'.

Reply on news.ycombinator.com