They've had them in Google News for ages. I've been using them for a while, work great (I'm on Android). So well in fact even though I am on the 0.1% of the population that's consciously aware of their tactics, they have already trained me to subconsciously prefer clicking on websites that have their AMP logo, compared to the rest, because I subconsciously know they load much faster.
When I first saw it (in the 'News' section of results) I was happy to see it. After clicking 2 or 3 of the links I quickly learned to avoid it and either go to another site or find the non-AMP link in the results below.
I really wish sites (AMP isn't the only thing to do this) would stop deciding they know how to implement scrolling better than my browser/OS does it. Here's a hint: YOU DON'T. Let the user have what they're used to. Sudden behavior changes for tenuous-at-best benefits ("It scrolls faster!") are obnoxious.
AMP doesn't implement scrolling in software. It is native GPU accelerated scrolling. iOS does have 2 modes and it might be that AMP hits the one some people don't like.
Knowing where the viewport is relative to the document is pretty valuable; It means that AMP can defer loading potentially sluggish content until the viewport lands on a particular position.
Unfortunately, blocking that API (listening for 'wheel' events) will entirely break large portions of many sites -- any element where they've manually implemented the scrollbar or have fancy stuff or whatever won't work. I tried writing a Greasemonkey script that killed smooth scrolling, but it broke way too many sites.
One thing that does work though, at least in a lot of cases, is using an adblocker to block the URLs of common smooth scroll scripts. My adblock filter rules are in a comment in this gist if you want them (actually, this gist is my aforementioned Greasemonkey script): https://gist.github.com/oxguy3/ebd9fe692518c7f7a1e9
They do not work as well on iOS. Two examples of this are "scroll to top" by tapping the title bar is completely broken under AMP. The other is that Safari Reader is mostly broken under AMP. That said, the experience with super fast, virtually instant loads, is great, and I think these are definitely kinks that can be worked out.
I'm just confused why they made it through to consumer release without someone else questioning them. These are major features of the most popular browser on [one of the two] most popular mobile OS that Google is choosing to break.
> "scroll to top" by tapping the title bar is completely broken
This is because the scrolling is in a container rather than the body. It's a tough problem on many mobile pages using sliding drawers for example, which rely on overflow based scrolling. There's no event, that I'm aware of, for a web app to listen for for tapping that UI element on iOS.
Ultimately, it's a non-standard convenience introduced on iOS only. Maybe someone else here has solved this :)
On iOS, there are various conventions that apps generally follow. On a list item you can swipe from right-to-left to bring up a Delete option. On a list of stuff you can tap at the top of the screen to scroll to the top. These are standard things in the iOS ecosystem.
A good parallel outside of iOS would be the pervasive use of right-click to bring up a context menu in Windows or the convention of having "--help" show help text in Linux.
A cursory look at those stats should tell you they're bogus. Going from 32% to 23% market share (about a 30% decline) in two months is not even remotely likely.
The point I was trying to make was that iOS, and Safari on iOS, has a massive, massive user base. Throwing #1 vs #2 into the mix is distracting from that point.
