To 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.
I believe this is exactly correct. Email is a 'paper trail' and being able to change that paper trail ex-post facto benefits the sender waaaaaaaaaaay more than it does the receiver. I met an engineer from Google who quit when they insisted on "dogfooding" this.
They used the example, you send an email that says lets meet for dinner tonight at 6. You arrive and after 30 minutes begin to wonder, go back to your email and now it says meet "tommorow night" at 6. Are you crazy? Did you misremember? Or did the sender change the email after they sent it and you read it? How could you complain?
As I understand it, it was met internally with "that isn't what we mean." But the ability to send HR important announcements and then change them after the fact is a capability that is just too tempting for HR to resist at some point.
> They used the example, you send an email that says lets meet for dinner tonight at 6. You arrive and after 30 minutes begin to wonder, go back to your email and now it says meet "tommorow night" at 6. Are you crazy? Did you misremember? Or did the sender change the email after they sent it and you read it? How could you complain?
This is a calendar invite. And this is a completely valid use case, but it's useless if I don't have an edit log. It's crazy how many people miss that last part.
It's probably going to be even worse than that - HR (and everyone else) will probably then have to implement process and procedure and storage mechanisms to prove that emails have not been changed. This might mean storing emails in a document control system. Email is bad enough but now we're all going to have to keep a mirror in SharePoint or something like that.
Gmail started scraping all emails a decade ago. Amazon responded by removing all product and pricedetails from Order confirmation and Order shipping emails. We consumers lost out -- we dont have our own copy and archive of what we ordered. If Amazon links perish to link rot and we lose access to Amazon login, our past order and spend information is gone.
FWIW, as far as I'm aware, it wasn't gmail scraping that was the cause of Amazon pulling that information. It was third-party plugins that read people's inboxes to provide them with coupons, discounts, etc., and those companies would sometimes sell the pricing data. I assume Amazon wasn't thrilled about that, but there wasn't anything they (or gmail) could do about it as long as the user was granting them access to their inbox.
But also - I just ordered something off of amazon and I noticed that the confirmation had the item that I ordered in it, albeit in a shortened/summarized way? So maybe they brought it back, figuring that with just part of the name, there's not much someone can do with the pricing information? Or maybe they just don't care anymore?
(disclosure: I work at google, but not on this, but worked adjacent to the gmail team for a few years and am going off of my memory. I'll also tap the sign that Google doesn't mine your gmail for ads, for both consumer AND paying customers).
When reconciling my budget (with YNAB) I often use gmail as my way to connect items to transactions [0]. I've found that I can just search for the amount that my card was charged in my email and find the Amazon email that relates to that order. Then, normally from the body, there is just barely enough information for me to know what I bought.
That got annoying enough that I just wrote a chrome extension to scrape Amazon orders/transactions and auto-match and update my YNAB memo line with a summary of the items.
That's a bit of a tangent just to say: yes, they nerfed their emails but not completely.
[0] Yes, YNAB recommends that you enter transactions right as you make them, but that's not how I use it.
> more and more emails are just links to some website with the information on it (often with a login required as well)
And a 2FA SMS sent to your phone.
> 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.
Download it. It sucks having to do that and maintaining your own archive instead of trusting your mailbox, but I guess there's some advantages to that as well.
Sure, I can download it if they send it as an attachment. Not so easy when it's an external reference. I guess I could login to the website and download... the web page? Well anyway I'm not going to.
> 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.
I 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.
But with remotely loaded img tags (automated emails don’t send images as static base64) that email is far from an immutable paper trail like how a PDF is.
I agree, the ship sailed a long time ago. I have been archiving my emails since the 90s. Sometime around 2010 all the remotely loading emails came along, and since then I've several times gone back to look at an invite or announcement and find nothing but an html tag. I guess an archiver that would need print all my emails to a pdf or image file to preserve it, like the emails that show up in litigation. The tools I was using, gmvault or google's takeout, aren't made for this path we're on.
Yes, of course, and that's why it's best not to put the important information into and image. Of course, many senders do this anyway, but at least it requires them to send me an image. No different really than sending me a link to the important information as I mentioned in my post.
But let's not make this even easier or default please. It's bad enough as-is.
A nice improvement would be for prominent clients like gmail to default to NOT display images. This would force bulk-senders (including legitimate ones) to stop putting the important info in images most of the time.
Ditto with links - maybe the clients should stop making them clickable, forcing the user to copy-paste the link. Not sure about this one...
> 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).
That's an unfortunate requirement these days.
For one, in Europe concerns around GDPR: e-mail is not guaranteed (!) to be encrypted or protected against modification in transit so it might get snooped up on its way, which makes it a no-go for sensitive stuff such as healthcare information or other highly protected classes of PII, unless PDF encryption or other ways of encryption are used... but these have the issue that UX around many of them is horrible. A link to a portal however? Easy, and provides automatically the guarantee that the other person is who they claim to be.
The second problem is deliverability: more than enough email providers still have laughably low limits (sometimes < 3MB), virus scanners don't like PDFs or ZIPs that they can't read (because they don't know the password, obviously), and on top of that come the usual anti-spam concerns.
IMHO, the best way to go would be an extra header field, think like "X-External-Attachments: https://foo.com/<uuid>.pdf <hash-alg> <hash-value>"... this could be used by MUAs to prompt the user if they wish to download and store the file, provide cryptographic checks of the file, and sidestep the issue of dumbass middleboxes yeeting password-protected files, as the files can be scanned on the endpoint side.
I hate these EU requirements. They do nothing to help real users, and really make everything worse. Like, is it helpful that every single website now has an added banner that we have to click, but which still nobody reads and doesn't really help anything? All to avoid cookies, which are not really the source of the problem these laws were meant to address? ARRRGHHH!
As far as the file size - does that critically important message need to be embedded in a 10MB PDF? Maybe we should go back to 50k limits and force them to put that one-liner in plain text in the email. ARRRGHHH!
While 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).
Yeah, while I basically loathed AMP for all the control and monopolization issues, I do see what Google was trying to accomplish, at least at first.
Any front end dev has had to deal with the onslaught of asks from various marketing and sales teams: "Can you add this tag library?", "We need to integrate this affiliate broker!", etc. etc. And lots of devs would push back with stuff like "At this point we load 247 3rd party tags and JS libraries and it takes 53 seconds for our page to load, we have to stop this madness!" but the problem was that for any individual marketing team ask, the impact was small and of course that team had some KPIs to hit this quarter. It was basically a sort of Tragedy of the Commons situation.
So AMP came along and essentially gave front-end devs a technical reason why they couldn't add some shitty, slow, buggy affiliate broker JS library to the code base, so when marketing came with an ask, they could simply say "Sorry, not supported in AMP, and without AMP we get downranked in Google". AMP essentially became a technical hack to align short term incentives ("We need to add some marketing feature X!") with longer term goals of faster, lighter-weight pages.
Perhaps I'm just being dense, but I really don't see the point of AMP. If you want to build a non-bloated website, you don't need special branding from Google to do so, you just need to care about the quality of your work. Websites like HackerNews, SourceHut, and Pinboard, are living proof.
The Wikipedia article does a very poor job, in my opinion, of explaining what AMP even is. [0] It emphasises use of CDN caching to improve performance, but this can be done for any static website. What does AMP contribute? Where's the innovation?
It wasn't innovative or intended to be, it was a solution to a collective action problem. It's easy to make the case for "we have to do it this way to avoid being penalized in search rankings".
AMP is a set of rules for people who are unable to stop themselves from making bad decisions. It has nothing to do with technical superiority. AMP is a deal under which, if an adopter stops acting like a jackass, they receive better search ranking. There is nothing that stops you from creating an AMP-like experience if you are naturally not a jackass.
The innovation is that the page can be prerendered from cache without any privacy or analytics concerns. AMP is an open standard replacement for Facebook Instant Articles and Apple News Format.
With AMP, you basically get guard-rails to prevent your team of junior engineers from making your mobile pages too slow in exchange for increasing The Google's monopoly power. :D If I remember correctly, with AMP, you have to use their web components, and you have to pass their validator or pages won't be listed or cached at all. AMP is not really innovative in the slightest. One can easily serve pages faster than an average AMP page if they wanted to. The businesses that see engineering as a necessary evil are not properly incentivized to care about page performance, and are sometimes only prodded into doing so if a giant like The Google tells them to. Management tells their programmers that they read an article about AMP and that it makes pages load faster and reaches a wider search audience by caching and cutting out unnecessary crap; the more seasoned programmers think "Yeah, no shit – I've been trying to tell you... but I'll spend time rebuilding pages for AMP because I get paid the same either way."
AMP is a misplaced principle, because it says “due to the constraints of mobile, web pages should be lightweight, not overdo it on interactivity, and load fast."
Instead they should have said, "Web pages should be lightweight not overdo it on interactivity, and load fast."
How would forking work? The whole point of AMP is that a cache can validate that it is safe to prerender. If you added your own stuff, the caches would just reject it.
Email 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.
Meanwhile, 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.
Yeah, 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.
So 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.
When 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.
I 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.
AMP 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.
This 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.
I 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.
I'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.
On 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.
I 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.
Netscape 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.
Readit News
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.
They used the example, you send an email that says lets meet for dinner tonight at 6. You arrive and after 30 minutes begin to wonder, go back to your email and now it says meet "tommorow night" at 6. Are you crazy? Did you misremember? Or did the sender change the email after they sent it and you read it? How could you complain?
As I understand it, it was met internally with "that isn't what we mean." But the ability to send HR important announcements and then change them after the fact is a capability that is just too tempting for HR to resist at some point.
This is a calendar invite. And this is a completely valid use case, but it's useless if I don't have an edit log. It's crazy how many people miss that last part.
Gmail started scraping all emails a decade ago. Amazon responded by removing all product and pricedetails from Order confirmation and Order shipping emails. We consumers lost out -- we dont have our own copy and archive of what we ordered. If Amazon links perish to link rot and we lose access to Amazon login, our past order and spend information is gone.
But also - I just ordered something off of amazon and I noticed that the confirmation had the item that I ordered in it, albeit in a shortened/summarized way? So maybe they brought it back, figuring that with just part of the name, there's not much someone can do with the pricing information? Or maybe they just don't care anymore?
(disclosure: I work at google, but not on this, but worked adjacent to the gmail team for a few years and am going off of my memory. I'll also tap the sign that Google doesn't mine your gmail for ads, for both consumer AND paying customers).
That got annoying enough that I just wrote a chrome extension to scrape Amazon orders/transactions and auto-match and update my YNAB memo line with a summary of the items.
That's a bit of a tangent just to say: yes, they nerfed their emails but not completely.
[0] Yes, YNAB recommends that you enter transactions right as you make them, but that's not how I use it.
And a 2FA SMS sent to your phone.
> 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.
Download it. It sucks having to do that and maintaining your own archive instead of trusting your mailbox, but I guess there's some advantages to that 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.
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.
But let's not make this even easier or default please. It's bad enough as-is.
A nice improvement would be for prominent clients like gmail to default to NOT display images. This would force bulk-senders (including legitimate ones) to stop putting the important info in images most of the time.
Ditto with links - maybe the clients should stop making them clickable, forcing the user to copy-paste the link. Not sure about this one...
[1]: https://techcrunch.com/2014/06/18/pluto-mail/
I swear years ago I had a mail client where you could type into a received message and alter it. Maybe sun mail or early apple mail?
they finally made the message pane immutable.
That's an unfortunate requirement these days.
For one, in Europe concerns around GDPR: e-mail is not guaranteed (!) to be encrypted or protected against modification in transit so it might get snooped up on its way, which makes it a no-go for sensitive stuff such as healthcare information or other highly protected classes of PII, unless PDF encryption or other ways of encryption are used... but these have the issue that UX around many of them is horrible. A link to a portal however? Easy, and provides automatically the guarantee that the other person is who they claim to be.
The second problem is deliverability: more than enough email providers still have laughably low limits (sometimes < 3MB), virus scanners don't like PDFs or ZIPs that they can't read (because they don't know the password, obviously), and on top of that come the usual anti-spam concerns.
IMHO, the best way to go would be an extra header field, think like "X-External-Attachments: https://foo.com/<uuid>.pdf <hash-alg> <hash-value>"... this could be used by MUAs to prompt the user if they wish to download and store the file, provide cryptographic checks of the file, and sidestep the issue of dumbass middleboxes yeeting password-protected files, as the files can be scanned on the endpoint side.
What are you sending that 3MB for an email is "low"? The Bible is a little over 4MB of plain text.
As far as the file size - does that critically important message need to be embedded in a 10MB PDF? Maybe we should go back to 50k limits and force them to put that one-liner in plain text in the email. ARRRGHHH!
And get off my lawn! ARRRGHHH
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).
Any front end dev has had to deal with the onslaught of asks from various marketing and sales teams: "Can you add this tag library?", "We need to integrate this affiliate broker!", etc. etc. And lots of devs would push back with stuff like "At this point we load 247 3rd party tags and JS libraries and it takes 53 seconds for our page to load, we have to stop this madness!" but the problem was that for any individual marketing team ask, the impact was small and of course that team had some KPIs to hit this quarter. It was basically a sort of Tragedy of the Commons situation.
So AMP came along and essentially gave front-end devs a technical reason why they couldn't add some shitty, slow, buggy affiliate broker JS library to the code base, so when marketing came with an ask, they could simply say "Sorry, not supported in AMP, and without AMP we get downranked in Google". AMP essentially became a technical hack to align short term incentives ("We need to add some marketing feature X!") with longer term goals of faster, lighter-weight pages.
Whether a site used AMP did not affect ranking in Google.
It never occurred to me that AMP is an initialism for "Abuse of Monopoly Power". It's deliciously fitting.
The Wikipedia article does a very poor job, in my opinion, of explaining what AMP even is. [0] It emphasises use of CDN caching to improve performance, but this can be done for any static website. What does AMP contribute? Where's the innovation?
[0] https://en.wikipedia.org/wiki/Accelerated_Mobile_Pages
That’s not possible without building an AMP page since it requires being able to safely serve off of google’s domain.
https://en.wikipedia.org/wiki/Facebook_Instant_Articles
https://developer.apple.com/documentation/applenewsformat
Instead they should have said, "Web pages should be lightweight not overdo it on interactivity, and load fast."
I wish it was easier to fork, honestly. There's some good ideas within, though some questionable choices as well.
Unfortunately the project is rather opaque in a number of ways
It’s mostly business use that’s keeping email alive, either business-to-consumer or business-to-business.
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 Comment
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.