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.
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.
> 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.
> 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.
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 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.
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?
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."
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.
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.
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.
I 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.
I 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.
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)
XMPP exists as a standard, and Google Chat was built on it. Then Google+ came along and needed more features, and instead of adding these features to a standard that supports federation (like XMPP or now Matrix), Vic Gundotra (I assume) did the expedient and stupid thing of building Hangouts Chat like Facebook Messenger, commencing the parade of throwaway Google communications products to come.
I 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.
I'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
I 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-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.
> 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.
Javascript libraries that MUST be loaded from one specific Google CDN.
If I load the exact same libraries from my own domain, suddenly it's not "valid" AMP anymore.
It's not a standard if it only works with one specific implementation.
This 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.
You 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.
This 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)
I'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.
No, 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.
The 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.
Discord 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.
Such 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.
Discord 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.
Nifty3929|10 months ago
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.
ChuckMcM|10 months ago
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.
albert_e|10 months ago
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.
mcv|10 months ago
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.
LoganDark|10 months ago
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.
rajnathani|10 months ago
maronato|10 months ago
[1]: https://techcrunch.com/2014/06/18/pluto-mail/
m463|10 months ago
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.
mschuster91|10 months ago
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.
room271|10 months ago
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).
hn_throwaway_99|10 months ago
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.
EvanAnderson|10 months ago
It never occurred to me that AMP is an initialism for "Abuse of Monopoly Power". It's deliciously fitting.
MaxBarraclough|10 months ago
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
Eric_WVGG|10 months ago
Instead they should have said, "Web pages should be lightweight not overdo it on interactivity, and load fast."
no_wizard|10 months ago
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
trollbridge|10 months ago
Digit-Al|10 months ago
skybrian|10 months ago
It’s mostly business use that’s keeping email alive, either business-to-consumer or business-to-business.
throwaway28692|10 months ago
perfmode|10 months ago
h1fra|10 months ago
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.
Breza|10 months ago
unknown|10 months ago
[deleted]
faust201|10 months ago
ChrisArchitect|10 months ago
kotaKat|10 months ago
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.
robertoandred|10 months ago
ingvar77|10 months ago
epc|10 months ago
hughw|10 months ago
rhet0rica|10 months ago
smeej|10 months ago
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.
nottorp|10 months ago
And don't tell me Cloudflare does no evil, that goes for now, and that went for Google some time in the past too.
0xbadcafebee|10 months ago
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|10 months ago
lern_too_spel|10 months ago
nottorp|10 months ago
layer8|10 months ago
zzo38computer|10 months ago
And, standards should not be made excessively complicated or badly designed; even if there is some complexity they should be optional when possible.
iaabtpbtpnn|10 months ago
account-5|10 months ago
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.
albert_e|10 months ago
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.
LinuxBender|10 months ago
_Algernon_|10 months ago
gregable|10 months ago
> 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-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.
kuschku|10 months ago
Javascript libraries that MUST be loaded from one specific Google CDN.
If I load the exact same libraries from my own domain, suddenly it's not "valid" AMP anymore.
It's not a standard if it only works with one specific implementation.
rchaud|10 months ago
Nazzareno|10 months ago
BiteCode_dev|10 months ago
draw_down|10 months ago
[deleted]
neuroelectron|10 months ago
jefftk|10 months ago
* 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)
Spivak|10 months ago
bayindirh|10 months ago
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|10 months ago
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.
tacker2000|10 months ago
trollbridge|10 months ago
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.
AlexandrB|10 months ago
Kwpolska|10 months ago