That email operates as a significantly decentralized, federated set of privately run servers cuts the gordian knot of having to decide what is allowed.
AMP is a step backwards for everyone in order to make up for the terrible performance of mobile networks and smart phones.
AMP is about making up for the race-to-the-bottom behaviour of sites that can’t resist using 6mb and a boatful of JS just to render an article(+analytics+ads)
In the tech sphere, posting on blogs linked to by sites like HN. The fact is that 99% of gmails users will never see the push back and have no clue what AMP is. Unless the actual experience is just terrible, most users will be probably enjoy the added functionality without thinking about the concerns we have.
P.S. WTF is a doodle?
Is this correct? Looking at the example in the spec [1], it seems to be a subset of HTML.
Those are just custom elements: https://html.spec.whatwg.org/multipage/custom-elements.html
There's a lot you can do while working within the rules, though.
In fact, its even more 'webby' than those because at least some browsers don't need polyfills for Web Components, and the declarative nature is more transparent than a virtual dom app with embedded data. Web Components was created so that browsers could use custom elements, like say <pay-with-bitcoin-button/> or <x-video codec="daala" src="foo.daala"/> AMPHTML is an implementation of that.
Everyday like clockwork, new frameworks appear on HN that introduce yet another way to create web content that eschews the vanilla approach, AMP is about as close to vanilla as you can get.
There's a separate issue if your concern is Google SERP giving preference to AMP or the way it is being rendered in a carousel, but that's a political argument around the deployment, it's not a technical argument against having a simple subset that unsophisticated developers can use to create fast loading apps, like Twitter bootstrap helped many devs create proper HTML5 content.
Otherwise common inaccurate statements are that AMP Cache is Google-only, when in fact, it's a spec others can implement, and CloudFlare already provides a competing implementation.
I get why people have legitimate gripes over AMP: URL/bookmarking/canonical linking behavior, scrolling behavior on Safari, the way its rendered in Google.com, perceptions that if you create a fast site that is AMP-like, but doesn't use AMP, you don't know how it's going to be scored, etc. I think those are all legitimate concerns, but the hyperbole over the syntax seems very misplaced: AMP isn't Flash or ActiveX, it runs on open web browsers without modification on top of standard specs.
Over and over again, people say "but you don't need AMP, you can make fast mobile sites by hand!" That's like saying "You don't need Web frameworks, you can make great apps with VanillaJS and HTML", the only problem is, history has shown that most web developers can't, and absent some framework codifying good behaviors, badness accumulates overtime until things get so bad that users turn away from the web altogether to native apps. You'll find years later complaining about how Apple News killed the mobile web and why you're forced to get your content approved by gated native News apps, because of overly optimistic beliefs that the wild wild west of news publisher web jockeys would all create optimal, consistent mobile browser experiences without assistance or any industry effort to standardize some best practices.
BTW, we've been down this road before. Remember XHTML Mobile?
That's not exactly true.
AMP is a proprietary Google product: All valid AMP pages must source remote resources from Google, and all 17 members of AMP's core team are employed by Google.
Specifically, the fact that valid AMP pages must load the framework from https://cdn.ampproject.org/v0.js creates a hard runtime dependency on Google servers. Developers are not allowed to self-host, fork, use an older version, or authenticate the library with a durable subresource integrity (SRI) hash while still remaining valid.
Meanwhile, AMP's governance ensures that Google maintains exclusive control as the sole arbiter of what is and is not AMP.
https://github.com/ampproject/amphtml/issues/534
https://github.com/ampproject/amphtml/issues/5846
> There's a separate issue if your concern is Google SERP giving preference to AMP [...] but that's a political argument
It's unreasonable to dismiss the relationship between AMP and Google Search as a mere "political argument."
Google owns AMP, and Google uses Search as a cudgel to force its adoption. Every product manager I spoke with at AMP Conf last year implemented it solely for the special treatment in Google Search.
AMP's (legitimate!) technical merit is not what's driving its growth.
> Otherwise common inaccurate statements are that AMP Cache is Google-only, when in fact, it's a spec others can implement
I don't think you quite understand the concerns people have regarding Google's AMP Cache.
The issue isn't about the existence of other caches, it's about how Google Search only serves AMP documents from its own cache, and sites cannot opt out of that cache while still remaining valid AMP documents.
Concretely: If I published AMP documents, traffic from Google Search would not hit my server directly, nor would it hit any other AMP cache.
> perceptions that if you create a fast site that is AMP-like, but doesn't use AMP, you don't know how it's going to be scored
That's not the complaint. People are concerned about the most prominent, eye-catching, and valuable placement on SERPs being reserved solely for AMP documents. No matter how high my non-AMP document ranks, it'll never have the rich presentation afforded to AMP documents.
According to the discussion, there's concern this creates large scale hard to fix security issues. The alternative is to build something like AMP into browsers themselves, and then the normal Chrome/Safari/Edge/Firefox release process could fix issues.
But in lieu of that, what's your suggestion? Wait years for standards committees to hash out something at the W3C so that browser vendors implement it, all the while users suffer and Facebook Instant Articles or Apple News soak up more and more web traffic into native, or, ship something that creates an unpatchable security flaw across the web without millions of pages being updated?
If not AMP, then what? XHTML Mobile? We've been down that route and it didn't work. Bring back RSS and force mobile publishing to just be RSS summaries for fast loading?
Lost in all of this geek fighting is the fact that there's a billion users out there who don't care about the Web vs Native, they only care that shit's slow as hell and their data plan is expensive, and despite all of this, there was apparently no forcing function enticing publishers to make their pages load faster, if anything, right before AMP, it seems each and every "redesign" of top level mobile sites got SLOWER and loaded even more JS.
I don't really care about AMP, I care about the Web and I hate closed App Stores soaking up content and making it DRM'ed. In my view, we were on a path to the web collapsing under it's own weight, and AMP is a much needed band aid.
If someone can produce a competing framework that does the same thing, can be easily and wildly adopted, and solves all of the problems people are complaining about, I'd wholeheartedly support it in lieu of AMP.
But what I don't want to see is more and more of my content forcing me to download stuff from the App Store, or run inside Facebook only. That's a far far worse situation than what we're in now.
