Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On AMP for Email

rodriguezcommaj.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: On AMP for Email

#11

Post by EpicEng »

aidenn0 wrote: post #6

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.

Re: On AMP for Email

#12

Post by magicalist »

iza wrote: post #8
skybrian wrote: post #2

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

Except you have to use tags instead of . Same for video, audio, and iframe. https://www.ampproject.org/docs/reference/spec#html-tags

> Except you have to use tags instead of

Those are just custom elements: https://html.spec.whatwg.org/multipage/custom-elements.html

Re: On AMP for Email

#13

Post by marbletiles »

superkuh wrote: post #9

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 performanc…

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)

Re: On AMP for Email

#14

Post by nixpulvis »

patrickaljord wrote: post #7
aidenn0 wrote: post #6

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

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.

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?

Re: On AMP for Email

#15

Post by nixpulvis »

ronnier wrote: post #4

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.

Do you just not use email much then?

Re: On AMP for Email

#16

Post by nixpulvis »

EpicEng wrote: post #11
aidenn0 wrote: post #6

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.

Luckily, sometimes views of fellow developers do in fact move the needle. Though I'm not holding my breath sadly.

Re: On AMP for Email

#17

Post by regularhackerer »

marbletiles wrote: post #13
superkuh wrote: post #9

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 performanc…

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)

Could do that without centralization.

Re: On AMP for Email

#18

Post by nixpulvis »

gregable wrote: post #5
skybrian wrote: post #2

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

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.

Re: On AMP for Email

#19

Post by criddell »

nixpulvis wrote: post #15
ronnier wrote: post #4

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.

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?

Re: On AMP for Email

#20

Post by nixpulvis »

criddell wrote: post #19
nixpulvis wrote: post #15

Earlier quoted context omitted.

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.
Post reply on HN