12 ms·
AMP and why emails are not (and should never be) interactive
- Spivak 1y agoI'm gonna take the other end of the luddite argument— this is cool as hell and they should lean into it more. Discord has proven that an app platform hiding underneath IRC is hugely popular. Email with the power of discord integrations and bots would get me to up drop gmail immediately.
- AlexandrB 1y agoIt could be cool as hell if it would be used for any purpose other than sending marketing communication. But, unfortunately, we live in this world.
- bayindirh 1y agoNo, thank you. E-Mail is designed to be an analog to, well, analog mail. I expect to open the same e-mail 5 years later and see it intact, in meaning sense. For interactivity, we have web pages, and they seem to work fine. This doesn't compare with Discord, because Discord is meant to be a "chat" platform for ephemeral issues to begin with (yet it's abused as a permanent platform), and AMP for e-mail is abusing a platform designed for permanence for temporary communications. That's a bad idea(TM).
- goku12 1y agoThe use case you described is genuine. But the problem I see here is the insistence that the email platform should fulfill those requirements instead of creating a new platform and letting it win the market on its own merit. People have certain expectations from emails, which have remained largely unchanged since the emergence of the internet. Those include a federated and fully open platform, immutability of messages that make it valuable as communication records, privacy afforded by plaintext, simplicity of use, etc. Many changes have already ruined some of those qualities of emails. For example, introduction of HTML in emails have converted emails from a messaging platform to an ad and tracking platform, forcing many clients to block dynamically loaded resources. Quoting of prior messages have become a complete mess. But worst of all, the email platform is arguably no longer fully federated, now that it's nearly impossible to self host email servers. It wouldn't be a stretch to argue that changes like these are intended more to centralize the email network than to add features to it. AMP is a clear aggression in that step. It's telling that neither AMP for web, nor AMP for email survived once Google was forced to stop pushing the so aggressively. Makes you question who wanted it so badly and why.
- surajrmal 1y agoThe chance of another distributed platform with the properties desired seems small. Why should email be resistant to any change? Takes like this is why every company develops their platforms as silos rather than open standards. To avoid the inability to ever make a change once it becomes popular. Instead, at best, we end up with large monocultures around an open source project such as Linux or chromium. Maybe that's better and email like platforms are a mistake, but fundamentally I don't feel like that should be true.
- trollbridge 1y agoSuch an "interactive" use would need to keep the basic structure of email; for example, a bot you can email and it talks back to you. (Such things have been tried before, but never really caught on.) If Discord had the same spam or mass marketing problems that email and postal mail have, nobody would willingly use Discord. As it stands, the primary purpose of email is to get authentication codes emailed to you so you can login to other things.
- Spivak 1y agoThis to me is the strongest argument in favor full evolving email into something else. It's damn near pointless, nobody needs digital letters and just like our IRL mailboxes they have become our distal trash bins. I would love to email to work up the stack and lose it's unstructured nature for most use cases. People use email for 2FA codes and such, why not go the whole way and let email and Google Authenticator be the same thing.
- Kwpolska 1y agoDiscord is not built on IRC. It's a completely custom, proprietary thing. "Servers" are not separate machines, as they are in IRC land, they're just groups of channels.
- tacker2000 1y agoDiscord is the worst platform of all. All content is hidden for outsiders, non-indexable by search engines, its the prime example of non-open siloed knowledge. To this day I will not use a project if it heavily relies on discord. All of the content could be gone at once, at the whims of one company.
- Spivak 1y agoThese are all complaints about Discord the chat platform, not Discord the extremely successful blending of text based messaging and rich UI interactions.
- room271 1y agoWhile I agree with this article's conclusion, I think it conflates political/market objections to AMP (i.e. abuse of monopoly power) with technical concerns. For a time, I tech-led the creation of the AMP site for a major news publisher. The technical choices of AMP, excluding the CDN-aspect, are I think a great fit for publishing websites with tens-hundreds of developers who are all tempted to write bespoke JS and in so doing create performance and maintenance hell. In many respects, philosophically, I think AMP was not far of HTMX. In AMP, developers are able to construct relatively sophisticated dynamic/interactive features using simple markup (and pre-built JS components). The page is managed through a single JS runtime which helps manage performance issues. As components have a standard HTML interface, it is possible to migrate the backend to different rendering technologies partially over time unlike (for example), isomorphic JS which forces a large-scale rewrite down the line. I tried to advocate for an in-house AMP-like solution for our main website, but it was ultimately re-written in React -- a process which took several years and resulted in a codebase of much greater complexity. (Performance was better than the old website but I'm not sure React really contributed to the gains here.) While AMP is rightly dead, I think the technical choices it made live on (or at least, they should).
- trollbridge 1y agoAMP seemed like a great technology that ended up being used for user-hostile purposes.
- Henchman21 1y agoIf you swap out AMP for ${generic_tech} this statement seems to describe the latest 15 years of software development.
- throwaway28692 1y agoIt was never user-hostile. It was definitely publisher hostile but that isn't the same thing.
- dbbk 1y ago
- neuroelectron 1y agoEverything Google has done in the last 20 years has made the web worse.
- jefftk 1y agoThis is just obviously false. If you want to claim that Google's impact has been on balance negative we can certainly argue about that, but some clearly positive things include: * Massive security improvements, including encryption (pushing HTTPS throughout the stack, funding Let's Encrypt, trackers on HTTPS adoption), site isolation, Project Zero, certificate transparency, pushing CSPs, authentication standards. * Large speed improvements, including V8, HTTP/2, HTTP/3, Brotli. * Web standards, including work on HTML5, JS standardization, web assembly, CSS flexbox and grid, webrtc. (Disclosure: I worked on web stuff at Google 2012-2022)
- nottorp 1y ago> pushing HTTPS throughout the stack Barriers to entry for self hosted sites. Easier to host with Google now. > Large speed improvements, including V8, HTTP/2, HTTP/3, Brotli. HTTP/whatever was done only for Google's benefit. > Web standards, including work on HTML5, JS standardization, web assembly, CSS flexbox and grid, webrtc. If they're so standard why do people develop for Chrome and ignore other browsers?
- jefftk 1y ago> Barriers to entry for self hosted sites. Easier to host with Google now. Let's Encrypt (which Google helped fund) is the opposite of a barrier to entry. Free domain-validated fully automated HTTPS cert distribution wasn't a thing, and now it is. It makes it way easier to self host in a post-PRISM world. Also, Google does a tiny fraction of overall web hosting. > HTTP/whatever was done only for Google's benefit. Your claim is that everything Google has done has been worse for the web, so you don't get to pick individual tech that's clearly good (ex: V8) and ignore it. And whether things were done for Google's benefit is also irrelevant: the claim is about outcomes. On the specific question of HTTP/2 and HTTP/3, these have made large improvements in end-to-end loading times across the web, including when Google is at neither end of the connection, and especially for high latency connections like mobile. > If they're so standard why do people develop for Chrome and ignore other browsers? All of the things I listed are widely supported and fully standardized. There are other parts of the web platform that aren't, and that does push people to Chrome, but that's not what we're talking about. Again, if you'd like to claim Google's impact has been bad on net that's much more arguable, but your claim is way stronger than that.
- rchaud 1y agoThis article misses the point of why emails were made interactive in the first place - to satisfy the demands of marketers. 90% of the emails you get are marketing-related. If you get an email that says "4 days left for our holiday sale", that counter will need to be updated if the email is not read on the same day. It's a small, maybe frivolous-sounding use case, but a lot of feature bloat starts out this way.
- Nazzareno 1y agoYou can do much more with AMP, not only marketing related stuff. Indeed, countdown timers can be done much easier with many tools (Nifty Images, Sendtric etc) without AMP.
- rchaud 1y agoAMP as described in this article provides a wrapper for some templated kinds of JS functionality. My comment wasn't specific to AMP, it was to the article's main point about "interactive emails" being unnecessary.
- draw_down 1y ago[dead]
- BiteCode_dev 1y agoYou don't need interactivity for this, you just need "<img src="" />"
- dawnerd 1y agoWhich still isn’t perfect as images get cached at different stages depending on the email client.
- johannes1234321 1y agoOr can be blocked or are opaque to visually impaired.
- epc 1y agoNetscape tried dynamic email with Communicator in the 90s…somehow I still have the sample "Airius Airway's 401k Contributions Worksheet" with JavaScript embedded (Gmail obviously ignores it). IIRC no one, and I mean no one, took advantage of it.
- h1fra 1y agoWhen AMP was about to be released, I was the engineer in my company in charge of deciding whether to implement it. I discarded the idea, but months later we realized Google was not joking about the SEO boost, and we had to backtrack very quickly in order to not lose to the competition. I regretted saying no because I missed the opportunity, but I was still convinced it was a bad idea overall. Now that it's gone, I could not be happier. Not only did AMP made the internet worse, but it was a pain to implement, a bad experience for users, and a bad deal for media companies.
- deleted 1y ago[deleted]
- Breza 1y agoI was on the opposite side. When AMP4email came out, I worked at a publisher of email newsletters. I pushed our CTO to implement it. He was less than enthusiastic. We ultimately decided it wasn't worth the effort and now that looks like a smart idea.
- faust201 1y agoAMP was a boon to all crap sites built by S Asian newspapers etc. even FT, guardian at some point had individual pages that were about 50x larger than it's AMP equivalent. Yes, for the rich AMP is monopoly etc. for poor like me - I prefer less data usage.
- hughw 1y agoGoogle Wave (ca 2009) also claimed that it would replace email. Expect the next email replacement from Google in 2029.
- rhet0rica 1y agoI came looking for this comment. One wonders if AMP-in-email was a project of the same team scaling back their original ambitions... but 10 years is a long time at the revolving door of Google.
- smeej 1y agoI was so disappointed this failed, and for what seemed like such an incredibly obvious reason. They tried to use the same viral "invitation only" system that had worked for Gmail for Wave, but apparently completely overlooked the key difference: Gmailers could send and receive emails to people who didn't have Gmail. Wave was only usable with other people who had Wave. And with only a handful of invitations, it was virtually impossible to grow your network fast enough for it to be useful. If they had made it possible to send regular emails to and from Wave (even just by integrating the existing Gmail account!), but then also let you "upgrade" your message to send a Wave when the recipient already had Wave, I really think people would have been willing to use it long enough for their Wave networks to grow big enough to replace email.
- Nifty3929 1y agoTo me the most important objection is that an email is a record of something, and needs to be self-contained and immutable for that reason. When I get an email, I want to know that I can always come back to that exact email for reference, and that there's no way that it can have changed, or that the important information is externally referenced (and therefore also subject to change). I think this is one important reason that more and more emails are just links to some website with the information on it (often with a login required as well). It allows the company sending you the email to retain control of that information. If you email me a text or PDF invoice, I can always come back to it for my own reference. If you send me a link to one, there's no guarantee I can still access it later.
- LoganDark 1y ago> I think this is one important reason that more and more emails are just links to some website with the information on it (often with a login required as well). I hate this with all of my being. It's awful. Send me an email that tries to tell me how important the information is without actually giving me the information... and I won't read it, fuck you. You don't get to decide which information I find important.
- xp84 1y agoI agree wholeheartedly -- it's like getting a postcard saying "You have an important message from your doctor, go visit the doctor's office to find out what." I respect that some of this is ass-covering because of overreaching regulation (or in many cases probably overly-conservative readings of the vague regulations) especially with respect to HIPAA and Euro-style "Privacy" legislation, but personally I'd prefer to opt-out of all types of nanny-ism trying to 'protect my privacy' by sending me content-free email with links, that then require that I 'click to view' and then, 90% of the time now, return to my fucking email to retrieve a stupid code.
- LoganDark 1y agoMy doctor does it ("you have one new notification, log into our system to see it"), financial systems do it ("something something happened on your credit report, log into our system to see it"), legal systems do it ("you have something something communication, log in to download it"), etc. It's utterly infuriating.
- 0xbadcafebee 1y ago"Interactive email" is basically Slack. We should make Slack a new internet protocol and application standard, and use that going forward to replace e-mail, texting, and the various isolated islands of "secure chat" solutions (WhatsApp, Signal, Telegram, etc). Allow us to retain and control our own data, while also enabling all of the features and functionality we've come to want from modern tools, and be compatible with other solutions. IRC and e-mail are both old and busted. 99% of the world wants to communicate and share information with more interactive tooling than ASCII text in a console or static HTML in a mail reader. There are alternatives to Slack, but like every networked application created in the last 10 years, none of them define an interoperable standard. They are all their own vendor-lock-in islands. Even Mattermost, the most polished "open-source" alternative, is not a standard, it's an application. Applications change all the time. Standards don't. Applications lose backwards compatibility, change their licenses, have closed ecosystems of servers. Standards don't. There's a reason that actual standard network protocols continue to work for 40 years, while applications made just a few years ago are dead and buried. Standards last. They enable interoperability in an ecosystem of supported technology. They give us flexibility, choice, competition, portability. The world is better when we have solid standards to build on. Replace it all with a standard. Let anyone implement the standard, implement a client, a server, etc. And let people choose the tooling they want - but while being interoperable with everyone else's. (Note that I'm not talking about federated social networks. E-mail and IRC are not social networks, they are communication tools, private by default, and have to be directed at specific individuals or groups)
- watermelon0 1y agoI think that you just described XMPP and Matrix, which are both standards.
- 0xbadcafebee 1y agoComparing XMPP/Matrix to Slack is like comparing Telnet to Chrome. Yes, they both display text, they're both interactive. But the latter has about 5,000x more features, which is why we all use it. Yet with Slack, it doesn't use a standard. Could you build an app like Slack that includes XMPP/Matrix along with a whole lot of other stuff? Sure. But without the whole kitchen sink, you still don't have a standard other apps will follow. You have a proprietary app plus XMPP. Other apps won't be compatible with it. Which is the case with Slack's competitors. Think of a web browser. It's larger than a kernel. It's probably the biggest, fattest, meatiest, most feature-rich application in the world. (And it should be, because it's a freakin' application platform at this point.) But it all runs on.... standards! Every part of it. I'm saying, do that, but for the massively feature-rich, complex, large, almost unwieldy, but insanely productive, communications platform that is Slack. I get that a lot of people don't really understand what the big deal about Slack is. A lot of people thought the same thing about web browsers back in the day. But once they started using them a lot, they got it. It's not just a document viewer, just like Slack isn't just chat.
- ChrisArchitect 1y agoThis is a weird thing to write about in 2025. AMP emails didn't really take off / get any kind of adoption did they. And HTML emails, annoying and problematic as they are have come a long way from the mess of client support and complete hack-job coding to where they are now thanks to standards and largely the popularity of web-based clients and the benefits those bring for email reading. GIFs inside emails unthinkable and ridiculous ten years ago. Today, not a big deal really for a good chuck of audiences. Etc.
- kotaKat 1y agoI do remember using WorkMarket a long time ago and experiencing the bizarreness of their emails as they were one of the very few AMP users. They'd send out emails about work opportunities and leveraged AMP to be able to go back into the email and tell you if it's still available to apply for or not in realtime, so you wouldn't have to click through and be disappointed it was already taken.
- Breza 1y agoI'm surprised more people don't use images for this kind of thing. You could put an image with a green checkmark next to every live job posting, and change it to a red X once the job is no longer available. I worked for a publisher of email newsletters and we ran a bunch of tests into the caching behavior of email clients to see how viable this kind of thing would be. Turns out it's pretty easy to implement and works just about everywhere.
- robertoandred 1y agoOn the contrary. The only place you get a standards-based email is Apple Mail on Mac and iOS. Gmail's web client is absolutely terrible for web standards. Outlook, on the web or app, is almost as bad.
- Digit-Al 1y agoEmail and SQL: two technologies that people keep saying are out of date and need replacing, but they keep rolling on whilst attempted replacements wither on the vine, with their dust eventually blowing away on the winds of time.
- skybrian 1y agoMeanwhile, many people don’t send personal emails anymore and people have switched to a variety of chat apps instead. And a lot of businesses use chat internally, such as Slack. It’s mostly business use that’s keeping email alive, either business-to-consumer or business-to-business.
- Spivak 1y agoYeah, this whole argument falls down when email is for junk mail, sending files, and password resets, and 6 digit codes. It's by every measure a failure by "product released after 2000" standards.
- throwaway28692 1y agoSo frustrating when people complain about Google trying to save dying technologies like email and the web. I'm glad that email is working for you but over here in the real world I don't know anyone who still uses it.
- perfmode 1y agoremember google wave?
- nottorp 1y agoIMO any standard pushed by the great internet gatekeepers (Google, Cloudflare etc) is best avoided. And don't tell me Cloudflare does no evil, that goes for now, and that went for Google some time in the past too.
- LinuxBender 1y agoI've never received an AMP email but it looks like based on the format [1] one could search the body for cdn.ampproject.org and either REJECT, DISCARD in Postfix or quarantine it if using some anti-spam platform. # grep body main.cf body_checks = regexp:/etc/postfix/body_checks # grep ampproj /etc/postfix/body_checks /ampproject/ REJECT AMP IS NOT SUPPORTED ON THIS SERVER [1] - https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format https://amp.dev/documentation/guides-and-tutorials/learn/ema...
- albert_e 1y ago> Four years earlier, the search giant had come for the mobile web with AMP—accreted mobile pages. typo in third line of the post. should i feel warm and fuzzzy knowing that this was not run through an LLM? or is it a hallucination artifact of that very thing.
- account-5 1y agoI didn't know amp was a thing in email. Glad it died before I knew about it. I've never viewed an amp site either. Actively avoided them, went out my way to view the actual content. Easy to do when you don't have JavaScript enabled by default. I hate it when I can't view textual information on a site without JavaScript.
- _Algernon_ 1y agoThe worst part about AMP was that it didn't even feel particularly fast. Not sure how they managed to fail at literally their main design goal.
- ingvar77 1y agoI think it was a great idea, useful in many cases (confirmations, approvals, votes, unsubscribes, forms, up-to-date flights and bookings info etc etc. I for sure admire that I can accept meeting invites right inside email in Gmail. Email must stay the same - it has HTML/text parts, these will stay same and can be accessed in 5 years. If someone really wants to include dynamic info in email they will do anyway- either link to webpage or dynamic image.
- gregable 1y agoI worked on AMP and AMP email for a while at Google, but these are just my thoughts. HN always pulled out the pitchforks on this topic, I'm not surprised to see the same again. I disagree with a number of things this article claims: > Build an AMP site, and you’d get preferential placement in search results ... The implicit stick, though, was that without an AMP page, your site wouldn’t rank as highly as it may have previously. And There was an AMP news carousel that would appear at the top news results. The web result order however didn't prefer AMP. Depending on how you looked at it, this was preferential or it wasn't. The "wasn't" perspective is that this carousel was much like showing image or video results - it was a different format and there was a result spot reserved for some docs of that format if the query warranted it. Interestingly, when Google first started rolling out carousels for images or videos in normal results, website owners protested as well as it was competition for visibility. I don't hear that argument as much any more. Regardless, the AMP carousel has been gone for a while AFAIK. > “We are here to make the web great again,” said Google’s vice president of news, Richard Gingras in 2015, only months after Donald Trump brought that phrase into the vernacular Yeah, that aged poorly. > [AMP] brought back the dynamics of the mobile versus the desktop web, for one. Instead of the same web for everyone, you now had one page on mobile, another page on desktop That was a website owner choice. AMP pages could be responsive and work just fine on desktop. Many sites did exactly that, though you often never realized they were AMP pages. The goal of the project was always to optimize mobile performance, but it worked well for desktop too. Search provided a mechanism where you could choose to pair an amp and non-amp page, only showing AMP for mobile. I suspect sites did this because non-amp allowed all of the bespoke javascript they wanted on desktop, including things that were kinda terrible for user experience but improved ROI. Super heavy javascript, ads that were difficult to dismiss, all sorts of jank. > And, more critically, it lessened your control over your site. ... ad tech and other scripts on your site might be incapable of running on your AMP site AMP is a subset of HTML plus some javascript libraries. The subset thing means you had a limited API. That was the point though, the limited API was restricted to the set of things that could be forced to be performant. That is "control" in some sense, but it wasn't control in the common sense of limiting content or ad networks or whatnot. Virtually every ad network had a library for running on AMP. > AMP required allowing any AMP CDN to cache your pages. You can and always could create amp pages that are not served by AMP CDNs. The tradeoff is that search results couldn't preload the page for the user, as there is a hard privacy constraint that the user can't initiate network traffic to the publisher until they indicate intent with a click. So without the CDN, it wasn't quite as fast, but it was still typically pretty fast. > As Ray Tomlinson, who implemented and sent the first email from ARPANET in 1971 said about adding formatting to email: “That’s too complicated: we just want to send messages to people.” This is a valid perspective on what email is or should be. I don't feel strongly that it's the only perspective, but it's certainly valid. The argument however is really against HTML email, not AMP email in particular. I think most of the rest of the arguments apply pretty equally to both. If you look at HTML email in webmail clients, clients all work on the principle of sanitization. Take arbitrary HTML, modify it to remove anything dangerous, and then render the rest. "anything dangerous" requires removing all javascript, most or all CSS, large swaths of the HTML tag space, rewrite all image URLs, etc. This would result in pretty garbled results except senders have adapted to only send the subset of HTML that won't be garbled. However, it's not easy to do. Take a look at https://templates.mailchimp.com/resources/email-client-css-support/ https://templates.mailchimp.com/resources/email-client-css-s... which shows what each email client accepts. It's much much worse than browser incompatibility, though you also have to handle browser differences too. In a sense, this limited HTML API is similar conceptually to AMP. AMP just was able to add back some of the interactive functionality stripped away. And AMP had the possibility of becoming a open-source standard compatibility API for webmail clients. One that was open source, had maintained validators that could be tested against, etc. I think it had the chance to really make HTML email better. Of course, if your perspective is that HTML email is fundamentally bad, then that's not really a win. > You’d need to authenticate your domain with DKIM, DMARC, and SPF—good ideas, regardless. You’d also need to send a sample email to both Google and Yahoo!, and register your domain with each of them. Then, if you were lucky, within 5 days you’d be approved to start sending AMP emails. I think the plan was always originally to expand this to a general availability format. However, AMP email launched in 2019 and Google largely shifted away from AMP shortly thereafter, so the project never got enough momentum to get to that state, sadly IMHO.