created Dec 11, 2019
December 2019 Hacker News threads. The first one pointed to a 2018 post, and the second pointed to a December 2019 post.
polemicdigital.com - Fight back against Google AMP (2018)
HN thread - 378 comments
markosaric.com - How to fight back against Google AMP as a web user and a web developer
HN thread - 536 comments
From the polemicdigital.com post:
Google can go to hell.
Who are they to decide how the web should work? They didn’t invent it, they didn’t popularise it – they got filthy rich off of it, and think that gives them the right to tell the web what to do. “Don’t wear that dress,” Google is saying, “it makes you look cheap. Wear this instead, nice and prim and tidy.”
F#&! you Google, and f#&! the AMP horse you rode in on.
This is the World Wide Web – not the Google Wide Web. We will do as we damn well please. It’s not our job to please Google and make our websites nice for them. No, they got this the wrong way round – it’s their job to make sense of our websites, because without us Google wouldn’t exist.
Google has built their entire empire on the backs of other people’s effort. People use Google to find content on the web. Google is just a doorman, not the destination. Yet the search engine has epic delusions of grandeur and has started to believe they are the destination, that they are the gatekeepers of the web, that they should dictate how the web evolves.
Take your dirty paws off our web, Google. It’s not your plaything, it belongs to everyone.
But publishers, especially media orgs, have enabled Google and its AMP control. The media created horrendously slow websites, and Google offered a solution and sweetened the extortion by promising a high profile in mobile search results if media orgs support AMP.
I strongly agree. Web developers and app designers should work to build fast, performant web sites that use bandwidth carefully because that's good for end users. But the entire AMP approach to doing this is questionable, and as we have seen over the years it appears to act more like a way to give Google more undeserved and unnecessary control over what should be an open web.
We're not okay with Google usurping web sites but we don't sympathize with publishers either.
The right thing is to build good web sites. Publishers obviously don't care about doing it right and we ended up with system requirements for web sites as a result. Google is now making it expensive for them to not care. Publishers are not a blameless victim of Google's monopolistic power, they actively contributed to the current state of the web.
People should not need a $1000 phone to read a news article. The only situation where it's acceptable for web sites to not work on "shit hardware" is when it's a WebGL application. In those cases, people know that powerful hardware is required before they even load the page.
Why does a WebGL application need to run over the web? This is another example of how the complex, bloated aspects of the web should have been regulated to its own protocol. bloat://idioticsite.com. It would be BloatGL. The bloat protocol idea is another story, and pointless now anyway, since that ship has sailed.
But all of this complexity stuffed into the web protocol and into web clients has led to browsers growing into massive programs, like mini operating systems, and this complexity has contributed to the existence of only two or three popular web rendering engines that can handle the bloated "modern" web. It's obviously complex when Microsoft throws in the towel on web rendering development and decides to rely on Google's web browser engine.
For the markosaric.com post, here's an HN comment that is too far down in the thread, but it's poignant, and it sounds like something I would say.
I'm not a fan of Google's proprietary web, but it's worth pointing out that this is largely a response to the increasingly shitty way publishers treat their users. Just reading basic articles on the web has become a painful exercise in dodging "Subscribe" faux-pop-ups; trying to scan text while your vision is bombarded with unrelated video; and user-hostile scroll capture effects.