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.

> ...it conflates political/market objections to AMP (i.e. abuse of monopoly power)...

It never occurred to me that AMP is an initialism for "Abuse of Monopoly Power". It's deliciously fitting.

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?

[0] https://en.wikipedia.org/wiki/Accelerated_Mobile_Pages

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."

I like AMP conceptually, would make a good app platform for alot of types of websites and such.

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

AMP seemed like a great technology that ended up being used for user-hostile purposes.