by maguay on 4/18/25, 7:31 AM with 165 comments
by Nifty3929 on 4/18/25, 3:14 PM
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.
by room271 on 4/18/25, 12:33 PM
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).
by Digit-Al on 4/18/25, 3:48 PM
by h1fra on 4/18/25, 2:28 PM
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.
by faust201 on 4/18/25, 2:28 PM
by ChrisArchitect on 4/18/25, 3:36 PM
by ingvar77 on 4/18/25, 10:18 PM
by epc on 4/18/25, 2:25 PM
by hughw on 4/18/25, 2:52 PM
by nottorp on 4/18/25, 4:52 PM
And don't tell me Cloudflare does no evil, that goes for now, and that went for Google some time in the past too.
by 0xbadcafebee on 4/18/25, 3:27 PM
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)
by account-5 on 4/18/25, 7:18 PM
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.
by albert_e on 4/18/25, 5:42 PM
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.
by LinuxBender on 4/18/25, 5:36 PM
# 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
by _Algernon_ on 4/18/25, 7:22 PM
by gregable on 4/18/25, 10:26 PM
> 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.
by rchaud on 4/18/25, 1:55 PM
by neuroelectron on 4/18/25, 1:37 PM
by Spivak on 4/18/25, 11:30 AM