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

441–450 of 489 posts

Re: Kill Google AMP before it kills the web

#441

Post by jorvi »

ageofwant wrote: post #375
Buge wrote: post #316

Earlier quoted context omitted.

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.

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

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.

Re: Kill Google AMP before it kills the web

#442

Post by jorvi »

squarefoot wrote: post #388
exergy wrote: post #70

Earlier quoted context omitted.

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

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.

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

Re: Kill Google AMP before it kills the web

#443

Post by tajen »

jdormit wrote: post #23
JumpCrisscross wrote: post #12

Earlier quoted context omitted.

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

Re: Kill Google AMP before it kills the web

#444

Post by MBCook »

theclaw wrote: post #400
MBCook wrote: post #193

Earlier quoted context omitted.

Too little for me. I still can't easily copy that URL, and there's no way to opt out of it. Instead of fixing their complete break to the way with the web works, they put in a little tiny patch and clean it's just as good.

If you're on iOS You can copy it by long-touching the URL that pops up when you touch the link icon.

You can now (although that's still different from any other site). I'm pretty sure that was only added a few months ago and when it was first released you couldn't easily copy the URL.

Re: Kill Google AMP before it kills the web

#445

Post by MBCook »

kinkrtyavimoodh wrote: post #374
MBCook wrote: post #301

Earlier quoted context omitted.

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.

Re: Kill Google AMP before it kills the web

#446

Post by notatoad »

tyingq wrote: post #423
notatoad wrote: post #360

Earlier quoted context omitted.

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

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.

Re: Kill Google AMP before it kills the web

#447

Post by cramforce »

om2 wrote: post #392
askafriend wrote: post #217

Earlier quoted context omitted.

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

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

Re: Kill Google AMP before it kills the web

#448

Post by cramforce »

madeofpalk wrote: post #334
raldi wrote: post #331

Earlier quoted context omitted.

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?

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.

Re: Kill Google AMP before it kills the web

#449

Post by SA500 »

cramforce wrote: post #165

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

Haha- that is hilarious

Re: Kill Google AMP before it kills the web

#450

Post by swift »

captainmuon wrote: post #313
EvilTerran wrote: post #94

Earlier quoted context omitted.

Seems to me the right approach would be for sites to embrace the HTML5 semantic tags ( , 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…

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

HTML6 document is essentially epub, which is HTML and CSS under the hood.
Post reply on HN