AMP has always been a double-edged sword. These pages were undeniably fast and for a long time, enabling AMP on a site was like a faucet you could turn on and just rake in traffic. But AMP was always an absolute abomination of a standard and horrible for the internet at large. The traffic just made it nearly impossible to say no to for most teams and agencies #WebDev https://www.theverge.com/23711172/google-amp-accelerated-mobile-pages-search-publishers-lawsuit
@developerjustin I want to argue about this so please don't interpret my autistic response as aggression; it's merely enthusiasm.
My feeling is that everyone completely missed the point about AMP.
There's the AMP cache (which accelerates the page and brings the google juice), but that wasn't it.
The real goal was letting third parties build rich content experiences without giving their JS complete access to your users' browser.
That's so much cooler than speeding up page load!
@developerjustin What sucks is that it's the only solution I've ever seen for this problem, but it's been largely thrown out with the bathwater because Google decided to play SEO games with it.
Take mastodon for example; you'd maybe like to embed a user's toot in your blog? Can you trust whatever instance you're looking at to serve a JS file you could embed in your site? Fuck no!
Instead, mastodon could serve a <mastodon-toot> element. The widget renders and mastodon can't access your document
@schizanon this is *such* a good point. There is another version of the story where, with better governance, AMP helped us dodge the React-ification of the web.
@developerjustin I think #indieWeb really missed out on #AMP. It could have brought back #RSS!
@schizanon how, though? I'm curious because even if AMP is not it, maybe we can salvage the good parts of it
@villasbc @developerjustin all I know about AMP is what their dev materials claim you can do. It lets you write JS, and then other people can consume your AMP components and that JS will get executed in a "sandbox". This protects their users while allowing your component to do some subset of things that it could otherwise do. I'm pretty sure you can fetch arbitrary urls, but there's probably limits to things used to fingerprint and cryptomine.
@villasbc @developerjustin and as for RSS; it's just text in XML, you can embed some HTML but nobody will let you embed a <script> tag.
But what if your feed items could have dynamic UI like polls, or charts, or forms? What if people could embed RSS content without fear of malicious scripts or CSS polluting the page!?
@schizanon @developerjustin Ah, makes sense. The idea is that if we could embed content with less risk, we could derive richer experiences on top of an RSS feed directly. It’s an interesting thought experiment.
@villasbc @developerjustin and the content continues to belong to you, it's hosted from your domain. You can monetize it, or update it anytime, and nobody (save for your domain host) can take it away from you!