Hacker News Reader

Comment by cdata | Hacker News Reader

Disclosure: I work at Google. Opinions are my own.

I'm surprised when I read discussions about AMP on HN (typically carrying a negative tone regarding AMP) without anyone mentioning an obvious competing concept: Facebook Instant Articles.

Here is an excerpt from Facebook's FAQ on instant articles:

> Rather than loading an article using a web browser, which takes over 8 seconds on average, Instant Articles load using the same fast tools we use to load photos and videos in the Facebook app

Facebook has drawn a line around the open web and stamped it as slow compared to Facebook's proprietary content delivery system. If nothing else, AMP is a timely wakeup call for content publishers: if you like the open web, better start producing content that loads quickly on a phone over a 3G network. Otherwise, we will incrementally lose openness at the behest of users who will demand the superior experience of channels like Facebook Instant Articles.

View on HN

Isn't google drawing it's own line around the open web with AMP? I mean with AMP I'm literally browsing a site hosted at Google with a Google top bar on my page. If a user hits the 'x' on my page it takes them back to google.

AMP is a competitor of instant articles rather than the 'cure'.

If google really cared that much about speed they would just punish slow sites. I see amp as a land grab in cute packaging.

> Isn't google drawing it's own line around the open web with AMP?

Yes, I mean, AMP isn't the solution I might build independently. But, it is built on standard, open web platform features. You can render an AMP article from any source in a manner of your choosing, using the features available in a web browser.

> If google really cared that much about speed they would just punish slow sites.

They have started doing this as well, I believe, by rewarding sites that are optimized for mobile devices.

> I see amp as a land grab in cute packaging.

There is a land grab taking place, whether AMP exists or not. The territory at stake is the growing mindshare of users who browse published content (sometimes exclusively) on mobile devices. I would personally love to see a more open movement than AMP or Facebook Instant Articles participating, but I would take AMP over Instant Articles without much consideration.

> But, it is built on standard, open web platform features.

- url highjacking isn't standard, or open, or a feature.

- forcing javascript to load from a specific domain is not standard either.

Let's not conflate the text/HTML-based syntax and the distribution channel implemented by Google. You can render an AMP document with your own implementation of the AMP custom elements. Can I do anything remotely similar with Instant Articles?

The problem is that for amp pages to work with Google search, which everyone uses, it needs to use Google's flavor.

Google should just stop pretending that AMP is any different than fb instant articles. Yeah it gives you more syntactical freedom and you can run some scripts in iframes, the lock in factor is the same.

Not sure why it matters that the scripts are hosted by Google, you can easily add hashes to external scripts to guarantee they haven't been altered.

Yes it's more open than fb instant articles but both act to build a fence around open web

That's all totally fair. But in my original comment, I tried to center my observation on how Facebook has threatened the openness of the web with a proprietary alternative. Is it even possible for Google to deliver the same features without drawing a line around something? If so, how does that hypothetical thing differ from AMP?

Probably not. It's just the marketing that gets me. Google should say "use AMP, a Google alternative to fb instant articles!" Not "use amp it will make your site faster!" Which isn't true.

Worse is that users will start associating the amp icon with fast sites, forcing everyone to start using amp or suffer lower conversions even if their normal site is just as fast or faster. This is because google forces amp sites to be fast, but doesn't punish slow sites in their other search results. Suddenly this amp thing starts to look less innocent.

There is absolutely nothing stopping google from putting an icon next to fast sites that don't use amp. They used slow sites as an artificial crisis to market a fence they're building around the open web.

Pretty dark for the "don't be evil" google. Facebook isn't doing anything better but at least their platform doesn't pollute search engine results

If Facebook was the search engine and could do what Google's search results do for AMP pages for their own offering, you'd probably see a lot more complaints about it.

I work at media company, we have a lot of traffic from both search engines and social media. We have implemented both AMP and Instant articles from day 1 they were introduced.

I love Facebook instant articles because it solves the real problem in very efficient manner - no markup on publishers side, semantics only. And it delivers really great user experience - zero loading time for all articles with a "bolt" sign in my Facebook Feed.

I don't see real value in AMP for two reasons:

1. The top banner plague from google makes my experience reading articles much worse. It consumes a large part of my phones really small screen. Is there single reason why do we need it. I doubt people engineering AMP implementation in Google use it daily.

2. You still can make AMP pages which will consume tons of bandwidth, drain my battery and make me hate web developers (see ability to include external fonts). And for developers who care for their users it's not helping much, even making it harder (see other thread in this HN page). Okay, preferching might help, but what else?

I hoped Google makes things better, instead all I see is just defensive rhetorics about open web. I don't care much about how open or free software is. User experience matters. And I see that Facebook cares about it much more than Google. So sad.

> I hoped Google makes things better, instead all I see is just defensive rhetorics about open web.

My personal opinion is that publishers have a choice: step up and build these types of distribution channels for themselves - to deliver the content in a format they prefer - or else the distribution channels will be built by others and the format of the content will be dictated to publishers by others.

The real danger for everyone is moving away from standard formats that can be rendered easily in a web browser towards something completely proprietary. For my money, AMP is better than Instant Articles in that regard.

> I don't care much about how open or free software is. User experience matters.

I agree that UX is important (if not most important), but I challenge you to consider the long term implications of investing in proprietary solutions just because they make hard problems appear to have been "solved" easily. Free and open source software has compounding benefits over time that proprietary software often fails to provide. Even Apple - a company (in)famous for its proprietary technical solutions - laid most of the foundation for its renaissance with free and open source software, and continues to benefit from (and contribute to) free and open source software development today.

> And I see that Facebook cares about it much more than Google.

Make no mistake: big tech companies care most about money. There is a trap that you can fall into, especially as a technical person, where you believe that a company cares about your success in particular. No company really does. They mostly just care about money. Plan accordingly.

The idea of a more open version of Facebook Instant Articles is great, it's the implementation that bothers me.

Instant Articles only works in the Facebook app, while Google wanted AMP to work on every mobile browser out of the box on day one.

This has its advantages and disadvantages, but I just can't get past the hijacking of the domain. Facebook Instant Articles does not do that.

What loads faster than straightforward clean basic HTML? The answer to speed issues is dialling back on fancypants javascript, not buying into corporate giants' content vaults. IMHO, obviously.

Reply on news.ycombinator.com