
On AMP for Email - rodriguezcommaj
https://www.rodriguezcommaj.com/blog/on-amp-for-email
======
eveningcoffee
AMP for Email is another Googles attempt to grab more dominance by abusing
their market share.

------
superkuh
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.

~~~
bonaldi
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)

~~~
superkuh
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.

~~~
bonaldi
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.

~~~
superkuh
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.

------
aidenn0
Enough people are coming out saying it's a terrible idea that the contrarian
in me thinks is't likely to catch on now.

~~~
patrickaljord
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.

~~~
nixpulvis
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?

~~~
patrickaljord
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/](https://doodle.com/)

------
skybrian
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](https://github.com/ampproject/amphtml/issues/13457)

~~~
iza
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](https://www.ampproject.org/docs/reference/spec#html-tags)

~~~
magicalist
> _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](https://html.spec.whatwg.org/multipage/custom-elements.html)

~~~
skybrian
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:

    
    
      #define BEGIN {
      #define END }

~~~
magicalist
> _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.

------
ronnier
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.

~~~
nixpulvis
Do you just not use email much then?

~~~
criddell
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?

~~~
nixpulvis
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.

------
cromwellian
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?

~~~
callahad
> _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](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/534)

[https://github.com/ampproject/amphtml/issues/5846](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.

~~~
cromwellian
> 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.

