Hacker News Reader

> However, as a non-principled web consumer, I think AMP pages are 10x better than the ad-filled, slow as molasses, jump-around-as-JavaSript-loads, video autoplaying, 'stories you might like' suggested bullshit, auto-loading 20MB heaps of steaming garbage that current news sites are.

You don't need AMP to get rid of them though. We can appreciate that Google encouraged developers to get rid of bloat AND to opt-in for AMP, but that doesn't make AMP technically superior. I think we should give a critique of ourselves and ask why did we wait for a corporation G to push us to get rid of the bloat we created?

We can appreciate that Google encouraged developers to get rid of bloat AND to opt-in for AMP, but that doesn't make AMP technically superior.

Depends what you mean by technically superior. In terms of benchmarks, AMP pages are lightning fast. Isn't that the only metric that matters?

On that same metric good old plain HTML is faster.

Well, sure. But HN is one of the few major websites that uses plain old HTML. At other websites, developers have very little leverage. The people pushing for bloated websites are managers / executives, not devs. Hence, bloat.

What can we do about this situation?

> At other websites, developers have very little leverage. The people pushing for bloated websites are managers / executives, not devs. Hence, bloat.

I found that AMP helps a lot in that marketing/exec teams see Google pushing AMP and think they need AMP.

My company built AMP equivalents, and honestly I wish we could ditch our entire React site for AMP.

Instead of an exec demanding a feature, we can now say "AMP doesn't support it." No matter how many times we've set performance budgets, management absolutely tears the budgets down the second we need to implement some flashy new feature (which for some reason is the perceived solution to every sales slump). A group of us has tried to use data against this at least a handful of times, but memories seem to be short lived.

Of course we need organizational change, but after pushing a stone up the hill over and over again you essentially just say "fuck it" and let it crush you. Bottom-up corporate change is a fool's errand.

I meant that you could achieve the same by reducing the bloat, applying the best practises etc. To be fair, Google has been encouraging people to do so through the PageSpeed suite for quite a long time...

What I found unfair about AMP is Google preloading your AMP-enabled webpage. So that even if your not-AMP-enabled page is equally efficient, an AMP-enabled page would feel faster because Google preloads it in the background. And then there is the fact that Google hosts your own content under their domain, and all other points raised in the article.

Right, but users don't care about the reasons why it's faster. They just know it's faster. Hence they use AMP, and AMP gains traction. We can say it's unfair, but that's life.

If we want to defeat AMP, we have to beat it at its own game. That requires us to come up with an alternative that's equal or faster than AMP. And clearly we've failed as developers to push for non-bloated solutions.

It might be possible to create our own version of AMP -- to take the best ideas from AMP and integrate it into some centralized system that isn't controlled by Google. It'd be tough, but the alternative is to let AMP steamroll us. A few rebellious developers aren't going to make much difference in terms of total AMP adoption.

Even if the AMP alternative was just a standard way of stripping bloat from websites, that might get us 50% of the way toward beating AMP.

Isn't AMP itself just a standard way of stripping bloat from websites? You could take the AMP library, include it in your web page and do anything you want with it.

What is the precise element of AMP you are trying to beat?

I think people are uncomfortable with the idea of Google controlling every aspect of your website down to the presentation. It'd be better for this to be centralized and standardized independently of Google's tendrils.

Part of what makes AMP fast is the preloading, so any AMP competitor would need to tackle that problem. You'd also need to demonstrate that websites rank better if they use your solution. And they should, if Google plays fair. If not, then at least this would be a public demo of that fact.

It's that and Google's CDN. If you hosted it yourself Google wouldn't include you in Search results carousel.

> If we want to defeat AMP, we have to beat it at its own game. That requires us to come up with an alternative that's equal or faster than AMP.

The technical work has been done for years. The problem is that currently the only decision which matters is Google's and they're treating performance concerns as a way to use other people's content to bolster their own brand. The only two ways that seems possible to change are either convincing Google to reverse that policy or getting more people to use non-Google search engines, which seems unlikely given the huge quality lead they have over Bing, DDG, etc.

This is similar to what happened with HTTP/2. Varnish author has his own proposal, but everything asides from SPDY simply wasn't even looked at.

And the current SPDY solution actually turns out to be worse under many circumstances, causing QUIC.

AMP pages hosted at a fast CDN under your own domain name would be technically as good as AMP pages hosted on Google's CDN

> In terms of benchmarks, AMP pages are lightning fast.

But apparently not faster than doing it yourself.

"Pinboard founder Maciej Cegłowski already recreated the Google AMP demo page without the Google AMP JavaScript and, unsurprisingly, it's faster than Google's version."[1]

[1] https://www.theregister.co.uk/2017/05/19/open_source_insider...

Because most of these pages are also corporate owned, and they believed that doing that stuff increased revenues.

Exactly, and Alex is probably not the only one who thinks that way:

"I initially enabled AMP on my site for one reason only – ranking well in Google search results."

This reminds me about a friend of mine, his father used to run a restaurant and he enabled "donations" to the mob to get a "better ranking" (or not to suffer worse ranking as it were).

> You don't need AMP to get rid of them though. We can appreciate that Google encouraged developers to get rid of bloat AND to opt-in for AMP, but that doesn't make AMP technically superior. I think we should give a critique of ourselves and ask why did we wait for a corporation G to push us to get rid of the bloat we created?

AMP (or something like it) makes it easier to push recommended practices to upper management and your team though. A site is either an AMP site or it isn't; you can't selectively ignore some of the recommended practices. If you're not using AMP, you've got to convince your team to follow the recommendations and get management to schedule time for it. For example, it's probably a tough sell to refactor an existing page to remove blocking JavaScript unless you can prove it's going to lead to a big speedup and so on for all recommendations.

I'm not saying that it's impossible to do this, just that something opinionated like AMP helps everyone follow recommended practices with less friction. It's similar to having a compiler that gives an error for a recommended practice vs it being in your coding style guide that you have to manually enforce.

While your point is valid, it's a sad state of affairs when engineers and their managers can't even be trusted to make good decisions for themselves, and have to outsource their judgement to Google under the guise of having your hands tied. The irony, it would seem, is that you're actually tying your own hands in other ways.

Of course, we could argue till the cows come home about what "good" judgement is :)

> While your point is valid, it's a sad state of affairs when engineers and their managers can't even be trusted to make good decisions for themselves, and have to outsource their judgement to Google under the guise of having your hands tied. The irony, it would seem, is that you're actually tying your own hands in other ways.

Well, when you've got your project managers, marketing people, coders etc. all trying to optimise for different things, each group doesn't understand each other and team member expertise differs I don't think it's that weird that issues like blocking JavaScript, encoding image sizes in HTML etc. aren't top priority.

For website speed, anything that makes it easier to know what the right thing to do is without debate is going to help. Even within a team of experienced web developers it isn't obvious what the best approach is because there's so many options.

I think it's because these bad little decisions make the publisher incrementally more money, and so their managers push for bloat. Eventually they end up squeezing more and more out of the audience subset that hasn't cracked and turned to an alternative.

On iOS I usually find AMP pages to be less usable. It forces a bar at the top and I can't easily share the link. Sometimes sites don't seem to work at all. For a long time any Reddit link on the Google Search results just didn't load on iOS for me.

I run an adblocker and use reading mode frequently. I do not usually suffer any issues with ads even without AMP. It is solving a problem I do not have and creating more problems in the process.

Same here. Media (images, video, etc.) don't load at all and the site scrolls very quickly.

Get used to that scrolling. It is the new default in iOS11 (and a welcome change!)

Can you elaborate on the Reddit issue? I experienced something similar (just a white page, no app opening, etc). Curious if this is the same thing.

I see it too. I think it's my content blocker (I use Firefox Focus). Easy enough workaround: tap the link icon at the top, then tap the link, and you'll open the page directly without Google's bullshit proxying. Still quite annoying, though. Any time I do a Google search and there's a choice of AMP and non-AMP results, I go for the non-AMP ones. I like having pages that load fast and aren't full of junk, but not as much as I like having pages that scroll properly.

Same thing.

I've always said: The problem AMP is trying to solve is very real. It's the way that Google is trying to solve it that is a problem.

What Google should be doing is encouraging the right designs, instead of pushing their own walled-garden design.

Unfortunately encouraging better design won't do much to most of the web. You have to guide with a heavy hand.

I'd strongly disagree. If you hit them where it hurts, they'll change. I'll even argue that we haven't really tried encouraging sites to be better.

If Google ranked load-time/page-bloat much heavier in their algorithm, and started punishing bad pages, then sites would adjust.

I currently see very little action from Google in this direction.

Look at how successful the mobile-friendly push was at getting everyone from vaguely talking about responsive designs to doing it Right Now! Every user-visible benefit of AMP would happen following your comment – increase the weight for page load time/size and add a standard pre-fetch mechanism[1] which would close most of the gap for the CDN hosting.

1. i.e. the top n results will have rel=dns-prefetch tags hoisted into the search result, the top result (or visible/hover/etc.) will have the first rel=preload html/style/script tags hoisted.

> I think AMP pages are 10x better than the ad-filled, slow as molasses, jump-around-as-JavaSript-loads,

Firefox on mobile supports extensions, so you can use UBlock Origin / UMatrix. Also the built-in reader mode makes most sites a much better experience.

>Firefox on mobile supports extensions

Unfortunately this isn't true on iOS as far as I can tell.

Safari on iOS supports adblockers

> Also the built-in reader mode makes most sites a much better experience.

True, but it doesn't improve page load times.

> 10x better than the ad-filled, [...] 'stories you might like' suggested bullshit

Actually I see these on an AMP page too.

Yep

https://github.com/ampproject/amphtml/blob/master/ads/tabool...

You're right but man you get a lot of that browsing with noscript. Reddit is loads faster with noscript blocking all the cruft they wrap around that site and that's not even one of the clickbaity sites.

That's true but it's a band-aid fix. We need to figure out how people can browse the web efficiently while ensuring websites are financially feasible, and everybody simply blocking javascript is not a financially feasible solution. I'd be more than happy to pay cash for a lot of stuff rather than have to deal with tracking/obnoxious ads, but I think the web would be a much worse place if all non-advertisement content was behind paywalls.

I have no idea what a sustainable solution would look like. Something similar to the Brave browser that was actually agreed upon by site owners and users alike, where site owners would turn off all of the BS for people that paid cash?

Of course, that doesn't touch the problem of people using crazy over-the-top, poorly optimized front-end stacks for things that could easily be accomplished with a regular web server and a smattering of Ajax.

"We need to figure out how people can browse the web efficiently while ensuring websites are financially feasible"

I'm trying to figure out how to make JS blocking available to normal end users. Why should users have to put up with the current shitty situation when a simple, technical solution is available that doesn't involve Google or anyone else whose intentions are not aligned with users' intentions? The main challenge is fixing the UI so that it can be used by the least computer literate users.

Make all web sites not require behaviour? This is a classic boiling the ocean solution.

Why not just fork AMP, call it openAMP and then rally around a roadmap that is more fair for the web platform at large (instead of just Google's)?

Without Google behind it how would you drive adoption?

Google won't let you into the carousel

Sounds ripe for a lawsuit

Which is exactly why the EU has 3 (well, now 2) open antitrust cases against Google.

I think that it would be better to use better practices in regular HTML. There doesn't need to be a new markup format -- just more restraint with JavaScript/animations/CSS/advertisements.

Have more optimism. AMP is all about performance and fighting web bloat, which is a real problem nowadays. This is how a typical mobile web page looks like: https://i.redd.it/t6u12tcocx5z.jpg and AMP is a radical but effective step towards the faster web. Additionally, AMP Cache loads content in less than no time and saves bandwidth and load on original servers, which reduces costs.

Publishers want revenue, not fast sites. I think that is the root of the problem.

Instead of AMP a better solution could be to add buttons to browser to disable JS/CSS/Web Fonts (the most useless innovation)/Cookies and let the user decide what they want to see.

Kind of like how selling socks shouldn't require a 60MB video autoloading. Yet http://www.sockfancy.com has a huge video that automatically loads and plays on desktops.

Speaking as someone who uses React: wut?

My companies entire site JS, React and many other modules included, is 220kb over the wire (gzipped).

Site bloat is a thing but it's due to bad developer practice not frameworks or libraries

The single worst offender though for bloat are 3rd party ad networks - Google included/especially. The site often has minimal control over what is put in ad slots.

Start pushing against google to improve their standards for ad payloads and you'll see a massive improvement.

Railing against ads themselves however is, sadly, not too helpful

It sounds like you use React well and it's reasonably light and performant. The current project I'm on has a React frontend where typing in a text box is laggy due to how horrific the code base is. You're correct in saying that React is not to blame only it's misuse, however it is becoming a common cause of slowness.

If it wasn't React it would be [insert any other framework here]. React isn't the cause - bad developer practice is. As you said - a text box is laggy due to how horrific the code base is.

That's not something that is going to be fixed by changing library.

As a predominantly frontend developer, I sometimes (just for giggles) check to see the page load of pages I visit. It always dismays me to see a site's own resources only take 200-500kb of bandwidth... and then all the ads and associated requests take another 25MB. It's quite common and I keep thinking there must be a better way..

Well, there is - but consumers prefer free + ads to micro-payments or subscriptions. Granted there has been pushback recently but that's usually due to gross abuse of ads.

The only realistic way that I see forward are the ad networks (and this includes Google) setting lower maximum payload sizes for ads. Obviously sites can push back on quality and size but it's a hard metric to track consistently given how ad networks serve things.

~~consumers~~ (nay, citizens) prefer to have no ads or subscription costs etc.

The fact is: ad-based model just puts the burden on those most susceptible to advertising. It's similar enough to funding schools through state lotteries in that the money comes from somewhere or the results go underfunded, and if you accept state-run lotteries or anything that looks even slightly like today's ad-based internet, you are talking about a funding source that is deeply and fundamentally unethical.

You say that, but time after time user behavior shows they'll go to the ad supported version.

See also: mobile. You have to totally gameify things to get micropayments to work.

I mean, if you want that for websites, sure... but if you think clickbait is bad now...

"but" is not appropriate. You aren't contradicting anything I said. I'd agree with you completely, but your points are only "and" from my post, not "but".

There are no micro payments out there that would support the site. You'd need to charge something like 0.0005 cents per view. No currency exchange supports something small. In reality, it would make people money. The consumer could limit their account to $20/m.

On the other hand, micropayment would freeze out poor people.

No, poor people would just see ads because they can't pay to remove them. Although I guess that's not a great target market...

AMP pages are regularly filled with garbage ads too.

Try clicking any of the god-awful clickbait AMP pages shared on Facebook, for example.