Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kill Google AMP before it kills the web

theregister.co.uk

Post reply on HN
Print view View original

301–310 of 489 posts

Re: Kill Google AMP before it kills the web

#301

Post by MBCook »

cramforce wrote: post #266
MBCook wrote: post #261

Earlier quoted context omitted.

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 si…

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.

Re: Kill Google AMP before it kills the web

#302

Post by MBCook »

bla2 wrote: post #274
MBCook wrote: post #202

Earlier quoted context omitted.

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 l…

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.

Re: Kill Google AMP before it kills the web

#303

Post by bdhess »

kbenson wrote: post #252
MBCook wrote: post #202

Earlier quoted context omitted.

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 l…

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…

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

Re: Kill Google AMP before it kills the web

#304

Post by acdha »

mikelward wrote: post #297
acdha wrote: post #246

Earlier quoted context omitted.

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 t…

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.

Re: Kill Google AMP before it kills the web

#305

Post by agumonkey »

jwilcoxson wrote: post #37
rubyn00bie wrote: post #27

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 beyon…

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

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.

Re: Kill Google AMP before it kills the web

#306

Post by ploxiln »

ejcx wrote: post #279
ghughes wrote: post #272

Earlier quoted context omitted.

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 :)

Re: Kill Google AMP before it kills the web

#307

Post by manigandham »

pdimitar wrote: post #259
manigandham wrote: post #90

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 reso…

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 reas…

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.

Re: Kill Google AMP before it kills the web

#308

Post by SomewhatLikely »

gwu78 wrote: post #294

Long before amp, Google began prefixing search result urls with "google.tld?url=" and adding Google parameters as suffixes such as "sa=", "ved=", etc. Unless I am mistaken this parasitic cruft only serves Google, not end users. Below is quick and dirty program to filter out the above. Replace .com with .cctld as needed. Requirements: cc, lex Usage: curl -o 1.htm https://www.google.com/search?q=xyz yyg 2.htm your-ad-s…

It's really annoying trying to copy and paste URLs from Google results. It also seems largely unnecessary, can't they detect clicks using javascript? I have noticed they have started doing this with links sent through Google Hangouts messages as well. I do remember a time when they weren't doing this and it was very refreshing because everyone else was.

Re: Kill Google AMP before it kills the web

#309

Post by acdha »

ihsw2 wrote: post #290
fenomas wrote: post #284

What kills me about AMP's UX is that not only is it a dark pattern, it's not even a new dark pattern. Back, say, 10-12 years ago it used to be really common for sites to jigger their outgoing links, such that the target site would appear in an iframe underneath a toolbar from the original site. This was widely reviled, and mostly died out, and the fact that Google is reviving it really bothers me.

How is this a dark pattern? Sites opt into it, users get a streamlined interface for content consumption, everybody wins. The only losers in this are those seeking to "curate" the user experience (UX) on their sites, and personally I lump them in with malicious ad peddlers -- to hell with them.

Sites opt-in under heavy pressure that they'll lost placement if they don't. Users lose the ability to get the normal site rather than the AMP version when browsing on mobile devices.

Re: Kill Google AMP before it kills the web

#310

Post by captainmuon »

richdougherty wrote: post #3

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

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

Post reply on HN