Comment by room271 | Hacker News Reader

Comment by room271 | Hacker News Reader

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.

Yep. I totally see why they did it. It’s a user focus, not developer focus. Users just want faster webpages. The end.

>without AMP we get downranked in Google

Whether a site used AMP did not affect ranking in Google.

Ranking is a closely held secret. Non AMP COULD have a negative impact. Let marketing try and get confirmation from Google that it does not.

You're either uninformed or splitting hairs about what "downranked" means. Google required AMP in order to be featured in the "Top Stories" carousel that was (unsurprisingly) at the top of the results page. Google ended this requirement in mid 2021, https://www.theregister.com/2021/06/28/google_amp_core_web_v...

I'm talking about search rankings and not what appears in the OneBox.

Doesn't really matter. Google directed clicks to the AMP sites in various ways, including the OneBox. Most sites which need ad revenue had no choice but to adopt AMP.

Why couldn't they just directly downrank pages based on their size or load time?

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

It's "accelerated mobile pages" but I love the abuse version.

Well yes, obviously Google didn't actually name it for Abuse of Monopoly Power.

Not publicly, at least.

They've put some seriously dumb admissions in writing before.

https://www.techemails.com/p/sergey-brin-irate-call-from-ste...

They learned from this and now just have periodic arbitrary layoffs to depress salaries and keep the workers scared and in line in a deniable way instead of in an explicit way.

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 set of rules for people who are unable to stop themselves from making bad decisions. It has nothing to do with technical superiority. AMP is a deal under which, if an adopter stops acting like a jackass, they receive better search ranking. There is nothing that stops you from creating an AMP-like experience if you are naturally not a jackass.

> AMP is a deal under which, if an adopter stops acting like a jackass, they receive better search ranking.

You mean, jackassery like, not running ads from Google's ad platform(s)?

AMP has no relationship to Google Ads, does not require Google Ads, and does not require using Google's CDN. There are dozens of ad networks that support(ed) AMP.

Google Ads has integrations for AMP. AMP does not require Google Ads.

Perhaps not directly, but from the article:

> AMP required allowing any AMP CDN to cache your pages. Visitors might be served your page from a Google domain instead of your own, or the ad tech and other scripts on your site might be incapable of running on your AMP site (handily, it seemed, for Google, who might prefer you to use their ad tech instead).

Part of that statement is correct, part of it is misleading.

> AMP required allowing any AMP CDN to cache your pages.

Sort of correct: this is true if and only if you wanted the rank boost for Google search. If you just wanted to serve AMP and have snappy page, not entirely correct.

> other scripts on your site might be incapable of running on your AMP site

Correct, because that's the entire point of AMP. It is a straightjacket intended to make it technically impossible for your "other scripts" to run, because actual users hate your "other scripts" and they make users' phones overheat etc.

Exactly this. AMP was not a technological concern so much as a "contract": I won't act like a jackass and do anti-user things on my site and you will convey that to your readers/searchers.

Doesn't seem to prevent AMP sites promoted on Android/Google/Gemini assistant from using dick moves like hijacking the back button to prevent you from leaving. I can't fathom why Google doesn't drop the hammer on that behavior.

It wasn't innovative or intended to be, it was a solution to a collective action problem. It's easy to make the case for "we have to do it this way to avoid being penalized in search rankings".

Doesn't Google already penalise websites for poor performance though? Why not just intensify that penalty, rather than develop and promote a new framework intended to forcibly prohibit bloat?

Sure but people won't always respond to incentives. It's like asking why AA exists when the cops will already throw you in jail for being drunk in public.

Google will rank results partially based on page performance and behavior. It is possible to improve your ranking by improving page experience. AMP is the complement: a tech stack that makes it impossible to not do those things.

When nearly every site has horrible performance IDK if it would make a difference to intensify those penalties, as they'd apply about equally for instance to every news site, every blog, every e-commerce site, etc.

But that's the same with AMP. If every site doesn't have AMP, penalizing them for not having AMP changes nothing.

In both cases it's an unstable equilibrium. The first site to be fast will get all the clicks. Or the first site to use AMP.

That was the replacement mechanism after AMP, yes

With AMP, Google could preload and pre-render sites, so things like swiping through a carousel between search results was instant.

That’s not possible without building an AMP page since it requires being able to safely serve off of google’s domain.

Thanks, that sounds like a neat feature. Regrettable than neither the Wikipedia summary, nor the Google Search AI overview, nor Google's own official summary page for AMP, [0] make this clear.

[0] https://developers.google.com/amp

The innovation is that the page can be prerendered from cache without any privacy or analytics concerns. AMP is an open standard replacement for Facebook Instant Articles and Apple News Format.

https://en.wikipedia.org/wiki/Facebook_Instant_Articles

https://developer.apple.com/documentation/applenewsformat

Prerendering was old-school back then, too.

Edge caching might not have been as prevalent but was hardly new technology.

> without any privacy or analytics concerns

Uhm, yeah, no. Less bloated JS usually means less concerns but privacy violations and tracking of visitors can very much happen on AMP. Some of that risk isn't removed, just shifted.

> Uhm, yeah, no. Less bloated JS usually means less concerns but privacy violations and tracking of visitors can very much happen on AMP. Some of that risk isn't removed, just shifted.

Um, yeah, yes. The whole point of AMP (and competing proprietary formats like FBIA and ANF) is that the preloading happens from a cache owned by the link aggregator, so the publisher doesn't get your details just because its page was prerendered in the background. The link aggregator obviously already knows that you're browsing over the article link, so there is zero privacy loss.

With AMP, you basically get guard-rails to prevent your team of junior engineers from making your mobile pages too slow in exchange for increasing The Google's monopoly power. :D If I remember correctly, with AMP, you have to use their web components, and you have to pass their validator or pages won't be listed or cached at all. AMP is not really innovative in the slightest. One can easily serve pages faster than an average AMP page if they wanted to. The businesses that see engineering as a necessary evil are not properly incentivized to care about page performance, and are sometimes only prodded into doing so if a giant like The Google tells them to. Management tells their programmers that they read an article about AMP and that it makes pages load faster and reaches a wider search audience by caching and cutting out unnecessary crap; the more seasoned programmers think "Yeah, no shit – I've been trying to tell you... but I'll spend time rebuilding pages for AMP because I get paid the same either way."

> One can easily serve pages faster than an average AMP page if they wanted to

This is incorrect. You cannot beat prerendered. It does not make sense to implement AMP for people visiting your website directly. AMP is for link aggregators like search engines, news aggregators, and social media websites.

The point of AMP was to force publishers to build non-bloated websites, because they weren't doing it of their own free will.

AMP is dead

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

How would forking work? The whole point of AMP is that a cache can validate that it is safe to prerender. If you added your own stuff, the caches would just reject it.

AMP is both a Javascript framework, and a wider page contract that facilitates CDN inclusion.

I believe the parent is referring to the Javascript framework, which itself has many nice properties for interactivity and performance.

Yea and I will say I don’t think it would be terribly hard replicate the benefits of the CDN on something like Cloudflare Workers

The point of AMP is that the link aggregator owns the cache, not the publisher. You would have to convince Google, Bing, and all the other link aggregators to use your implementation for their AMP caches. That's why it has a standards body. If you don't understand why, you don't understand the problem that AMP solves. https://news.ycombinator.com/item?id=43733809

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

If you swap out AMP for ${generic_tech} this statement seems to describe the latest 15 years of software development.

It was never user-hostile. It was definitely publisher hostile but that isn't the same thing.

Of course it was user-hostile. I can't tell you how many times I would get linked to an AMP version of a page on desktop, with text spanning the entire width of the screen, and no way to get back to the 'normal' version.

Reply on news.ycombinator.com