On AMP for Email(rodriguezcommaj.com)
rodriguezcommaj.com
On AMP for Email
https://www.rodriguezcommaj.com/blog/on-amp-for-email
33 comments
AMP for Email is another Googles attempt to grab more dominance by abusing their market share.
The problem with AMP is centralization. The problem with centralization is deciding who gets to talk about what subjects. Centralization provides perverse incentives to restrict this.
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.
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.
Mobile networks and smart phones have incredible performance.
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)
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)
Do you really believe that? They can't even hold a TCP connection open without running out of battery or terrible latency. And $diety forbid trying to host or use ports.
I have a device that fits in my trouser pocket that allows me to stream and watch HD video for multiple hours over a cell network while being powered by a battery roughly the volume of a matchbox.
Yes, I think that's incredible. Does it have TCP characteristics similar to an Ethernet-equipped desktop? No, probably not -- but that's got nothing to do with the characteristics that led to the creation of AMP.
Mobile networks and phones are powerful enough for video, so they're powerful enough to download and render a web page. If they're slow at web pages, it's very likely the fault of the page creator, not the network or device.
AMP is an attempt to force the hands of the page creators out there, since they apparently can't self-regulate.
Yes, I think that's incredible. Does it have TCP characteristics similar to an Ethernet-equipped desktop? No, probably not -- but that's got nothing to do with the characteristics that led to the creation of AMP.
Mobile networks and phones are powerful enough for video, so they're powerful enough to download and render a web page. If they're slow at web pages, it's very likely the fault of the page creator, not the network or device.
AMP is an attempt to force the hands of the page creators out there, since they apparently can't self-regulate.
It has everything to do with it. Mobile phones have special needs due to their lack of energy and lack of a real network connection. Sure, they can be powerful... for a dozen minutes before thermal throttling and draining the battery. Sure they can stream video like a good consumer but you can't do anything productive on them. You can't even really run a decent NoScript interactively or related due to the lack of a decent UI. So, AMP.
They're really quite shitty computers but luckily there are so many users that tech companies are figuratively bending over backward to make up for their performance problems.
They're really quite shitty computers but luckily there are so many users that tech companies are figuratively bending over backward to make up for their performance problems.
Could do that without centralization.
Enough people are coming out saying it's a terrible idea that the contrarian in me thinks is't likely to catch on now.
>Enough people are coming out saying it's a terrible idea...
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.
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.
Being able to do tasks without leaving your email client is actually great, specially on mobile. Answering Doodles, filling ticket forms etc. Users are going to love this. Should we not improve the email experience just for the sake of abstract concepts such as Web Standards? Not to mention that AMP is an open spec that could be implemented by anyone and be included in web standards.
Filling out web forms in emails sounds like a dream come true for phishing shops.
It's sad that we've gotten so jaded that you think Web Standards are abstract concepts that get in the way of improvement. Standards are what have gotten us as far as we are (in general).
P.S. WTF is a doodle?
P.S. WTF is a doodle?
You're aware that most web standards originate from proprietary tech that went crazy popular and were then standardized?
Doodle is super popular in Europe but not so in the US https://doodle.com/
Doodle is super popular in Europe but not so in the US https://doodle.com/
Re: "Amp for Email uses that language instead of HTML and CSS."
Is this correct? Looking at the example in the spec [1], it seems to be a subset of HTML.
[1] https://github.com/ampproject/amphtml/issues/13457
Is this correct? Looking at the example in the spec [1], it seems to be a subset of HTML.
[1] https://github.com/ampproject/amphtml/issues/13457
Except you have to use <amp-img> tags instead of <img>. Same for video, audio, and iframe.
https://www.ampproject.org/docs/reference/spec#html-tags
> Except you have to use <amp-img> tags instead of <img>
Those are just custom elements: https://html.spec.whatwg.org/multipage/custom-elements.html
Those are just custom elements: https://html.spec.whatwg.org/multipage/custom-elements.html
Hmm, custom elements are an interesting loophole. If you define your own set of tags and provide JavaScript implementations for them, I guess it would run in a browser, but is it really the same language anymore, and does it matter?
I'm reminded of:
I'm reminded of:
#define BEGIN {
#define END }> is it really the same language anymore
Yes?
The analogy would be more like defining custom functions or classes not in the standard library. It's just encapsulation that can then be used by name. They can't be inserted arbitrarily regardless of syntax like a macro can be.
Yes?
The analogy would be more like defining custom functions or classes not in the standard library. It's just encapsulation that can then be used by name. They can't be inserted arbitrarily regardless of syntax like a macro can be.
It is just a subset of HTML (as is amp). Most email providers that accept HTML formats already only accept a subset of HTML. This is just a different, more formally defined, subset.
I mean, HTML is just XML... these subsets are in many ways their own language.
HTML is an application of SGML / ISO8879. It defines its own domain and that's the scope of it. It's a leaf.
XML is a subset of SGML and can have further subsets and implementing applications I.e. it is a branch. As noted above, XHTML was a leaf on this branch.
So they are related but not equivalent.
XML is a subset of SGML and can have further subsets and implementing applications I.e. it is a branch. As noted above, XHTML was a leaf on this branch.
So they are related but not equivalent.
It's not, technically.
XHTML was a formally defined HTML subset of XML but it died.
Fair enough, my point stands though.
I really don’t care about amp for email. But I’m very worried about amp for the web because it means we give up control of our content and features and will need to live by googles rules.
I know what you mean, but at a certain level of abstraction, isn't that what web programming is all about? You already live by Chrome+Firefox+Safari+IE rules. I mean sure, there's a complicated political process, but it's still rules made by other people working for large organizations that the average web programmer just accepts. It's not like we all had a vote about Flash. Or JavaScript, for that matter.
There's a lot you can do while working within the rules, though.
There's a lot you can do while working within the rules, though.
Do you just not use email much then?
It's just a client-side thing then, right? I can send email to a GMail user from a non-AMP client and I can receive email from a GMail user. I don't think there are any mail system interoperability concerns, are there?
I assume sending will always work as expected (they aren't about to start demanding things be AMP formatted), but who knows what your client might render an AMP email looking like.
I don't know why people keep getting this wrong, but AMP does not introduce proprietary browser extensions or syntax. It's a custom element framework, not much different than say, React and JSX, or Vue, Ember, or tools such as LESS/SASS.
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?
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?
> AMP does not introduce proprietary browser extensions or syntax. It's a custom element framework,
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.
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.
> r authenticate the library with a durable subresource integrity (SRI) hash while still remaining valid
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.
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.