Hacker News new | more | comments | ask | show | jobs | submit login
Kill Google AMP before it kills the web (theregister.co.uk)
969 points by DLay on May 20, 2017 | hide | past | web | favorite | 462 comments



Ive forced myself to use Bing since google introduced AMP. Do I like it better than Google? No, I don't. But! I like not having google become my single source of content more than I dislike the slight drop in quality as a result of using Bing. I like the sites I go to, to have control over their content and being able to easily link to them.

I think it's reprehensible for google to push this so relentlessly and beyond simply stealing links it makes google into the "internet."

This (AMP) could easily be a standard, in fact it's mostly just common sense (good lightweight HTML/CSS/JS). Instead of Google forcing its way on users and creators it could just lower the page rank of the offenders.

One other thing about AMP that pisses me off as a user and an engineer is it's one more place to maintain meaning one more shitty neglected experience. As a user I hate it when AMP pages are broken and I somehow can't get to the non-AMP version. I don't blame the developers because we have enough on our plate. My anger is solely directed to google for making the damn mess in the first place.


Just as a FYI, Bing is a really large supporter of the AMP project.

“We started experimenting with AMP in our Bing App last May and have noticed that AMP pages load, on average, approximately 80% faster than non-AMP pages” says Marcelo De Barros, Group Engineering Manager in charge of the AMP integration at Bing.

https://blogs.bing.com/search/September-2016/bing-app-joins-...


It turns out that if you strip most of the JS bloat from a webpage and serve it from a fast CDN, the page loads way faster. Shocking stuff.


It's not shocking but AMP enforces it.

People talk a lot of trash about AMP, but until there's another solution that allows me to go to a news website and actually read it, I'm an AMP supporter.


Such a solution has existed for at least a decade: ad blocker :)


Do ad blockers really solve the problems that this article criticizes AMP for? You've closed one bag of worms and opened another one. How can independent publishers live in an all adblock world? State publishers like criticized in the article might survive. You're again centralizing journalism, this time into the few organizations that can get their readers to pay a subscription.


I think that the ones that will best survive in an ad-blocking world would be hobbyist journalists and bloggers. That does not seem to be that bad to be quite frank as it would probably lead to higher quality content, less copy-paste and less clickbaits.


Not really unfortunately. The ones that thrive are the ones not doing it for money. Propaganda, state and commercial, are by far the biggest ones.


What the heck is a hobbyist journalist?


Me. I run http://startupnews.com.au despite making no money doing it (as the plaintive pleas for sponsorship and donations on the site show). The Perth startup community needs it, so I run it.

There's similar blogs for every small community, run by people who care about that community. Usually unfunded, and only covering stories of interest to that community.


> What the heck is a hobbyist journalist?

Shills and Kool-aid-drinking zealots mostly - they are the ones usually motivated enough to do 'journalism' for free. Don't expect any professionalism, depth or any form of investigative journalismbeyond tweet-storms.


They cannot. How can wagon wheel makers live in the age of the car? Their business model is defunct.

We outsourced our opinions and fact-finding to journalists for a few hundred years. Now that time has past. Journalists themselves have destroyed their own industry by producing a poor quality product. Maybe in future journalists will re-invent themselves as purveyors of pure factual reporting, and those that care about that kind of thing will pay for it. But it is a niche market. Democracy, decency, enlightenment and society will suffer of course. But those things were never guaranteed with any kind of real safeguards.


There's more to the world than the US. The press in, for example, The Netherlands and Finland might be opinionated but they're mostly factual and high quality.


I wonder if the clickbait and fake news is an English-language phenomenon, because of the huge potential global market for English-language articles?


> Maybe in future journalists will re-invent themselves as purveyors of pure factual reporting

If you think this was ever the case, rose colored glasses are in effect.


Ad blockers serve minified JS and CSS through a CDN?


Because minified JS and CSS was invented by AMP?

Unless you’re doing tree shaking, which AMP can’t do duplicate, compression has rendered “minification” useless long time ago anyway.


From what I've heard this is false, since for large javascript and css libraries the parsing is faster with minification.


+ reading mode in Safari helps a ton.

But still you are loading ton of unnecessary content. Ad blocking on iOS still sucks (no custom filters).


Custom filters are absolutely possible, it just depends which adblocker you choose to enable. IIRC the block list has to be compiled to a static JSON file for Safari to consume, but most of the decent adblock apps on iOS provide a companion configuration application that lets you insert custom entries then recompile the block list.

If anything I prefer this way of working - Apple alone are responsible for maintaining a high performance adblocker in Safari, the wider app ecosystem just provides the block lists, rather than rely on app developers to write performant browser plugins.


RSS readers ?


Why don't I see a significant difference then? The only thing I've noticed about AMP sites is the pain of trying to navigate them, alongside the dual top bars (reminds me of toolbars back in the day) and impaired functionality.


It feels like the principles (minus the tracking) of AMP should become a W3C spec. Surprised Microsoft and others haven't pushed for this.


What tracking?

I'm not aware of anything AMP does differently than non-AMP with regard to tracking, except that it's declared in a way that allows it to be cached+preloaded without falsely triggering analytics.


When a user searches for an article on Google and clicks on an AMP link it never leaves google.com, even if the AMP link is an external entity.

Repro: 1. Search for some BBC news on google.com, click on an AMP link and load a BBC page 2. Notice that you're still on google.com and not on bbc.com


Actually we could do even better and let the browser do the tracking and anonymize the data.


Checkout Duck Duck Go, still not Google-level results, but it's still pretty good, and not Bing.


Duckduckgo is a lovely idea with abhorrent search results. Like, unusably bad results, at least to the extent that I'm a reasonably tech savvy user. I'm often searching for papers as a grad student, or typing things "close enough" and hoping Google figures it out for me etc. Duckduckgo cannot keep up. I love Bangs, I love the idea, but the search is nigh-useless.

That said, I use StartPage, who have a contract I believe with Google. It's Google's search results, minus the tracking. It's as much as I am willing to compromise on something as fundamental as search.


The results for localized stuff, e.g. a local store, are horrible. The results for complicated questions where the query is either not very specific or the page might not have all words, are also really bad. But if you have a good idea of what you're looking for, which is most of the time for me, it works very well.

At least it's honest about not having results whereas Google presents 5 billion, all of which are missing one of the three keywords (which it notes in a small, light grey text, which you only notice after the first three results were completely unrelated and you were wondering what went wrong).

For example, "new double c++" is the query I did most recently and in the top 3 there are 2 results that answer my question.

Making something up at random like "torrent clients" gives me as top hit the Wikipedia article "comparison of bittorrent clients", which is better than expected.

I can't seem to think of a vague query right now. "audio books" gives me sites with audio books; "psychology books" gives me articles of 'the best 50 psychology books' and such; and looking in my query history, "draw unicode" seems vague but the top hit (shapecatcher.com) is the one I was looking for.

Something localized then: "drankwinkel echt" (where Echt is a place and drankwinkel a liquor store) indeed gives terrible results. The store name, surprisingly, works though: "gal & gal echt" gives similar results to google.nl.


> At least it's honest about not having results whereas Google presents 5 billion, all of which are missing one of the three keywords (which it notes in a small, light grey text, which you only notice after the first three results were completely unrelated and you were wondering what went wrong).

Yes, that's really bad; it's what killed Altavista and could really be Google's undoing.

Still, Google is miles ahead of the competition.

Small experiment: searching for "movie old man balloons" on Google and Bing.

On Bing there is a first line of 4 videos, none of them related to the movie "Up" in any way. The second link is to Up on Imdb (good). The 3rd link is to a crazy religious fanatic site page titled "Disney PIXAR's, 'Up' - The Sugarcoating of Pedophilia!" (WTF??!? - but at least related to the movie). The 4th link is again to a youtube video with no connection to the movie.

On Google, the first 8 links are to the movie. There is a line of images, all from the movie / movie poster. There's a list of 4 questions "People also ask" that shows questions about the movie ("How many balloons would it take to lift a house?"). To be fair, the crazy Baptist site does show up on Google too (God has good SEO!), but way down below the fold.

Anyway, my point is, when answering the question, Google is certain you're looking for information about Up, and tries to give it to you.

Bing seems to have doubts and tries to guess if maybe you're looking for a funny video of a man in the subway wearing a balloon hat (??!? it's not a "movie"!!) or the hit song "99 Luftballons" from 1983 (not a "movie" either!)

Bing tries hard, but is obviously more than a little clueless.


> Small experiment: searching for "movie old man balloons" on Google and Bing.

Your experiment's results are not repeatable. When I do that here:

* Bing gives me 8 pages about Up (including that spoof site), one about Danny Deckchair, and a page about a magician who re-creates old movies with balloons.

* Google gives me 13 pages about Up (also including that spoof site), a book of best movie scenes on its page for The Third Man, and an article from The Rotarian from 1948.

Of course, some knowledge of how these things work teaches that this is a terrible methodology, given that it does not account for the fact that both Bing and Google tailor their search results to the searcher. One should at the very minimum log out of one's Google and Bing accounts, which you made no mention of doing.


>crazy religious fanatic site

FYI, Landover Baptist Church (which that article is from) is a very old, very well known spoof site.


Oh, thank you, I didn't know that. It seems real enough.


And a canonical example of Poe’s Law in action.


Yes. But the fact that it's a parody of fundamentalist Christianity makes it a very bad result, because it's a comment on religion (or fanaticism, or Internet culture, or what have you) and not about the movie itself.

A perfect search engine would not return this on the first page of results about the movie, because it's not about the movie.


> The results for localized stuff, e.g. a local store, are horrible... But if you have a good idea of what you're looking for, which is most of the time for me, it works very well.

That's a spot-on description of Altavista :)


DDG "worse" search results are also a product of you not being profiled. Or to put it in another way, Google better search results are also a product of all your habits being gathered and analyzed. Sadly we can't have a search engine that knows nothing about us and guesses at the same time what we are looking for. DDG can give better results, but this require being more specific when searching.


I'm not sure this is true. Google results are still amazing when used at a friends' or a public computer and not logged in, etc. (not to mention incognito mode, which you could argue still profiles you through your ip).

Other search engines feel like a noob salesperson who needs to be told 5 times in 5 different ways what you need -- and it's really simple stuff too.

I like experienced salespeople.


Google results get "better" (depending on your definition of better) as you go in very specific ways. When I browse I clear cookies every time a tab is closed and I never log into Google just for searching. I've noticed at work I'll be googling for programing stuff and if my session gets "stale" (been doing a bunch of searches without closing the tab) I notice Google starts making assumptions about what I want. For example, if I Google a generic programming term say "string," on a stale session Google will assume the string I want is programming rather than, say, crafting or physics, and the string I want is the language I've been Googling in my last few search terms. So if I googled "string" in a fresh session I get a couple generic Wikipedia pages and some references from various programming language. If I Google "string" in a stale session Google "knows" I'm looking for the Java string so they will show me Java string results. If I wanted those same results I'd have to Google "Java string." It does make you lazy at searching though because you start thinking "Google knows what I'm talking about."


DDG could still profile you via an account and just not sell the info to advertisers. Incorporate in Germany for the strong privacy protections, et voila :)


In my experience, DuckDuckGo just requires a habit shift. You're used to Google knowing everything about you and utilizing that to provide you catered results. Be more specific on DDG and you should be fine.


This was my feeling as well. Try using Google from a public library and it returns results similar to DDG.


Not at all. I'm not logged in to my Google account at my day job and I still got relevant search results when I arrived. DDG wouldn't after months of use at home.


You don't need Google account to be profiled by them.


How else can they profile me in a brand new job, in a brand new Windows installation, in Firefox, if I'm not logged in? The organization I work for has a lot of different job types and we're all proxied through the same external IP so they couldn't even profile my job type.

I got relevant results in my first day there. I didn't notice a drop in result quality.

Google is just that good even if I hate to admit it.


There's still a limited number of job types at your workplace. If you search for "django" odds are none of your non-technical colleagues have been searching for anything other than the Python framework at work.


Fair enough.


It has greatly improved over the years. I remember it being unusably bad when I first tried it in 2013, but today I only have to revert to Google once in a while. That being said, there are rare occasions when it fails spectacularly, bringing up totally irrelevant results for simple searches.

It seems to expect more precise queries, while Google is geared toward "close enough" searches. I've found that DDG is often preferable when I have an exact phrase in mind. Google is sometimes too helpful, correcting errors that are not actually errors and failing to take some queries literally enough.

The main issues I have with DDG are that it doesn't seem to prioritize recent results (which can be good, but usually isn't) and it fails at local results, which is basically by design.


>Google is sometimes too helpful, correcting errors that are not actually errors and failing to take some queries literally enough.

While I am still personally a huge fan of Google's work in this are and many others, sometimes I long for the days of straight boolean search queries in search engines. I could often find exactly what I'm looking for, and get the same result each time.

Are there any other major or effective engines that allow for boolean queries beyond AND/OR?


A full set boolean queries, while useful for specifying a query, are likely far too computationally expensive at scale. The reason you don't see most major search engines abandon them is because the resources are better spent investing into heuristic algorithms that benefit a majority of the userbase.


I just saw this now. Thanks, that makes sense. Just the same, I still miss the utility of it!


DDG feels like it's still using Google's early algorithms, whereas Google has moved to prioritising more question or natural-language based searches recently.


You use DDG as your default engine. For most common searches it works fine, particularly nice is that if there is a wikipedia entry it will show it right there. When you have a tougher search and it doesn't work you just slap a '!g' or a '!b' on the end and turn it into a google/bing search.


Maybe you're searching for something really niche, but I use DDG and have no problem with its results. If I can't find what I'm looking for, I can always use !g to check google, and most of the time google doesn't have the answer either!


Scary to think that there is only a single website that provides good "something as fundamental as search"!


It is actually Bing, which DDG uses for the bulk of its results.


Well, I learned something today.


It used Yahoo last I checked.


And Yahoo uses Bing.


I didn't know that. TIL


Yandex?



[2009]

nowadays Yandex uses its own index even for “foreign” (non-Russian) sites.


It really is as good as google for most things, in my experience. I use it by default and when it can't find what I'm looking for, Google usually doesn't do much better.


one of the last areas I've found myself going back to google is when I'm searching for a gif... Duck Duck Go will return them, but it is usually a very small subset of the available gifs out there.


After 2 attempts it's now my default search "portal". As other said, generic results are low grade. But the bangs and the "control" are worth this loss. I can search really fast on dedicated websites !yt !gi !gmaps !wbm (waybackmachine) and I don't have to worry about what's going on most of the time.


Can only second ddg. It's not perfect but I usually only have to use "!g" (ddg syntax for search on Google) every two days.


For past few years, I go to try DuckDuckGo every once in a while (especially when someone suggests that again on HN), but it disappoints me every time with the quality of search results.

Also, if it is using Bing on inside, I'm not then sure why the results are still different than that(even at the places where there's no scope for personalization). For example type this line exactly in both bing and ddg:

difference between std list and std set

The first result DDG shows is of a difference between set and a vector - not only that, it also highlights that result in a Google Card inspired fashion (which is worse because Google does that only when they have a certain amount of confidence in the answer), while the first result Bing shows is an actual difference between list and a set. So either Bing is cheating DDG, or DDG is doing something stupid on top of its results. (Also, if you cover the above string in quotes, Bing still shows 'some' search results, while DDG doesn't).

May be after using the '!' ninja techniques it'll be same as Google, but then I have also come to love the fact that I can type in 'my next flight' or 'Show me emails from ....' or 'remind me to ... ' and other personalized things on Google so may be my priorities are different here.


Sounds like your priorities are different; and that's fine. DDG doesn't parse your emails so it doesn't have your location, flight info nor a lot of user data to build personalized results. I like it a lot, it's gotten much better but it requires adaptation when coming from Google.. or just !g


I tried Duck Duck Go exactly because of the AMP issue. Its search results are bad enough that I couldn't keep using it even though I wanted to. I'm on Bing for now.


I get identical results from DDG and Bing, and that isn't surprising because DDG's search backend is Bing.


I really don't ex: "ice cream calories" share several but not all sites and use a different order for those they share, which just suggests similar algorithms.

PS: DDG redirected image searches to bing, but not generic searches. Which honestly seems reasonable as doing image search well is incredibly hard, with minimal payoffs.


Nope, for that search I once again got the same results in the same order.

It sounds like Bing is personalizing your results either by location or by adtech tracking, which is kinda antithetical to the point of DDG.


And specifically why not Bing?


Bing just feels gross to me, just like Google. But as someone pointed out, I guess DDG uses Bing for some of its results, so I don't have much of an argument here.


I've switched to Bing on my mobile as well.

My contract with a search engine is that they should provide links to other sites in a relatively painless way. In exchange for this the search engine can track me while I am on the site.

AMP breaks this relationship by refusing to let me leave the site and extends tracking to other sites. The speed difference is negligible to me and not worth this violation of privacy.


DuckDuckGo.com instead, for so many reasons. First, privacy aware. Their index is fine. They don't hide their tale and run, hiding behind captcha's and turning their users into slaves, when it comes to confronting bots: https://twitter.com/cyphunk/status/849615910545620992 (vid comparison of using google via tor vs using duckduckgo)


I've become a pretty big fan of StartPage. Same Google search but without all the tracking.


FWIW, you do get a link on the AMP page to the canonical URL now.


I am kind of shocked to see this be the top comment on this story, I remember getting shit on thoroughly everywhere for daring to point out how awful this was back when it first came out, seems like people are FINALLY willing to be a bit more skeptical of Google's actual intentions given their shady and abusive track record.


The internet is going to be all AMP and PWA soon, so everything is served from google or on the app store. Enjoy! /barf.


I think you've misunderstood what PWAs are? PWAs are fundementally websites which are built on a bunch of guidelines with performance and accessibility prioritized.


And if you follow those guidelines and with the right meta data, they get treated specially by certain 3rd party, like google/android letting you update them in the app store.

Just like AMP are fundamentally websites built on a bunch of guidelines with performance and accessibility prioritized which, once you sprinkle them with enough metadata, get treated specialty by third party like google.

Yeah, I don't think I misunderstood. AMP's guidelines are just more strict before the 3rd parties start treating you specially. And in both cases, the original website/app is just fine, until it starts getting treated specially.


> like google/android letting you update them in the app store.

Update what? What do you mean by "app store"?


sorry, terrible choice of words on my part (more like the world's worse freudian slip, as I was thinking "like apps in the app store). I meant that they're going to show up like any other app in the app list, settings to be tweaked/modified/deleted and so on.


Why not DDG? I switched to it recently and I am enjoying the !bang searches.


Use ddg.com.


no. dont use it, hands were faster than brain. the adress is ddg.gg. sorry.


> Google has no respect for [iOS Safari]. It’s a deliberate effort by Google to break the open web.

I could make the same argument that Apple cripples iOS Safari's implementations of emerging standards that aim to bring the web experience closer to a "native feel" to keep its app store revenue churning:

http://caniuse.com/#feat=stream

...but really it's a lot more likely that getting _all_ things right on _all_ platforms is the really, really hard thing about the web, for browser vendors and web developers alike.

Never attribute to malice that which can be adequately explained by incompetence (or in this case, sheer overwhelming difficulty).

https://en.wikipedia.org/wiki/Hanlon%27s_razor


But also:

sheer overwhelming difficulty + no incentive = no action


With respect to scrolling: We (AMP team) filed a bug with Apple about that (we didn't implement scrolling ourselves, just use a div with overflow). We asked to make the scroll inertia for that case the same as the normal scrolling.

Apple's response was (surprisingly) to make the default scrolling like the overflow scrolling. So, with the next Safari release all pages will scroll like AMP pages. Hope Gruber is happy then :)


Another bug I've noticed is that AMP breaks in-page searching with iOS Safari. If you perform an in-page search, the browser will not scroll to the found instances of the search term on an AMP page. I imagine it's related to the other scrolling issues.

Please, please fix this. It's impossible to support something that's foisted on us and breaks basic web functionality. If I were cynical, I'd say bugs like this are designed to degrade the web experience on iOS. There's a lot of bad web programming out there, but very few sites manage to break search.


I believe we have a webkit patch pending for this. Definitely on our radar!

Edit: some detail. Safari sometimes doesn't scroll find results into view when they are in overflowed space. This issue actually affects a large percentage of web pages. Fixing it was very easy, was just an oversight in WebKit.


Great. Thank you for submitting the WebKit patch, and sorry for heaping the blame on you guys. Looking forward to the update.


On top of this: we currently have a team working to fix webkit bugs that are problematic for AMP. This, of course, will make webkit better for everyone.


Can you team also work on a way to let people opt-out of Google AMP?



Is that really Apple's stance? I find the scrolling to be the #1 reason why I bounce from AMP pages. I would hate for them to make this a system wide behavior.


In current iOS Safari, webpage scrolling is inconsistent from all other scrolling on the system. This was an intentional decision made long ago. In addition, overflow areas are consistent with the rest of the system, and thus inconsistent with top-level webpage scrolling. This is semi-accidental. In reviewing scroll rates, we concluded that the original reason was no longer a good tradeoff. Thus this change, which removed all the inconsistencies: https://trac.webkit.org/changeset/211197/webkit

Having all scrolling be consistent feels good once you get used to it.

That doesn't necessarily mean it was a good idea for Google's hosted AMP pages to use overflow scroll all along. The inconsistency definitely did feel weird. And the way they do scrolling prevents Safari from auto-hiding its top and bottom bars. I believe all the desired scroll effects could have been achieved without the use of overflow scroll.

Edited to add: the AMP scrolling model also breaks tapping the top of the screen to scroll to top, and this won't be fixed by scroll rate changes.


I figured that the different rates had to be intentional, but I did wonder why. Thanks for the explanation. I remember the checkerboard background on the 3G when you were scrolling too fast, if the speed was faster I mention it would've been way too easy to hit that.

It never occurred to me that Safari page is what the outlier, I just assumed that Safari pages matched the rest of the system and iframes for the thing that we're off.

Maybe this won't be as hard to get used to as I feared.

Thanks again.


Is there a way how the behavior could be implemented in software to match default?


Thank you for sharing this information!


Yeah, I don't care either way. But Safari should have the SAME scroll inertia for every scroll context and ideally it is the same as used for native apps.


Yep, I agree with you. It should definitely be consistent across the board.

Oh well, maybe I'll get used to the inertia scrolling. I'll give it a shot when they make the system-wide change.

For now though, the different scrolling experience on AMP (and some other pages) is jarring to the point that I don't even bother and I just bounce.


It feels like putting inertia control options in a browser was a big mistake in first place.


There are no such controls. There are just different places where one can scroll. All other browsers (as far as I know, and this includes Safari on desktop) make all of these the same, but mobile Safari chose to make them different.


The snark at the end seems very unwarranted.


Sorry, but there is some irony there. We were as surprised as anyone. I do like the new inertia much better. Allows for much faster scrolling similar to Android.


I don't think there's any irony here. You deployed something that worked horribly on iOS, you didn't offer a way to opt out, and when someone else put in a fix for your terrible UX that just happens to change everything else to the way your stuff currently works you use it to gloat and a guy who pointed out how terrible your UX was.

Honestly this whole thing (AMP and your comment) come off arrogant as hell to me.

I like the current iOS behavior because it's what I'm used to. I don't find the slower scrolling speed to be an issue at all. But if everything really is going to change then I will probably annoyed me for a while but I'll get used to it.

I'm not complaining that the scrolling behavior on AMP is too fast specifically (although that's how it feels to me), I'm complaining that it's DIFFERENT from everything else. All my muscle memory of how to scroll things is broken on AMP pages and only AMP pages. (I don't care if it's how iframes work, you deployed it anyway)

Once it feels like the rest of the system then it's not really much of an issue anymore. I'll get over my personal preference.

But the snark was totally unnecessary.


Well, they deployed normal HTML5, which because of how the page was defined happened to expose a weird interaction in how iOS performed some actions. They thought it was a bug in iOS and treated it as such. Getting called out as assholes for doing what they thought was the right thing (and by someone that was wrong on the facts to boot) probably rankled a bit. Calling out Gruber as both wrong and in addition so wrong that the company he thinks was maligned is actually changing to the behavior he dislikes does come off as a little snide, but given the facts I wouldn't hold it against them. I definitely wouldn't use arrogant to describe it.


They didn't explicitly set the behavior that way, but they deployed it knowing that WAS the behavior. And they didn't bother to change it or give anyone an option to turn it off or do something else making everyone on iOS suffer since they started pushing AMP.

They could've just as easily pushed you to a new page which contain the AMP content and wasn't an iframe, thus leaving all the standard feel and gestures working. Instead they choose to go along with what they were doing on android even though it was severely sub optimal on iOS.

I think choosing to do that WAS arrogant.

They made Google significantly harder to use as an iOS user because they didn't care and gave us no option to try and fix it.


I don't have an iPhone, so I can't check the actual behavior to see how broken it is. Is it just not fitting the Norms of the platform, or does it really impede usage?

I think the "correct" response in a case like this, where the platform owner has a bug and has committed to a fix in the pipeline for delivery, is highly dependent on the problem. Even then, it's possible to make the wrong choice given the information available at the time.

I prefer not to call the actions of a company and a group of people arrogant without more info than present, even if one of those people expressed a less than sympathetic opinion of the problem. I extend the same courtesy to Apple often enough, it would be hypocritical of me not to.


I don't think it was a bug, I think it was an intentional choice by Apple but I don't think it really mattered to most people untill AMP started using it.

The big problem with that that only exists on iOS is that the 'weight' of the content is much much less than normal web pages. All your muscle memory of how far and how fast to move your finger to get the page to scroll a certain amount is wrong. Instead the page scrolls MUCH faster and further. This would be bad enough except you're still technically on the Google page and as soon as you go back or close the AMP result the scroll speed is what you're used to.

The end result is it's incredibly frustrating and feels "broken".

I understand that Google's preferred solution caused a behavior that is severely sub optimal because of the way Safari currently works. My problem is I think they handled this extremely poorly and forced all iOS users to deal with it for what, over a year?

I'm glad apples fixing it but I don't like the way Google handled it... effectively saying to iOS users "too bad" since they didn't do anything to mitigate it while waiting for Apple's fixed to come through the pipeline.


> They thought it was a bug in iOS and treated it as such

The majority of end users don't know anything about divs and iframes and don't care whose bug it is. So the question remains-- since they clearly know that this bug exists, why would they ship like this?

Every time I land on an AMP page on my iPhone, the scroll gets out of control and all of a sudden I've unintentionally followed a link to some video that starts playing with sound. It's ridiculously annoying.


This is amazing.

A hypocrite (Gruber, as evidenced in another thread) calls the AMP team hacks who do terrible work. Turns out their "terrible work" is actually Apple's bug and the AMP team points this out both to Apple and to Gruber. In your eyes, this makes it all their fault.

When called out on it, you double down by saying that the team is still to blame because they chose not to work around Apple's bug. You basically want Google to be part of Apple's captive audience.

No, seriously, take a step back and consider that this is what you're saying.


>A hypocrite (Gruber, as evidenced in another thread) calls the AMP team hacks who do terrible work

I must have missed this. When did Gruber call the AMP team hacks?

> Turns out their "terrible work" is actually Apple's bug and the AMP team points this out both to Apple and to Gruber.

This is flat out disingenuous, unless you're talking about something other than the originally submitted DF article. There were multiple examples of why Gruber thinks AMP sucks. Are you claiming that all of them are "Apple's bug"?


> When did Gruber call the AMP team hacks?

The link of this thread was originally [0].

Although he didn't use the word 'hack' himself, Gruber said:

"Google has no respect for the platform. If I had my way, Mobile Safari would refuse to render AMP pages. It’s a deliberate effort by Google to break the open web."

So he sees them as intentionally sabotaging things.

0: https://daringfireball.net/linked/2017/05/20/gilbertson-amp


Indeed, that's in alignment with what I had seen. It seems obvious at least to me that the actual character of Gruber's statements and @julianmarq's portrayal of those statements do not agree.


> Are you claiming that all of them are "Apple's bug"?

Let's see:

- find in page: yup, Webkit bug (Google/Chrome uses Blink).

- scrolling behaviour: yup, Safari bug.

Anything else that I missed?


It was an intentional decision, not a bug:

https://news.ycombinator.com/item?id=14386292


> This is semi-accidental.

I.e., "not design decision".


And how would you characterize Google's decision to ship it in this state, knowing that the behavior was broken in iOS Safari?


You don't think there's any irony in the fact that Google noticed that Safari was behaving badly sometimes, and asked Apple to fix it, and Apple said "wow thanks for pointing that out, we're going to make it much more extreme". Google asked for one thing, and because of that was given the exact opposite. That's pretty much the definition of irony.

>a state of affairs or an event that seems deliberately contrary to what one expects and is often amusing as a result.


I wouldn't have expected Apple to speed up the scrolling on everything else if that's what's really happening, but I don't find it amusing.

As I said another comments though Safari was doing exactly what it was designed to do (for whatever reason they designed it that way). I don't think this is a bug on Apple's part. It makes sense to harmonize the scrolling behavior, but I don't believe it was unintentional.

Now I understand what someone was talking about when they said this might be ironic. I wasn't even sure what they were referring to. I can't place my finger on why this doesn't seem like irony to me. Maybe it's just not odd enough.


> As I said another comments though Safari was doing exactly what it was designed to do

Apple seems to disagree with you, though. I would trust Apple to know better what Safari was designed to do.


Snark? I think we're reading two different comments. I think it's fair to share surprise at a response like that from Apple. I would be surprised, too.

It almost feels like you're looking for reasons to be upset and finger-point. I hope that's not the case.


I took their original remark at the end as a snarky comment about Gruber. I didn't read it as being about the way Apple decided to fix things. If that was the intent it was unclear to me.


Sounds like Apple's underinvestment in mobile Safari makes it currently impossible to implement this well in web pages in iOS, and that the AMP team is working with Apple to fix their broken platform. I don't see how this isn't Apple's bug.


Under investment?

I'm not sure it was a bug, it sounds like it was a design decision. Maybe not in GOOD one, but I doubt it was a true bug.


Why? What reason do you have for this belief of yours?

Apple's response indicates it was a bug, and nowhere has Apple said "this is a design decision we are now changing".


It's hardly AMP's fault that safari scrolling is inconsistent. Any complaints about that should be aimed at safari, not AMP.


The way Safari does things is not their fault.

That they chose to ship that way instead of using an alternate implementation that didn't run into the problem ( or was less frustrating or provided an opt out ) was THEIR decision. They're not 100% blameless in this.


> You deployed something that worked horribly on iOS

Except that thing was a bug in Safari. They used perfectly valid plain HTML without any hacks or JS.


It wasn't a bug in Safari, that was simply the way the scrolling behavior was implemented in iframes.

It was still there choice to deploy using iframes knowing that that was the way it felt. They could've use JavaScript to load the contents into a div or simply pushed so far users to a page that had nothing but the AMP content on it.

They left it severely sub optimal and decided that was good enough… making google significantly more annoying to use on iOS than what it was before.

That was the choice they made and stuck too. No options to turn it off, no options to do it a different way; you just get stuck with it.


It isn't related to iframes directly. Iframes in mobile Safari are never scrollable. The div thing you suggest would have the same issue. If you are a web developer you likely have built a website that has this issue.


Ah. I mostly do back end work, the front and stuff I do we haven't spent any time on optimizing it for mobile, only desktop browsers. I'm not familiar with the quirks of mobile browsers. I only know the iframes scroll oddly because I've been told that was why AMP pages feel weird on iOS here on hacker news before.


If you haven't done much front-end word, let alone handled quirks of mobile browsers, consider listening to other people on this thread instead of arrogantly pontificating all around.


So because I don't know the intarcacies of mobile web development I don't get to have an opinion on the UX of a website I use every day?

So my top-of-the-head guess of something that might avoid it based on what I thought the problem was from other HN discussions wasn't right. What a sin.

That doesn't invalidate my experience or frustration as an end user.


>It was still there choice to deploy using iframes knowing that that was the way it felt.

So you're blaming Google for not writing around an edge case bug that exists only on one platform?


You call someone's work "terrible" (twice) to their face and now you're upset over a little bit of snark?


I didn't like what I saw as their snark. When they replied they didn't apologize for it or even mention it, they just explained that the scrolling behavior was changing again.

My second comment was because I thought the original behavior of implementing AMP the way it was and forcing it on users was arrogant and has seriously annoyed the hell out of me since it originally started appearing on iOS. I've literally considered switching search engines to get away from it because it makes using Google that much harder.

Yeah, I called it terrible to their face. Because it frustrates the hell out of me. I've tried finding ways to contact google, I've tweeted at them, I've posted in previous discussions. At no point did anyone ever seem to wake knowledge the problem other than seeing people (who I assume we're not googlers) basically say it's not their fault because that's the way Apple implemented iframes.

Combined that arrogance with what I see as rudeness... and yeah. I said terrible twice. I'm frustrated as hell at this and don't like that the solution will be "it's going to stay there but Apple is going to make it a little bit better for you".

When the scrolling gets fixed? I'm still gonna be annoyed as hell at AMP pages. They break the experience, but now just a little less. Hurray.


nobody wants that. we like the way iOS scrolls and there's no reason for some pages to work different because you are imposing us an unwanted feature we can't disable and makes google impossibile to use. please remove this AMP thing. it's breaking the web - and the scroll is just the minor problem.


Maybe Gruber's comments about AMP's scrolling implementation were hypocritical (or naive, at least), but this isn't the biggest problem by far. Considering that Apple addresses what needs to be fixed in terms of how the web behaves on its browser, there's no reason for me to be unable to search for text on an AMP page or scroll back to the top on I tap the status bar on my phone.

I know, those are native platform affordances that the web doesn't need to care directly because iOS is not an open standard. But neither is AMP.


What are you talking about? Who is Gruber? And there is nothing in the article about scrolling.


A little bit before 2017-05-21T00:52Z [1], moderator sctb updated [2] the submission's URL from the original blog post by John Gruber [3], to that of an article in The Register penned by Scott Gilbertson. Gruber's post quotes Gilbertson, and supports its main premise, but offers its own perspective.

Changing the submission URL is unfortunate, because a lot of the discussion in this thread prior to 2017-05-21T00:52Z pertains as much to Gruber's material as the Register article. Now a lot of this discussion, as you seem to have noticed, appears out of context.

[1] https://hacker-news.firebaseio.com/v0/item/14385185.json?pri... [2] https://news.ycombinator.com/item?id=14385185 [3] https://daringfireball.net/linked/2017/05/20/gilbertson-amp


The link was originally https://daringfireball.net/linked/2017/05/20/gilbertson-amp which complains about scrolling.


I have to agree with him. AMP's different scrolling behavior in Safari makes me avoid it entirely--it's the same reason why I avoid using Chrome in iOS.


Google needs to kill AMP. Like many other teams in Google they are filled with arrogant people who believes everything Google have to become "standards" and don't give a damn about how they are being arseholes on other platforms.


Can you add an option to bypass the AMP version completely? Google search is mostly ruined on mobile because everyone has jumped on the AMP bandwagon


Wouldn't this line of CSS:

    -webkit-overflow-scrolling: touch;
have addressed the issue?


That line causes the observed behavior. But it improves it over not being present.


Haha- that is hilarious


Please don't "fix" the "bug" that disables the "scroll to the top of the page when the user accidentally taps the top of the screen" behavior. I loathe this behavior, have never summoned it intentionally, and can't imagine why anyone would ever want it.


Really? I use that all the time. How else do you get back up to the top of a long list?


I'm not sure I've ever needed to do that in all my life. But about three times a day I accidentally lose my place on a long webpage and there's no Undo.


When scrolling itself is faster (as is currently the plan for iOS) the gesture is needed less, I assume, since one can just fling up.


I actually loved that feature on iOS. I have an Android now and miss it in Chrome.


In theory* I don't mind the idea of having a more standardised subset web page that has a consistent internal structure and that renders quickly.

However, having Google load this structured content and host it on its own platform is a terrible idea. Content should remain on the publisher's site. Putting too much content in one place is dangerous for competition.

* In practice there are implementation problems too, e.g. those mentioned in the linked article.


It's worth pointing out Cloudflare has a competing AMP serving tool: https://www.cloudflare.com/website-optimization/accelerated-...


I haven't yet seen a non Google hosted AMP page in Google's carousel.

Does that happen? If not, it's somewhat telling.


No, it does not happen, nor will it ever because that's fundamentally not how AMP caching works. A site doesn't pick an amp cache like they pick a hosting provider, with some sites cached on cloudflare-amp while others are hosted on google-amp. All amp content is on all amp caches. Google search is one AMP client, and it uses google's AMP cache. If, for example, bing wanted to serve AMP pages, they would need to choose an AMP cache to serve them from, and cloudflare's offering would be an option. One of the problems that AMP is trying to solve is individual websites hosting on insufficient architecture. If each site was allowed to choose what AMP cache it was served from, that would defeat the purpose. It's up to the client to choose the cache it uses, to ensure a consistent speed.


That's pretty much the point I was making. The wording from Google to publishers doesn't make this clear.

It is the implementation they chose, and it does have speed benefits. But, an edge cache that allows the end user more control, their own domain, an no hijacking header is possible, and would provide a notable speed benefit. If there were a choice between the two, publishers would likely pick the latter.


Publishers had a choice, and they overwhelmingly chose to host their sites on infrastructure that was too slow. That's why the AMP project exists, to take choices like that away from publishers, because they consistently make the wrong choices when you give them one.


Seems to me the right approach would be for sites to embrace the HTML5 semantic tags (<nav>, <article> and so forth), and browsers to offer a way to view just that semantically-marked-up content - without scripts, with restricted CSS, and maybe with some kind of filtering out of third-party content. Something like Firefox's "reader view", but including more bits of the page.

So the browser would still be downloading the exact same HTML document (straight from the publisher's server, how you want it) - just then ignoring all the clutter. Compare to AMP, which AFAICT necessitates serving a whole separate version of the page with only the blessed markup... it reminds me of the bad old days, having a separate mobile site instead of a single responsive design for all devices. All seems rather antithetical to that grand ideal of separating structure and presentation.


An idea I've been floating for a while is to have two HTML profiles in the future. Call it HTML6 document and HTML6 app.

HTML6 document is a restricted subset, similar to what you suggest. I would still allow complete design flexibility, and I might even allow a subset of JS, but only for presentation purposes. Definitely not turing complete, and no ajax etc.. Probably I wouldn't allow cross-origin resources with credentials. So you could include an image or stylesheet, but the browser would not send along cookies. What I'm aiming for is a replacement for PDF, something you could read on an ebook, etc.. Just a plain document.

On the other hand, I'd have HTML6 app to be able to use the complete web platform.


This sounds good as a dream, but in reality it would actually achieve anything because everyone, including the publishers, would just use 'HTML6 app'.


You can make light web pages with current technologies but nobody wants a page without advertisement, popups, analytics and notifications.


HTML6 document is essentially epub, which is HTML and CSS under the hood.


Isn't that pretty much what AMP is? IIRC, you don't need a separate version of the page with only AMP on it - Google's cache just extracts only the AMP parts of your page when caching. Or has this changed since I saw it? (And if so, why - that would probably also be an argument against your solution :) )


Right. Here's the problem and confusion with Google AMP: it's actually two seperate products.

1. There's the HTML/CSS/JS library/subset that's a good framework for building pages that load quickly

2. There's the 'CDN' that integrates with Google Search to preload and 'iFrame' the site in. Google 'has' to host/'iFrame' the content in their own google.com/amp pages because that's the only way to preload a page to make it display instantly.


> I don't mind the idea of having a more standardised subset web page

We already had this two decades ago: WAP, its contemporaries (i-mode), and its immediate successors (XHTML Mobile Profile).


Sure, and those were good solutions for the time - nothing wrong with similar approaches in a modern context.


Big difference was that these had custom renderers. AMP renders in any web browser since they are just web pages.


Except mobile Web adoption in 2002 was poor because of form factor, among other things.


Oh sure. Though I'm not actually trying to criticise the idea of a subset, if anything I'd support it. I'm just pointing to potentially useful precedent. It's not a new idea.


>However, having Google load this structured content and host it on its own platform is a terrible idea.

Google isn't the only party running an AMP cache.

> Content should remain on the publisher's site.

It does. Its also cached by aggregators, and AMP is designed to take advantage of being accessed from a shared cache.

>


That exact caching has to end.

They can offer to do a CDN like CloudFlare, but make it optional.

I want to ensure that not a single bit of my data ever runs through Google's infrastructure, while still getting all the same benefits as if it did.

If Google treats sites different just for using an AMP Cache, then I'll have to send another complaint to the EU Antitrust committee.

My pages actually increased their loadtime tenfold when I tried them with AMP — they're tested on a HUAWEI IDEOS X3 on 64kbps GPRS. AMP increases load time to over a minute. (On a modern phone, with a modern connection, my pages are obviously also faster — I'm also testing with a Nexus 5X on 100Mbps 4G)

I can't just massively increase load time for pages just for a better ranking in search results, this shouldn't even be a choice.


Google using their search monopoly to create a distribution monopoly is also extremely worrying.


Nah man, it's all good. I mean sure, we keep giving absurd amounts of power to an ad company but it's google, who doesn't love google.

If it was microsoft they already would have shut this down because of the backlash. Google does it and people are fine with it.


Isn't that an antitrust move by google?


> Google using their search monopoly to create a distribution monopoly is also extremely worrying.

Google is using any means possible to keep the web (html, js, css) relevant in the age of native apps (that includes Facebook app running on Android). If the web stays relevant, the same goes for Google search.


In contrast, I think google is making every effort possible to direct people away from the web and into the Google ecosystem. Searching for maps? Google. Searching for flights? Google. Searching for information? Google. The list goes on, and the technical means for delivery is essentially irrelevant.


Rich snippets is the catch all for everything else.

You can see a preview for what that means by checking out Wikipedia's traffic decline over the last 3 years or so.


To be fair, at least in wikipedia's case, that's potentially a good thing. Wikipedia isn't ad-supported, so having their data hosted elsewhere isn't actually a problem (as long as credit is given and so donations continue), because it becomes less expensive for them to host.


Definitely trying, but overreaching. The public is starting to cut out Google/the middleman and it's really just forcing shoppers into Amazon's ecosystem, those searching for flights to Skyscanner etc.


> Putting too much content in one place is dangerous for competition

Considering we're on the precipice of a global authoritarian-populist cycle, there are non-market consequences to such concentration, too.


What is an authoritarian-populist cycle?


Brexit, Trump, FN, Erdogan, etc.


What makes you think we're on this precipice?


I'm surprised if you think otherwise.

WE are on the mercy of few SV companies and whatever they decide or push is our fate.


> Putting too much content in one place is dangerous for competition.

Only in this weird world of third-party-served-js-ads.

In an ideal world, I wouldn't care about where my content is served from. I just care 1) that many people see it, and if it is commercial 2) that I get money for it. I could just add some ads as inline to my article, served in the same way as my article's illustrations are. Not sure google allows that, though. Wouldn't surprize me if not.


I didn't realize AMP content was hosted by Google.


The original content is still on the website, Google hosts a cache server, rehosting the website's content around the world closer to the users for faster access, for free.

In theory, it's a win-win-win situation. Publisher gets free hosting (with analytics and ad money still coming to them obviously), users get a faster experience and Google is happier if the users browser more content.

In reality, AMP is obviously not perfect but they have been addressing common issues and improving. I may not be fully sold on it yet, but I don't understand the massive blind hatred.

Saying "people can just optimize their website" doesn't mean shit. They've had years and no one has been. Sites have been getting slower every year despite browsers getting faster. No one gave a single shit until AMP came around...


The main problems I have are that it breaks two really important web features: sharing links and trust. Users seeing google.com URLs means they trust them more, which has helped propaganda sites and phishers.

The other thing is that for me, AMP has not been faster many times. I know they're working on it but having to download and run 100KB of external JavaScript before rendering frequently meant that it was slower than the real page. It helps the stragglers but e.g. WaPo or NYT load just as fast and that should be enough.


Tap the link icon at the top of the page. Then long press the URL that appears. Or short press it then use your browser's share menu.


I'm aware of that but it's new – it took a year to add, giving many time to develop a negative association with the icon – and it's still clumsy compared to the standard web experience.

With real web pages, the native sharing UI just works as it does everywhere else.

With AMP, you have to know to tap a different unfamiliar icon and then know that the unstyled URL displayed is actually a link you can interact with. That means that sharing goes from one tap to 2-3 and that's after people learn that Google gives substandard results doing what they're familiar with and so you need to remember to do something else only for pages which you found on Google.


That's also not an alternative — Google can't be allowed to treat pages different in their results just for using Google's AMP Cache.

An AMP page served without cache has to be treated the same, or this becomed exactly the freedom issue that this entire discussion is about.

My pages are actually optimized a lot, and they actually get about 10x slower with AMP than without.

I don't want to have to choose between fast loading and good SEO, I want both. And Google only offering good SEO to those who let Google track all user interactions with their page is also not ideal (I specifically do not use any ads, analytics, or tracking, not even storing IPs in the server logs).


I doubt that CDN is really that important. Maybe if your site serves content overseas then there is a difference but what about a website in a relatively small country that is visited mostly by locals? The CDN doesn't make big difference here.

If your server supports HTTP/2 and has a connection with a good bandwith then static resources can be loaded really fast without any CDN because all the resources can be loaded in parallel without waiting in a queue.

The real motivation for publishers to implement AMP is that they hope to get better position in search results.


Google has, and should, downranked slow pages in favour of fast ones.

But instead of simply pushing that aspect harder, they're actively promoting their own tech.


> Google has, and should, downranked slow pages in favour of fast ones.

They do.


Yeah, one of the biggest problems with AMP is that it works very differently than how the documentation leads you to think it works.


It is interesting that AMP is about the only edge cache that doesn't let you use your own domain. Cloudflare is fairly good evidence that it's workable at scale. Of course, that would eliminate the hijacking header and Google control over the URL.

Edit: Disagree? What part isn't true?


Do you think Google wants to hijack the URL and add extra chrome? They don't. They want the absolute fastest performance which requires prerendering which requires hijacking the URL. (This seems like a bad tradeoff to everyone on HN.)


That extra chrome didn't even include a way to see the original URL until after much squealing. It did, however, include left/right swipe to other people's content. The MVP that rolled out fairly clearly shows who benefits.

An edge cache of an optimized page is plenty fast without preload. Images, in fact, can be preloaded cross domain if that is really needed.

You know it's a mess when the New York Times has to inject a "sorry this video doesn't work on AMP pages, visit our site" message on stories.


Ever heard about RSS? ;)


>Content should remain on the publisher's site.

Publishers are free to implement their own cache and host their own content. AMP is open source and they can modify it however they like.


I mean that when you click a search result in Google you should go to the publisher's site, not to Google's cache of the content. It may have changed since, but that's how it was implemented originally by Google:

https://www.wired.com/2016/02/googles-amp-speeding-web-chang...

"…but there’s a big catch: if readers decide to share a link to an AMP page they’ve clicked on through a Google search, the link points to Google.com (for example, google.com/amp/yoursite.com/yourpage/amp), not to your site. A Google spokesperson confirms that there isn’t a way to both have your AMP-optimized appear in Google’s prioritized search listings without having that content hosted on Google’s AMP Cache servers."


I was under the impression that the publisher could elect to use their own servers for their AMP content. Is this not possible anymore?


There's a lot of doublespeak around this.

1. You can (and must) host AMP content on servers of your own choosing.

2. Google's crawlers ingest your AMP content, validate it, and re-host it in Google's AMP Cache. Bing and other folks run similar crawlers and caches.

3. Google search results will only link to AMP content on Google's own cache.

So yes, you can host your content on your own servers. And you can give people direct URLs to that content. But Google users will only ever see links to the copy of your content that Google hosts; your servers never see that traffic.

There is no way to opt-out and still be considered a valid AMP page.


Publishers already host their own AMP content. Google caches that content, but anyone can go to the publisher's URL and get it directly.

Disclaimer: I work for Google and have some involvement with AMP.


If by "anyone" you mean "my tech savvy friends at google" then yes. I've seen many friends end up on a google-hosted AMP version of a webpage, unable to complete whatever ticket purchase etc they needed because whatever autoAMPifyer the origin site uses produced half broken pages. These users have no idea what AMP is or why the page doesn't work (or that they could have reached the origin site directly if they click around on several unlabeled half-invisible icons in the fake-address-bar on top). In fact, they don't even realize they aren't browsing the origin site. They just give up.


Conceptually this isn't all that different from having a website that works in browser A but not B due to insufficient testing. Why did they not fix it?


Because how many website operators continuously google their own web site on mobile devices to click through to experience their google-hosted AMP editions? I would wager it's a fairly small % of the number of websites running an auto-AMP-ifying wordpress plugin, for example.


I've seen plenty of badly designed mobile websites over the years and these sites seems to have turned out okay - most mobile browsers keep the option of "Request Desktop site" very accessible for a good reason.

The worse case I've seen is a site in which every page crashed Mobile Safari without fail regardless of which version you ask for. It was eventually fixed but I never figured out why. If the sites are just running some script without checking then the admins have failed their line of duty.


Well, I suggest you start giving AMP content that isn't in Google's cache the same preferred treatment in search results that you give cached content.

I'm just going to file another complaint to the EU Antitrust committee otherwise, as this is a simple and clear violation. (Although I doubt my own complaint would be very relevant — all large publishers already have filed such complaints, and Google will be fined for it).

My pages actually increased their loadtime tenfold when I tried them with AMP — they're tested on a HUAWEI IDEOS X3 on 64kbps GPRS. AMP increases load time to over a minute. (On a modern phone, with a modern connection, my pages are obviously also faster — I'm also testing with a Nexus 5X on 100Mbps 4G)

I have the choice between a massively worse user experience, or worse search ranking. And that's a choice that's just not acceptable to me.


Here's your one step recipe to kill AMP:

* Build fast webpages.

The linked article says: "Yes, AMP pages load fast, but you don’t need AMP for fast-loading web pages." Well yes, but people don't build fast webpages without AMP. They could've done all the time, yet webpages got more sluggish over the years.


Building fast webpages won't get you preferential placement in Google search results.



You're right, I was imprecise in my brevity. Speed is definitely a signal in ranking. I'm mainly grousing at classes of results -- like the "Top Stories" carousel -- that are only available to AMP pages, and rather difficult to organically rank above. The AMP results also get more vertical real estate, flashy thumbnails, publisher logo images, etc.

For example, searching for "Python" returns five pages of results where only two aren't about the programming language. But at the top of the page, bested only by python.org itself, is a huge carousel of 11 AMP stories about snakes in the everglades. These stories also appear in the normal search results, but not until the bottom of page 7.

So somehow the #68 result, "Python hunters eliminate more than 100 snakes from Everglades," got boosted to #2, because rankings #2 through #13 (if you count the AMP carousel) are not available to merely fast and relevant content.


Ah, yeah. Truth be told I realised after hitting 'send' that you may have meant that.

This being the case, I think even if building fast webpages may not allow one to circumvent AMP in the instant, it is still a strong way of removing much of the grounds for its existence.


I could be wrong, but from what I've seen, it's not possible to create a non-AMP page that loads faster than AMP, on account of Google's JS hot-loading and caching. AMP always loads faster for me.


Really? Push HTML without bload to a CDN or gihub pages.


Google can only pre-cach and pre-render content it hosts, so it has to go through their cdn servers.


The complaint about AMP's strange UX paradigms is valid: it works very hard to pretend like every AMP article is a standalone website, but it actually behaves like a viewport-wrapping iframe, where Google Search is on the outside and the article is on the inside [1]. But it's not a personal affront to iOS; it's more of an artifact of Google's confusing market strategy and conflicting requirements for AMP's deployment: pretend like AMP pages are real browser-resident tabs, while actually driving traffic around within the confines of Google Search (vs. outside) when possible. As much as I don't care for their strategy, I respect needing to balance conflicting requirements. They should scrap the dishonest UX and be up-front about what they are, as I write [1].

But Josh descends to hyperbole. I've been both critical and supportive of AMP on here [2], but it's important to not lose sight of the big picture. AMP isn't an effort by Google to kill the open web; it's a technology whose existence was forced by Facebook Instant Articles' meteoric rise, a competitor from a company that doesn't even operate on the level of the open web, but runs a family of products where the data flow is one-way: inbound.

Instant Articles made publishing harder on the web, giving preferential treatment to articles posted within Facebook's walled garden (cf. AMP giving preferential treatment to content that adheres to the AMP spec, the same way they give preferential treatment to content served with TLS). With Instant Articles fizzling a bit [3], AMP's importance as a strategic play is lessened, and we can enjoy its benefits without feeling like we're pawns in a game between two massive content aggregation portals.

Besides, Apple News is the same idea as AMP; I'd be curious how Josh feels about that.

[1] https://news.ycombinator.com/item?id=13415625 [2] https://hn.algolia.com/?query=niftich%20%22AMP%22&sort=byDat... [3] https://news.ycombinator.com/item?id=14126073


Is Apple news more than a feed spec like RSS / is the content hosted by Apple directly, like how AMP pages actually live on google.com?


Apple News is really just RSS. I think Gruber's Daring Fireball stuff in Apple News just comes from his RSS feed. It's all hosted on your servers, so it's basically just a specialized browser.


AMP pages don't intrinsically live on google.com. Rather, when you use Google Search on mobile, some results may have AMP equivalents, they're often prioritized on or closer to the top [1] or otherwise highlighted (like in a carousel). As of writing, these results are marked with the lightningbolt-in-circle logo and the text 'AMP' somewhere in the result's most immediate box [2].

Clicking on one of these AMP results in Google Search will lead to a Google-hosted page with the base URL of "google.com/amp/", which loads an iframe (or equivalent) of the AMP article content. This whole thing takes up the entire viewport, save for a small grey horizontal bar up top, which collapses (hides) with JS if you scroll down far enough, but is otherwise pinned to the top, staying adjacent to the browser chrome.

This AMP navbar, as of time of writing, has the original publisher's domain name in the middle (which isn't a link, just informational text); then on the right side is a link ("chain-link") icon which will produce a small overlay containing the article's original (non-AMP, non-google.com/amp/ link), and a vertical triple-dot button with a link to 'More info'. This 'More info' link takes you to a Google Search Help article [3] (along with a really, really long visit_id as a tracking parameter), which talks about AMP and the Google AMP Cache, says that "The Viewer is a hybrid environment where Google and the third-party webmaster may each collect data about you", links to a few FAQs and the Google privacy policy, and the like. In the past, the navbar was different [4], and its deficiencies where a frequent source of criticism.

In short, Google Search on Mobile serves AMP results out of Google's own AMP Cache in a not-completely-obvious in-place wrapping viewer that tracks your visits, but it's now possible to get original URL [4]. Meanwhile, Cloudflare, currently the only other operator of an AMP cache, offers auto-AMP links [5] for customer domains, and offers an SDK to customize the wrapper-viewer [6] that will surround the articles surfaced for that domain.

Apple News is a client application that combines a feed-reader with articles delivered from Apple News' servers; these latter types of articles are always hosted by Apple [7], and in the beginning the only way to publish to it was to use Apple's APIs to post to Apple News directly [8][9]. Now there's integrations that will consume content out of your CMS and post it to Apple News on your behalf, which makes it easier to use, but doesn't change the fact that the the content is published into Apple's ecosystem.

[1] https://www.wired.com/2016/02/google-will-now-favor-pages-us... [2] http://imgur.com/a/rggVe [3] https://support.google.com/websearch/answer/7220196 [4] https://news.ycombinator.com/item?id=13582844 [5] https://www.cloudflare.com/website-optimization/accelerated-... [6] https://www.cloudflare.com/website-optimization/amp-viewer-s... [7] https://www.wired.com/2015/06/apple-builds-content-business-... [8] https://help.apple.com/newspublisher/icloud/#/ [9] https://developer.apple.com/library/content/documentation/Ge...


HTML is already fast. It's the stuff that's added to the page that slows it down, and we already have plenty of standards, techniques and solutions to make sites faster.

AMP is just an alternate HTML framework that prevents certain things, that's all. Not sure why everyone is so eager to opt-in to a less flexible system instead of fixing their existing web presence. All it does is increase the amount of time and resources needed to now maintain effectively 2 different versions of the same site while also losing control over rendering, URL location and privacy.

Also the main reason for slow sites is all the ads - ads which are are usually served by DoubleClick, the biggest ad server on the planet and owned by Google.


I am on your side -- just chiming in to share my observations.

To 99% of the businesses I worked with, software development is a singular expense. It's treated like buying a tractor for the farm. Hell, even farming equipment is more generously funded by the buyers for possible future expenses (compared to most software development) -- maintenance, repairs, parts that periodically need replacement, fuel.

For one reason or another, most businesses treat software development like buying a socket wrench from the local store and never even thinking of spending another penny on the developed product in the future. They expect it to run perfectly forever.

It's a sad state of affairs.


That only makes AMP worse. Many publishers are already squeezed with dev resources, the last thing they need is yet another standard to support instead of putting that time towards the original HTML that is universally available to all users and devices.


Absolutely. You know, in a perverse way of seeing at it, I kind of feel good that Google forces AMP; they are like "Hah, you all stupid motherduckers couldn't get your own crap together for 15 years, guess it's time for you to be ruled, if you can't make use of your freedom". If you look at it that way, it makes sense.

Still, maybe it's time the web development in general gets its crap together indeed. One can dream, right?


Yes. Most often, it's a business management and priority issue than anything technical. It's far easier for developers to point to AMP limitations and just say "its just not supported" rather than try to argue against adding more cruft to the page and get overruled anyway.


A farmer understands a tractor, but most business people don't understand software development.


Very true. The farmer is also aware it's not a maintenance-free machine, unlike businessmen who think software never needs another penny of investment.


Because when Google says, "We can make your page faster" management listens. But when a company's own engineers say it, management says, "Google knows better."


I know it might not be their shtick, but I wish the post focused more on the "publication independence" part of the criticism. Giving Google control over prioritizing a subset of the web, and letting them optimize for it, just gives them a better way to filter content. They seriously have enough power over the web as it is.

The other criticisms about how it performs on iOS seem truly secondary, they could easily fix them but we're still left with the far bigger issue.

Additionally, criticisms about iOS having a closed ecosystem seem irrelevant to this. An App Store is one thing, but starting down the path of effectively adding "high speed lanes" to the supposedly free web is scary.


Gruber's first link ( that's not part of the quoted block or a link to the article he's quoting from ) going to a previous piece of his about the publication independence problems of going along with AMP.


Well said. It seems impossible for me to believe that the trajectory Google is on doesn't end in catastrophic, dystopian disaster for us, the consumers. That should have been the focus, rather than scrolling behaviour.


The only reason AMP is even viable is because the current alternatives are even worse.

Publishers have to date shown a remarkable inability to grasp the idea that user experience matters. Just about every major online publication is painful to browse on a mobile device, even ones that have embraced responsive design, because of things like slow-loading ads, excessive use of JavaScript, and enormous modal prompts for things like subscription offers and newsletter signups. Every year the situation gets worse. And no publisher appears to be willing to buck the trend; presumably they believe that, as long as everybody else's site is just as bad, doing so would just be leaving money on the table. So the economic incentive for change is not there.

AMP is a terrible idea for a lot of reasons, any one of which would in a sane market make it an instant non-starter. But the state of online publishing demonstrates that it is anything but a sane market; it's a market trapped in a death spiral, and in that situation any idea that seems to offer a way out is going to get some traction. So it is with AMP.

The only way to make AMP (or something like it) irrelevant would be for the publishers to get their houses in order on their own, without the need for external pressure. But their leadership doesn't have the kind of farsightedness such a move would require, and that leaves room for someone like Google to come in and do their jobs for them.


AMP is Google's latest attempt to build a walled garden. It's more dangerous to the web than Facebook's WG because of Google's near-monopoly on search. AMP does indeed need to die in a very hot fire.

And in the long term, it's high time somebody built a less creepy, better functioning search engine.


Bing works fine. The more people use them, the better they'll get. DuckDuckGo mostly feeds off other engines, but is also good.

I personally don't really recommend StartPage because you can't get away from Google's opinionated ranking on a site that provides Google results.

But in short, use other search engines and they'll get better. Stop giving Google your search behavior, it's what they use to keep themselves on top.


You realize Bing supports AMP and has an AMP cache as well, right? And if you use DDG, you're effectively using Bing.

BTW, Cloudflare has an AMP cache as well....


I am aware Bing also supports AMP, but reducing Google's dominance in search data is key on preventing them from determining web design going forward.

DDG uses multiple sources, including Bing and Yandex. They also have their own efforts like their knowledge graph-type data features, which are open source and can be contributed to.


Bing user here. I switched a few years ago when I finally got sick enough of Google's many creepy abuses of power.

It's just as good. As others have noted, Google's search is only good when you're signed in. Because they use all that data to personalize the results.


Honestly? I've come to loathe the abysmal performance of the modern web so much that I'm ready to accept AMP. Half the reason I come to hacker News is that the site runs fast. And half the reason I comment before reading the article is because it doesn't.


I often comment without reading the articles because on an older device it's impossible. 90% of links will just crash the browser in 10 seconds. I can watch an hour long youtube video just fine, but trying to load a newspaper article will make it keel over and die.

Disabling javascript does fix a lot of it, but then I can't vote on HN, and I like doing that.


There are extensions which add buttons to quickly enable/disable JS on per-site basis like NoScript for Firefox.

Also, Firefox reader view fixes many websites which otherwise render empty with JS disabled for reasons I didn't bother investigating.


I don't think it's possible to get browser extensions on an old iOS device.


Fair enough, I didn't realize you meant iOS devices.


AMP needs to either be drastically rethought or killed. Nothing more annoying for me on my iPhone than clicking a link and it's AMP - as it means missing features, broken scrolling, masked URL and worst of all, in page search is totally broken on the iPhone! So annoying that there is no way to disable it - if Google persist in pushing it then it might push me to try alternatives!


Google's broken AMP crap is what made me switch to duckduckgo on iOS.


It seems to me that only iOS users are complaining -- as an Android user I am blown away by how readable AMP pages are.

I can just get to the page, read it, and then leave. There's no futzing around with:

* long scrolling down "the fold" filled with clickbait in-site links or other unrelated nonsense

* interstitial and overlay ads

* crappy non-mobile interfaces

* "Shared" buttons stickied to the bottom or top of the viewframe

There's still ads around the page (in-content ads between paragraphs and "you may like" or "recommended" ads at the bottom of the page) and navigational elements to browse outside of the AMP page. It's the mobile content consumption experience as it should be.


Yes, the people who don't own a phone OS by Google are complaining about Google's AMP. That is part of the problem.


A way to disable it while seeing Google results is to start from DuckDuckGo but add "g!". This goes through a different Google interface that always returns normal links.


I believe you mean "!g". DuckDuckGo "macros" start with bang.

https://duckduckgo.com/bang


They both work.


Indeed they do! Thanks for the pointer. Looking a bit deeper, it looks like that's a special case for g! rather than something that works across all DuckDuckGo bangs.

More

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: