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

AMP for email is bad

tutanota.com

Post reply on HN
Print view View original

61–70 of 161 posts

Re: AMP for email is bad

#61

Post by joshuamorton »

SquareWheel wrote: post #33
detaro wrote: post #27

Earlier quoted context omitted.

> Listen -- AMP is merely a set of guidelines and a framework to help developers make media-rich web content load fast. You can obviously achieve the same results without AMP, just like you can write a SPA without a framework. Duh. Basically all criticism of AMP is about the fact that this is not true. If Google said "we prioritize fast pages, here's some guidelines and code on how to do that", that'd be fine. But th…

>don't want to show 8 seconds of empty page to users without JS That's incorrect. AMP pages support noscript.

Specifically, if you disable JavaScript entirely, they load cleanly (via the no script tag).

If you block just the amp js endpoint, they have a fallback for slow confections that waits a few seconds before rendering to avoid page redraws. This is the 8-second thing.

Re: AMP for email is bad

#62

Post by andreareina »

jchw wrote: post #48

Every thread about AMP on Hacker News goes exactly the same way. It’s annoying, repetitive. But here’s the thing: while I get criticisms about AMP for web, pretty much none of them apply to AMP for email. The author of this article keeps bringing up points about AMP for web as if they have anything to do with AMP for email. AMP for email basically does one thing: it enables interactive emails without allowing arbitra…

So now email clients need to implement a javascript engine as well as an html engine? For what benefit to users? At what cost to users?

AMP for email solves a nonexistent problem.

Re: AMP for email is bad

#63

Post by joshuamorton »

nullandvoid wrote: post #60
lern_too_spel wrote: post #8

Earlier quoted context omitted.

> When you use google search with javascript enabled AMP results are both prioritized in the listing and pre-loaded in the background. Or Bing search or Baidu search or Yahoo! Japan search and so on. The whole point of AMP is that it can be safely preloaded and prerendered, making it faster than any other web page you can create for people coming from a link aggregator. One of the big advantages it has over Facebook…

Why does it make sense for Google to control this prefetch mechanism rather than just using a browser built in with prefetch type setup

In what way does google control this prefetch mechanism?

If you mean why does the cache (of which there are 3: google, cloudflare, and Microsoft/Bing) get to control the preloading, the amp limited set of html can be safely cached in it's entirety.

So when I visit a search engine and an amp page is preloaded, it doesn't communicate with that domain.

This ensures that cross domain preloading is possible without leaking my information to any third parties (where third parties in this case is "random sites on the first page of Google").

If link preload was used, any time you made a search, it'd be equivalent to opening all the results on the page, from a tracking perspective. That's pretty awful from the point of view of privacy.

Re: AMP for email is bad

#64

Post by captn3m0 »

radarsat1 wrote: post #36

I really wish the email standard was markdown instead of HTML. I only ever switch from text-only when I need to embed an image, and otherwise occasionally italics or whatever is useful. This could be taken care of with a basic markdown-like language, and avoid getting full HTML advertisements, etc. I really, really don't need your newsletter to be properly formatted in my mailbox, just send a link, I'll open it in th…

If Google really wanted to make the web fast, they would add native support for text/markdown mimetype in Chrome and ask publishers to just create .md files instead.

Re: AMP for email is bad

#65

Post by callahad »

SquareWheel wrote: post #55
callahad wrote: post #52

Earlier quoted context omitted.

It is impossible to use AMP as a standalone Custom Element library and still validate as AMP. Valid AMP is required to dynamically load the library from Google's unversioned CDN.

That's true. But it's still valid HTML. It's most definitely not a fork of anything. > unversioned CDN Isn't the filename versioned (v0.js)?

Not really. The project leaders have explicitly stated that the content of the script at that URL is subject to change at any time, and thus users are prohibited from locking it to an audited, known version with an SRI hash.

Re: AMP for email is bad

#66

Post by SquareWheel »

callahad wrote: post #65
SquareWheel wrote: post #55

Earlier quoted context omitted.

That's true. But it's still valid HTML. It's most definitely not a fork of anything. > unversioned CDN Isn't the filename versioned (v0.js)?

Not really. The project leaders have explicitly stated that the content of the script at that URL is subject to change at any time, and thus users are prohibited from locking it to an audited, known version with an SRI hash.

I see. Thanks for the clarification. That is pretty poor practice.

I guess v0 might imply "beta" and thus not have stable API naming yet. But still, it's clearly being used in production at this point.

Re: AMP for email is bad

#67

Post by social_quotient »

swixm wrote: post #46
seieste wrote: post #30

Earlier quoted context omitted.

AMP is slower for me because I have to press on my screen twice to get to the actual page I wanted to go to. Hence AMP requires at least 0.5s between the time I click on a Google link and get to my real destination?

Refusing to read the information you were looking for just because it is in an AMP page makes it look like you're following the "antigoogle" NetHack conduct.

It’s easy to forget that the web isn’t just read only.

I fear the reductionist mindset that made AMP, and your comment, a primary forced tech in the first place.

If google really wanted a faster internet they would put a proper incentive model in place for it and not add this layer of abstraction. Curious what I mean here? For each extra 500ms penalize the page by +page in the results. What would this do? Overnight agencies and marketers would cease to create huge bulky platforms/sites/pages with sloppy plugins. We would be forced to really consider speed a function of UX. In addition to this a lot of the junk trackers like adroll would be gone or innovated to be faster.

Re: AMP for email is bad

#68

Post by ocdtrekkie »

joshuamorton wrote: post #59
ocdtrekkie wrote: post #41

Earlier quoted context omitted.

I think theoretically you can use AMP email through an IMAP client, if that IMAP client supports AMP. But support for it is probably going to be pretty scarce, particularly in the open source world.

You're correct. There's nothing about amp4email that requires a Gmail account. I'm actually pretty sure that if you use an imap client it whatever, you could view amp email from some site without ever communicating with a third party.

It would still need to talk to your email provider's AMP cache, presumably, though, unlike a normal email which you download once and then do not need to reach out to the server for again.

Re: AMP for email is bad

#69

Post by ocdtrekkie »

SquareWheel wrote: post #47
ocdtrekkie wrote: post #39

Earlier quoted context omitted.

amp4email is far worse and more dangerous than amp4web, and that's why privacy respecting email services are so opposed to it. Tutanota here, and FastMail who posted about it when it was first announced. AMP isn't a subset of HTML, it's it's own proprietary fork of HTML. It's not saying an img tag is okay, it's tell you to use an amp-img tag.

> AMP isn't a subset of HTML, it's it's own proprietary fork of HTML. This is another misunderstanding. HTML allows custom tags. This is built into the spec. AMP is plain and regular, standards-compliant HTML.

I think you are misunderstanding my point.

An img tag doesn't work on an AMP page. It has to be an amp-img. Every standard HTML tag is invalid in AMP content, as you must use a customized AMP flavor of HTML.

Whether or not it returns valid as HTML markup isn't really relevant: The point is it's an entirely different, incompatible, markup, from what a normal browser knows how to interpret and use, and if your browser doesn't have JavaScript, it's not even going to know what any of those custom tags are, is it?

Re: AMP for email is bad

#70

Post by [deleted] »

jchw wrote: post #48

Every thread about AMP on Hacker News goes exactly the same way. It’s annoying, repetitive. But here’s the thing: while I get criticisms about AMP for web, pretty much none of them apply to AMP for email. The author of this article keeps bringing up points about AMP for web as if they have anything to do with AMP for email. AMP for email basically does one thing: it enables interactive emails without allowing arbitra…

[deleted]
Post reply on HN