Earlier quoted context omitted.
> as if the lift of transforming HTML into AMP HTML wasn't already big enough for your average web site owner, implementing signed exchanges will be over the head of 99% of the folks building web pages on the Web Converting web pages into AMP isn't something you can automate, but supporting signed exchanges is. You need certificate authorities to support the flag and web servers support the protocol, but if this catc…
How do you personally feel about AMP? It looks like an attempt to make the web a walled garden.
* I like that when AMP is used for ads then the ads are fully declarative. Advertisers getting to run custom javascript, even in a cross-domain iframe, isn't great.
* I like that AMP allows sites (currently primarily search engines) to trigger preloading in a way that doesn't leak information to the site that is being preloaded.
* I like the way things like "sorry AMP only allows us to use 50k of CSS" can give developers leverage to push back against bad site designs.
* I like that it centralizes some measurements: instead of every ad provider using their own custom polling system to determine if the ad is on screen they can all subscribe to events triggered by a single well written system. This doesn't affect the amount of tracking (there's lots either way) but it makes it hurt the user experience less.
On the other hand, I don't like that:
* AMP uses a ton of JS, and if all you want is a simple website it's going to slow things down in the non-preloaded case. For example, taking a random post on my site (https://www.jefftk.com/p/trycontra-implementation and https://www.jefftk.com/p/trycontra-implementation.amp) I see a median speed index of 1.611s on non-AMP but 2.051s on AMP: https://www.webpagetest.org/result/190417_XB_22673cb98ce390a... https://www.webpagetest.org/result/190417_PS_1a60378762d87fb...
* A lot of people that don't want to implement AMP are doing it because then they get more search traffic. I understand how there isn't currently a non-AMP way of doing preloading in a way that doesn't leak information to the site (see above) but I think Web Packaging should be extended to support this in the general case and allow publishers to use AMP only if they want to.
* The interaction between AMP and content blockers isn't great. If you have a content blocker set to allow some JS but not all (for example, no third party JS) then it's not going to run the AMP JS or the contents of the block, and AMP pages will render with 8s of white screen before the CSS times out. This is a pain, but I'm not sure what the right way to fix it would be. (I wish content blockers were smart enough to figure out which tags to run, but that's probably asking too much.)
If you wanted to expand on how AMP seems like an attempt at a walled garden I would be interested in reading it; I haven't previously read any explanations that made sense.