Comment by tejasmanohar | Hacker News Reader

Comment by tejasmanohar | Hacker News Reader

  AMP is, to begin with, Google exerting its market power to extend its control over others’ content. Facebook is doing it, so Google has to.

As a consumer, I actually love AMP. Everytime I click a news link on mobile and am taken to AMP, I'm relieved to be free from the extremely distracting original websites.

Google has done a lot of exciting work on open standards like JSON-LD [0] and Microdata [1] to bring a better experience to both Google search results and Gmail. I love clicking the inline "Confirm subscription" button [2] instead of opening emails from Mailchimp and searching for a link. I'm not that scared of the future becoming locked into Google. I believe they'll improve upon and create better standards for emails. Most things aren't entirely altruistic, and that's OK. Gmail being an early adopter to these standards is a good enough reason for them.

[0]: https://developers.google.com/gmail/markup/reference/formats...

[1]: https://developers.google.com/gmail/markup/reference/formats...

[2]: https://developers.google.com/gmail/markup/reference/one-cli...

We have the exact opposite opinion then. I moved to DuckDuckGo on iOS because I thought the AMP formatted Google search results were so user-hostile.

Maybe they’ve fixed the bizarre scrolling and overly sensitive links by now, but I see no reason to find out, because I don’t feel like I’m missing anything.

For what it's worth, I only use my phone seriously when I'm out and about, and a lot of times, my internet connection isn't the best, e.g. while in metro

This is true for me too, but I still find that using AMP pages on Android is basically nonfunctional. They load fast, but scrolling is shoddy and every single linking function (back button, hyperlink, and new tab alike) is a mess.

If I want to load a single page with dense content, view it without scrolling much, and close the tab, AMP makes my mobile experience better. If I want to do anything else, AMP on Android starts to interfere with basic functionality.

Which is a pretty sad story for a Google CDN on a Google browser on a Google OS.

I know the scrolling issues we're bugs in webkit. Google (I believe) started to employ a webkit dev to fix the problems.

I’ve heard that before. It’s still fair to blame Google for the whole fiasco. Especially since the non-AMP versions had always worked fine.

Why not blame Apple for building a buggy browser that you have no choice but to use? Stop buying buggy user-hostile phones. AMP pages work perfectly fine in Firefox for Android.

Let’s say you’re an engineer about to roll out a feature to (literally) a billion users. Through testing, you know your feature is busted for the ~14.5% of your users who use Safari. But it’s not your fault! Apple should fix it.

Quick quiz: do you release a feature that is broken for 145M users, which brokenness they might plausibly encounter multiple times a day?

In a typical organization, the answer would probably be an unambiguous “no”.

Without passing judgment, I find the fact that Google decided to ship anyway to be a useful indicator of their beliefs, culture, and priorities.

You could turn that around and ask why Apple didn't bother to fix something that was causing pain for some of their users and continued not to fix it after it was causing pain for most of their users. Google made a bad engineering decision, but I would place most of the blame on Apple.

It's the same for IE and web applications that didn't work in that browser. Luckily, people (for the most part) stopped using IE. We can only hope that iOS Safari will share that fate.

It doesn’t feel equivalent to me; I tend to think that there’s a meaningful distinction between a bug known before shipping and a bug discovered after.

That said, it’s fair to ask why Apple hasn’t placed priority on the scrolling bug, post-AMP. What the real dynamics are I can only guess; I’d love to hear from lurking AMP or WebKit engineers.

The three main issues are that scrolling behavior was busted, clicking on the top bar doesn't scroll to the top like it does in all other scroll views in the system, and the URL bar doesn't show the 'real site' so links shared via the built-in mechanism are links to google, not to the actual site content.

All three of these are Google not taking into account mobile browser design. None of these can really be classified as issues in Safari, rather they are consequences of the Safari design and the design choices Google made.

The first two are due to the content being embedded within an iframe.

The scrolling issue was partly because Safari implemented custom scroll behavior (supposedly due to a Steve Jobs request) for its main web view, but scrollable iframes did not override the scrolling behavior. The fix here (I believe it was rolled out in iOS 11) was to change system-wide behavior for Safari to use the system default scrolling behavior, so that everything behaved the same.

The title bar issue is due to the content not being a scroll view, but a view the size of the screen containing one or more scroll views (the iframes). Which of these should be scrolled to the top on a tap? Changing this behavior could change it for deployed sites, so rolling out any sort of new heuristic requires testing and probably wouldn't be done outside a new major version (e.g. iOS 12).

The third issue is across all browsers - Google is the one serving the content, not the third party that wrote the content. Because of this, any attempt to change where the browser 'thinks' a page is being served to another domain runs afoul of pretty fundamental web security principles. You might be able to design some sort of call (similar to CORS) to ask if google is representing your content in order to get permission to forge the address, but that would be a new web standard that hasn't been written yet.

Google should have just not used a scrolling iframe. MobileSafari has this beautiful quirk that iframes greater than 8 pixels tall automatically expand to the size of their content, solving all of the awkward coordination problems of sizing the iframe. It would have been just so damned simple for Google to fix this in MobileSafari :/.

That's certainly an interesting quirk, I've never heard of it, nor seen it in another browser.

Definitely useful, though, why isn't that a feature in HTML5?

The AMP viewer and the AMP cache page are served from different domains. Leaking the size of the cache page to the viewer page would be a security bug, which is worse than the scrolling bug that Apple actually had.

> I’d love to hear from lurking AMP or WebKit engineers.

A WebKit engineer explained the scrolling bug and how they fixed it here: https://news.ycombinator.com/item?id=14386292

> That said, it’s fair to ask why Apple hasn’t placed priority on the scrolling bug, post-AMP

Because Apple is incapable of fixing a browser bug without an OS update. You should be asking why Apple won't let you use a non-buggy browser on your phone to begin with.

I’m not going to switch my browser or my hardware platform over some trivial bug that only surfaces on one website. I’m just not going to visit that website.

No, not really. Most UX issues with AMP on Safari rather stem from the approach Google has taken with the html. For instance, it’s not a WebKit bug that tapping the top of the screen on an AMP page does not scroll to top - something that works on virtually all other webpages.

The tapping top of screen hasn't been fixed, as it likely is hard to do.

As for other work on scrolling:

Person contracted to fix some webkit issues: http://frederic-wang.fr/amp-and-igalia-working-together-to-i...

HN discussion made some news about scrolling changes made due to AMP's bug reports: https://www.macrumors.com/2017/05/22/scrolling-changes-comin...

AMP scrolling is still broken. I don’t see why it needs to touch the scroll behavior at all. Plain html is both fast and scrolls naturally. It doesn’t break mobile safari. I don’t get why Google needed to render AMP on such a way that they need to try hard to emulate native scroll behavior (still getting it wrong, previously it was too fast and now it’s a smidge too slow) instead of just using the native behavior.

>The tapping top of screen hasn't been fixed, as it likely is hard to do.

Plain HTML+CSS is hard to do?

Google has gone to an exceptional effort to make things not work like they do by default. That it's even more effort to now get basic UX back shows just how misguided the entire team is.

It doesn't matter how you "feel", I know for a matter of fact, objectively and measurably, that my load times have gotten significantly faster, and that AMP has achieved what thousands of sites have failed to do.

So feel free to call it names and bring up feelings, but what I care about is the actual objective experience I'm getting.

That's being a bit obtuse. Of course it matters how it feels, however you look at it! Such as if a loading bar makes something feel better as it loads - then good!

That's not quite what I was talking about. I was responding specifically to:

> I see no reason to find out, because I don’t feel like I’m missing anything.

The person was basically saying "I don't feel like checking how good AMP is, I'm just going to blindly dismiss it"

While I agree with your opinion that AMP is fast, perceived performance is certainly a thing. Read into it :-)

There are still UX problems on Android too. I tend to open links in a new window and then close the one I'm looking at when I'm done with it. This experience is totally broken with Amp pages in mobile Chrome. Uhg.

When AMP was announced, I was excited about it specifically for my phone - it's where I care most about loading speeds.

These days, I actively avoid AMP links on Android. It's such a hideously buggy, functionality-disabling system on my phone that it's not worth loading those pages at any speed.

Honestly if AMP is such a nice format, how hard can it be to just format the content in plain HTML+CSS and let the browser do the scrolling and UI bits?

Only if that doesn't work pleasantly, then you get to complain about the browser not doing its job properly. (this remark aimed at some other replies in this subthread)

It's probably not hard at all, it's just that Google's priorities are currently at "fuck you" especially if you try to avoid being tracked.

As a consumer I like the speed of AMP but hate the usability of it (ever try sharing a link? ugh).

As a developer and a content creator? I absolutely hate it. Not only is my content hosted outside of my control but they give them a visual weighting in Google search results. So now, if I want my content to have the best chance to be seen, I have to use AMP.

I wish they would have just made AMP a framework or build system that out spit out optimized web pages. Instead they force us to use their CDN which also has multiple trust issues.

I don’t like how usual ios controls stop to work with amp, e.g. scroll to top by tapping on time; back button works[-ed] wrongly. Also there is annoying amp bar at the top that pops up constantly when I scroll. They can’t distinguish between swipe-and-stop and swipe-and-letitscroll in browser, so it doesn’t work as safari header bar.

Better they completely faked dns/cert in some wat and presented me copied content from their amp cache. I don’t check sources anyway.

Reply on news.ycombinator.com