131–140 of 161 posts
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…
Email does have an expectation of durable persistence; in fact I would argue that that is a critical feature of email - If you send me an email I can always return to my email inbox and if I open the email I will always see the exact same message. I do not want that to change, in fact, as soon as I know that can change, it undermines the trust of the entire channel.
Will Amazon send me an order reciept, then subtly change the delivery date because it loads via Javascript? Wow, I could have sworn they promised it would arrive on Friday, now it's next week? What else could they change in my order as well? If I want an immutable copy do I now have to go back to paper printouts?
Even worse, what if I got an email using interactive features from a website that no longer supports those resources? Am I going to open my inbox and get a 404 because it's dynamically loading content that now isn't there? I have a reasonable expectation that when I open an email today, I can return to my inbox and see exactly the same content next week, next month and five years from now without having to question my own sanity. If I need to look at an order confirmation from a website that now doesn't exist because they didn't get their funding am I SOL because the CDN serving the dynamic email content is gone?
This is why I oppose AMP. This is a serious, legit criticism and I'd like Google to address it head on. User's don't want emails to become ephemeral, ever changing media because they want to feel their inbox belongs to them. As soon as it feels like they're visiting a site that belongs to someone else, it's not their inbox, instead it's just a bunch of bookmarks to changing, volatile resources that someone else has put into their face. It feels like an invasion, and it is.
Earlier quoted context omitted.
> Ever been forwarded one of these corporate-type emails where people reply all over the place, each using their own convention of color and typesetting and emphasis markers, with bits of "rich text" signatures and images littered throughout? That's a bloody terrible experience. https://www.prettyfwd.com Created to fix that exact issue.
Which is Gmail-only and therefore Google-only. I wouldn't want very sensitive corporate data hosted by Google, so this is a red flag for my use-case.
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…
"... I actually tend to use DuckDuckGo anyways." "... I don't even like AMP." Any idea how many Google employees use DuckDuckGo? Is it really common, e.g., maybe due to sheer size of the workforce, for Google staff to dislike what their employer is producing and releasing on the internet?
I think maybe it's that when you work at a huge massive company, you stop feeling like you have to "help the company" all the time. The company is big enough.
Earlier quoted context omitted.
> pretty much none of them apply to AMP for email It seems they do, though. Both amp4web and amp4mail are attempts at taking old, established, and perfectly good elements of the Internet, and turning them into something that serves the interests of the adtech industry, at the expense of users. > it enables interactive emails without allowing arbitrary code It also conveniently enables extra advertising and tracking,…
Email tracking in AMP is, as far as I know, roughly identical to without AMP. To quote the official AMP documentation: https://amp.dev/documentation/guides-and-tutorials/learn/ema... >AMPHTML allows tracking email opens with pixel tracking techniques, same as regular HTML emails. Any user-initiated requests for data from external services will also indicate the user is interacting with the message. Email clients may…
> The request is always made from the client, even if the document was served from the AMP Cache.
My naive reading of `amp-list` is that it's a tracking pixel that basically can't be blocked if you have AMP enabled and expect your emails to render reliably.
I suppose you could disable `amp-list`, the same way you could disable AMP in general. But it's trivial for me to make an email that won't render if the request fails. So you'll either accept my "tracking pixel" or you'll be okay with (effectively) not using AMP.
Am I'm missing something? I didn't see anything to this effect, but I guess Google could require fallback data to be coded into the email if the request fails?
[0]: https://amp.dev/documentation/components/amp-list?format=ema...
Earlier quoted context omitted.
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.
>So now email clients need to implement a javascript engine as well as an html engine? Webmail can do JS. Clients using full HTML engines like MSHTML, Gecko or Webkit shouldn't have an issue either. Text-based clients are the obvious exception, and they should still be rendering the same plaintext mail they've always been rendering. Clients can also not implement AMP for e-mail, which I imagine is going to be the cas…
Earlier quoted context omitted.
> AMP does not actually make loading any faster Every AMP link i click on google loads crazy fast. I don't know why the implementation details or google's incentivizing it would make this not count for some reason. I don't like what amp is doing to the web either but the user experience is really good, pages do load much quicker than your average page and I find myself preferring them a lot over the uncertainty and f…
Less JavaScript bloat, I think. AMP is mostly static content. Plain HTML and one CSS file (read: one, not five, not ten CSS files) minus the JavaScript bloat would also load insanely fast. It doesn't have to be AMP. Try the basic HTML verson of Gmail -- it loads about 5-10X faster than the AJAX version.
Earlier quoted context omitted.
Unfortunately I think you're being a little too optimistic. The reality I've seen is that GET is used for all sorts of things, including state changes and irreversible consequences. Analytics could check for useragent (and probably already does), but it just introduces a lot of noise. Plus the other concern is that it'd be a huge privacy issue to have analytics being triggered just by performing related searches.
So what’s your take on Chrome and Safari link preload which are in use by the millions at this exact moment?
Preload within a domain is reasonable. Preload across domains is, imo, a security concern, but maybe acceptable if the domains are trusted. Preloading untrusted, unknown content is a terrible idea.
Earlier quoted context omitted.
AMP can be preloaded because it's designed to be preloaded. Regular HTML pages have side effects that can't be accounted for. lern_too_spel is right. That is literally what AMP was built for. Let's watch as HN downvotes the correction while upvoting the misinformation in the top-comment. edit: Downvote and flag. Very disappointing.
Your comment was correctly flagged for breaking the site guidelines. Downvote-baiting is equal parts tedious and supercilious, and is off topic here. https://news.ycombinator.com/newsguidelines.html
Thanks for your comment. I wasn't trying to bait any downvotes though. I have no desire to be downvoted. I was frustrating that another user was being incorrectly downvoted and ganged up on simply for explaining how something worked, and I was trying to defend them.
I tried editing the comment before I went to bed to soften it but HN would not allow me to do so. If that were possible, I don't think we'd be having this chat.
Other users in this thread have similarly been flagged simply for explaining how AMP works. I'd ask that you review the other flagged comments in this thread to review if they were done in respect to the site guidelines as well.
Thank you.
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…
I don't object to some scripting, I object to emails that can change their contents between views.