Google Announces Plan to Improve URLs for AMP Pages, but AMP Will Still Suck | Hacker News Reader

Google Announces Plan to Improve URLs for AMP Pages, but AMP Will Still Suck

daringfireball.net

The premise Google is responsible for the issues he mentions is demonstrably false.

AMP's foundational tenents don't include Google Search is the one and only search engine. Bing and Microsoft's apps have been using AMP publicly for 1.5 years, with Google's help and support during development.

The comments after are Apple bugs, not issues with Google or AMP. To wit, the AMP foundation hired an open source consultancy 6 months to bring WebKit's frame implementation in sync with modern browsers, which also fixes the scrolling issues. See http://frederic-wang.fr/amp-and-igalia-working-together-to-i...

But is it necessary to do it using iframes? Why not open a web page (which would be better supported in general and wouldn’t require fixes in the first place)?

On the one hand, I cry every time the open web loses a bit, and certainly AMP is a loss for the open web. After all Google is essentially trying to make the web its platform.

But as a user... I love, yes love AMP. All of these complaints about scrolling and Safari chrome and URLs are valid, but guess what: AMP has an awesome feature that the page actually loads!

I know some sites (like Daringfireball) load really nice and fast on mobile, and only have 1 or 2 ads on them, but that's not the state of the web. There are lots of sites with great content, but also 2MB of React Frameworks/Ads/Crap to display a 2KB article. I hit "Reader Mode" as soon as I can on these pages, which is usually after 5-10 seconds of load. Compare this to AMP which load in <1 second. That tradeoff is worth it to me.

Yeah this is the problem. I think some of the criticisms of AMP are valid but the sad reality is that sites are never going to clean up their act on their own. AMP dramatically improves web UX for people that might otherwise be inclined to give up and spend all their time in feeds in native apps.

Hopefully Google can address some of these concerns without losing the very real end user benefits of AMP as it's implemented now.

The road to hell is paved with good intentions. Google's new motto perhaps.

Good intentions?

Strip away the blue sky projects and the stuff they do for optics/PR, and you’re left with a machine that is designed to collect deeply personal insights about every economic participant on Earth and use that intelligence to make money.

Google’s road to hell was paved with deceit.

Not sure where the deceit was. This was always what they were doing.

But before all they had was a search engine instead of 500 services paired with analytics.

I think the initial intention of creating a "good" search engine was there and a great social benefit, but after that it kinda went to hell.

AMP as a "feature" is really just there to prevent you from leaving search results and google's sites.

It's a cover up for further closing down the open web and helping them bump ad revenue.

Hopefully you guy already know that.

I'm pretty sure everyone realizes what proxying all non-Google content through their servers does. The thing is, people who rely on Google are more afraid of it going away than they are upset at the lengths by which Google asserts itself over their life.

It's really funny to me. They already had Android Chrome's "traffic optimizer" to tunnel all traffic through their servers. But I guess they wanted Safari and other mobile content as well, so they made this crappy web proxy, and now it affects everyone's use of the web. Like... they really didn't have to do this. But they knew they could, and knew it would only provide a minor annoyance to most people, so they did it. And predictably, people defend it, as if reinventing WAP were a good idea.

(To be fair: when I used a J2ME phone, I wrote WAP web services. But I'm not runnning a J2ME phone any more.)

I'm still kind of confused as to why people dislike AMP. I thought it was just meant to be a fast subset of HTML, which allows for small, fast, cacheable pages?

It's not a subset of HTML, it's a system of delivering content that happens to shift some control from producers to Google.

Producers had disregarded users' interests for too long with increasingly bloated pages. Google was able to benefit both itself and users by cutting the bloat, but because the solution comes at the cost of further centralization, it's seen as part of the general erosion of the open and decentralized web.

AMP content is still hosted by the producers though isn't it?

If people are concerned by it being "centralised" due to Google caching the pages, shouldn't they also be concerned about CDNs like Akamai? Or am I missing something important?

The problem is, that you never leave Google's domain. Even if the content is hosted somewhere else, you are accessing it through an iframe on a Google domain. But without looking at the URL bar, you don't even know it, as there is no Google logo or anything. Not to mention, that it's a terrible user experience. The AMP header takes up a big part of your screen height and often causes browser URL bars not to hide, taking up even more. Add the site header and you barely have any space left for the content. And it's even worse on old devices - they have to render the Google page and the iframe inside it. This makes them much slower than if Google just let you access the page directly.

I'm not sure that being hosted on Google's domain is inherently a bad thing, given the ubiquity of CDNs, but the others are definitely fair points. If I'm understanding everything, AMP still seems like a good idea, it's just implementation details which can be problematic.

I think the problem for mobile web would never be solved by "import" something.Every website should really find their own way, since websites varies in many aspect.

But to be honest, I really think developers these days are doing things wrong.they are adding more and more stuff for simplicity, which turn out to be bigger troubles

Reply on news.ycombinator.com