submitted second draft of AMP story

1 files changed, 31 insertions, 28 deletions

diff --git a/amp.html b/amp.html
index d66b084..884a190 100644
--- a/amp.html
+++ b/amp.html
@@ -6,24 +6,27 @@
 <p>Google is late to the game, but its new Accelerated Mobile Pages project has the same goals as Facebook and Apple's efforts -- make the web feel like a native application on mobile devices. It's worth noting that all three companies seem utterly unconcerned with speeding up the web on the desktop.</p>
 <p>All of these efforts -- Instant Articles, Apple News and AMP -- are to help speed up our experience of the web on mobile devices by stripping out all that junk that messy web developers and publishers have included in their websites. All those ads, all those images, all those interactive graphics, all those comment sections, all those extras that take too long to load.</p>
 <p>Instead, Facebook Instant Articles, Apple News and now AMP will present stripped down pages that load quickly even over the paltry 3G speeds still found in much of the United States.</p>
-<p>In the case of AMP there are apparently two things playing the role of villans in the &quot;web is too slow&quot; story: JavaScript and advertisements that use JavaScript.</p>
+<p>In the case of AMP there are apparently two things playing the role of villains in the &quot;web is too slow&quot; story: JavaScript and advertisements that use JavaScript.</p>
 <p>It sounds like a pretty good story. It has good guys (Google) and bad guys (everyone not using Google Ads) and it's true to most of our experiences. Who isn't sick of intrusive ads and terrible JavaScript libraries begging for us to sign up for some terrible newsletter?</p>
-<p>But this story has some fundamental problems. For example, Google owns the largest ad server network on the web, if ads are the problem, why doesn't Google get to work speeding up the ads? More on that in bit.</p>
+<p>But this story has some fundamental problems. For example, Google owns the largest ad server network on the web, if ads are the problem, why doesn't Google get to work speeding up the ads? More on that in a bit.</p>
 <p>But first, AMP.</p>
 <h2 id="what-is-amp">What is AMP?</h2>
-<p>AMP bills itself as a subset of HTML. That is true, to a point. But as one has probably come to expect with a new project from a big company on the web, AMP also re-invents the wheel quite a few times. There's a name for this behavior: Not Invented Here or NIH.</p>
-<p>For example, pretty much everything AMP does could be accomplished through RSS, which is an open standard that's been around for over a decade. It's even been declared dead, but it still persists in part because it's fantastically useful and works just about everywhere. Even if you don't like RSS, and Google, for whatever reasons, has never seemed to like RSS, there's JSON, RDF and several other means of finding and stripping out the core content on a page.</p>
-<p>The problem with RSS, JSON and RDF is that that Google didn't invent them. And so AMP.</p>
-<p>First though, what is AMP? AMP is a markup language that looks a lot like HTML without the bells and whistles. In fact, if you head over to the <a href="https://www.ampproject.org/how-it-works/">AMP project announcement</a> you'll see an AMP page rendered in your browser. It looks like any other page on the web.</p>
+<p>To understand AMP first you need to understand Facebook's Instant Articles. Instant Articles uses RSS and standard HTML tags to create an optimized, slightly stripped down version of an article. Facebook then allows for some extra rich-content like auto-playing video or audio clips. Despite this Facebook claims Instant Articles are up to 10 times faster than their siblings on the open web. Some of that speed gain comes from stripping things out, some likely comes from aggressive caching.</p>
+<p>But the key is that Instant Articles are only available via Facebook's mobile apps and only to established publishers who sign a deal with Facebook. That means reading articles from Facebook's Instant Article partners like National Geographic, BBC, Buzzfeed and others is a faster, richer multimedia experience than those same articles when they appear on the publisher's site.</p>
+<p>Apple News appears to work roughly the same way, taking RSS feeds from publishers and then optimizing the content for delivery within Apple's application.</p>
+<p>All this app-based content delivery cuts out the web. That's a problem for the web and by extension, Google, which leads us to Google's Accelerated Mobile Pages project.</p>
+<p>Oddly though, unlike Facebook Articles and Apple News, AMP eschews standards like RSS and HTML in favor of its own little modified subset of HTML. AMP HTML looks a lot like HTML without the bells and whistles. In fact, if you head over to the <a href="https://www.ampproject.org/how-it-works/">AMP project announcement</a> you'll see an AMP page rendered in your browser. It looks like any other page on the web.</p>
 <p>AMP markup uses a basic set of tags from HTML. An extremely limited set of tags. Form tags? Nope. Audio or video tags? Nope. Embed? Certainly not. Script tags? Nope. There's a very short list of the HTML tags in allowed in AMP documents available over on the <a href="https://github.com/ampproject/amphtml/blob/master/spec/amp-html-format.md">project page</a>. There's also no JavaScript allowed. Those ads and tracking scripts will never be part of AMP documents (don't worry, Google will still be tracking you).</p>
-<p>Amp defines several of its own tags, things like <code>'amp-youtube</code>, <code>amp-ad</code> or <code>amp-pixel</code>. The extra tags are part of what's known as <a href="http://www.w3.org/TR/components-intro/">web components</a>, which is not now, but likely will eventually be a web standard (or possibly ActiveX part 2, only the future knows for sure).</p>
-<p>So far AMP probably sounds like a pretty good idea to most readers. Faster pages, no tracking scripts, no JavaScript at all so no overlay ads about signing up for newsletters or downloading apps no one needs... Except, wait for it, actually there is some JavaScript -- Google's JavaScript. Also, Google's ads. Also Google's tracking pixels.</p>
-<p>The more you look at AMP the less it looks like a good idea. Let's start with some of the poor technical decisions in the current incarnation of AMP. Or at least they're poor decisions if you like the open web and the current HTML standards.</p>
-<p>AMP re-invents the wheel for images using a custom component <code>amp-img</code> instead of HTML's <code>img</code> tag (not only does Google ignore RSS, JSON and RDF, it ignores HTML). AMP doesn't stop there. It does the same things with <code>amp-audio</code> and <code>amp-video</code> rather than the HTML standard <code>audio</code> and <code>video</code>. AMP developers argue that this allows AMP to only serve images when required, which isn't possible with the HTML img tag. That, however, is a limitation of web browsers, not HTML itself. AMP also very clearly has treated <a href="https://en.wikipedia.org/wiki/Computer_accessibility">accessibility</a> as an after thought, or more likely, not a thought at all. You lose more than just HTML tags with AMP.</p>
-<p>In other words AMP is technically half baked at best.</p>
-<p>But the markup that is AMP is really only one part of the picture. After all, as pointed out above, if all they really wanted to do is strip out all the enhancements and just present content of a page there are quite a few already existing ways to do that, including RSS, JSON and RDF. In fact, Google used to have an RSS reader that did just this. So why AMP?</p>
+<p>AMP defines several of its own tags, things like <code>amp-youtube</code>, <code>amp-ad</code> or <code>amp-pixel</code>. The extra tags are part of what's known as <a href="http://www.w3.org/TR/components-intro/">web components</a>, which is not now, but likely will eventually be a web standard (or possibly ActiveX part 2, only the future knows for sure).</p>
+<p>So far AMP probably sounds like a pretty good idea to most readers. Faster pages, no tracking scripts, no JavaScript at all so no overlay ads about signing up for newsletters or downloading apps no one needs.</p>
+<p>But then there are some problematic design choices in AMP. The more you look at AMP the less it looks like a good idea.</p>
+<p>Let's start with some of the poor technical decisions in the current incarnation of AMP. Or at least they're poor decisions if you like the open web and the current HTML standards.</p>
+<p>AMP re-invents the wheel for images using a custom component <code>amp-img</code> instead of HTML's <code>img</code> tag (not only does Google ignore RSS, JSON and RDF, it ignores HTML). AMP doesn't stop there. It does the same things with <code>amp-audio</code> and <code>amp-video</code> rather than the HTML standard <code>audio</code> and <code>video</code>. AMP developers argue that this allows AMP to only serve images when required, which isn't possible with the HTML <code>img</code> tag. That, however, is a limitation of web browsers, not HTML itself. AMP also very clearly has treated <a href="https://en.wikipedia.org/wiki/Computer_accessibility">accessibility</a> as an after thought, or more likely, not a thought at all. You lose more than just HTML tags with AMP.</p>
+<p>In other words AMP is technically half baked at best. The good news is that AMP developers are listening. One of the worst things about AMP's initial code was the decision to disable pinch and zoom on articles. Thankfully Google has reversed course and <a href="https://github.com/ampproject/amphtml/issues/592">eliminated the tag that prevented pinch and zoom</a>.</p>
+<p>There are also dozens of other open issues calling out some of the <a href="https://github.com/ampproject/amphtml/issues/517">most</a> <a href="https://github.com/ampproject/amphtml/issues/481">egregious</a> <a href="https://github.com/ampproject/amphtml/issues/545">decisions</a> in AMP's technical design. There are already open issues surrounding nearly every technical shortcoming mentioned in this article.</p>
+<p>But the markup that is AMP is really only one part of the picture. After all, as pointed out above, if all they really wanted to do is strip out all the enhancements and just present the content of a page there are quite a few already existing ways to do that, including RSS, JSON and RDF. In fact, Google used to have an RSS reader that did just this. So why AMP?</p>
 <p>Speeding things up for users is a nice side benefit, but the point of AMP, like Facebook Articles, is to lock in users to a particular site/format/service. In this case the users aren't you and I reading, it's the publishers putting the content on the web.</p>
-<h1 id="its-the-ads-stupid">It's the Ads Stupid</h1>
+<h2 id="its-the-ads-stupid">It's the Ads Stupid</h2>
 <p>The goal of Facebook Instant Articles is to keep you on Facebook. No need to explore the larger web when it's all right there in Facebook, especially when it loads so much faster in the Facebook app than it does in a browser on the web.</p>
 <p>AMP exists because Google recognized what a threat Facebook Instant Articles is to Google's ability to serve ads.</p>
 <p>This is why it's called Accelerated <em>Mobile</em> Pages. Sorry desktop users, Google already knows how to get ads to you.</p>
@@ -44,9 +47,10 @@
 <h2 id="amp-static-pages-that-require-googles-javascript">AMP: Static Pages that Require Google's JavaScript</h2>
 <p>The most basic thing you can do on the web is create a flat HTML file that sits on a server and contains some basic tags. This type of page will always be lightning fast. It's also insanely simple. This is literally all you need to do to put information on the web. There's no need for JavaScript, no need even for CSS.</p>
 <p>This is more or less what AMP wants you to create (AMP doesn't care if your pages are actually static or -- more likely -- generated from a database, the point is what's rendered is static).</p>
-<p>But then AMP wants to turn around and require that that page include a third-party script in order to load. AMP deliberately sets the opacity of the entire page to 0 until the script loads and only then is the page revealed.</p>
-<p>As developer Justin Avery <a href="https://responsivedesign.is/articles/whats-the-deal-with-accelerated-mobile-pages-amp">asks</a>, &quot;surely the document itself is going to be faster than loading a library to try and make it load faster.&quot; Why yes they would.</p>
-<p>Ironically, for something that is ostensibly trying to encourage better behavior from developers and publishers, this means that pages using progressive enhancement, with perhaps a couple of scripts that don't track you, but do add some functionality to the page -- in other words sites following best practices and trying to do things right -- will potentially be slower in AMP.</p>
+<p>But then AMP wants to turn around and require that pages include a third-party script in order to load. AMP deliberately sets the opacity of the entire page to 0 until the script loads and only then is the page revealed.</p>
+<p>As developer Justin Avery <a href="https://responsivedesign.is/articles/whats-the-deal-with-accelerated-mobile-pages-amp">asks</a>, &quot;surely the document itself is going to be faster than loading a library to try and make it load faster.&quot; Pinboard.in creator Maciej Cegłowski did just that, putting together a demo page that duplicates the AMP-based AMP homepage, but without that JavaScript. Over a 3G connection Cegłowski's page fills the viewport in <a href="http://www.webpagetest.org/result/151016_RF_VNE/">1.9 seconds</a>. The AMP homepage <a href="http://www.webpagetest.org/result/151016_9J_VNN/">takes 9.2 seconds</a>.</p>
+<p>JavaScript slows down page load times, even when that JavaScript is part of Google's plan to speed up the web.</p>
+<p>Ironically, for something that is ostensibly trying to encourage better behavior from developers and publishers, this means that pages using progressive enhancement, keeping scripts to a minimum and aggressively caching content -- in other words sites following best practices and trying to do things right -- will potentially be slower in AMP.</p>
 <p>In the end, developers and publishers who have been following best practices for web development and don't rely on dozens of tracking networks and ads have little to gain from AMP.</p>
 <p>Unfortunately, the publishers building their sites like that right now are few and far between. Most publishers have much to gain from generating AMP pages -- at least in terms of speed. Google says that AMP can improve page speed index scores by between 15-85%. That huge range is likely a direct result of how many third-party scripts are being loaded on some sites.</p>
 <p>The dependency on JavaScript has another detrimental effect, AMP documents depend on JavaScript, which is to say that if their (albeit small) script fails to load for some reason -- you're going through a tunnel on a train, only have a flaky one bar connection at the beach or any other myriad familiar mobile web scenarios -- the AMP page is completely blank.</p>
@@ -54,23 +58,21 @@
 <h2 id="amp-for-publishers">AMP for Publishers</h2>
 <p>Why require a bit of JavaScript to load what amounts to one of the simplest possible pages on the web? Well, the developers would argue (correctly) that it's needed to parse, among other things, those <code>amp-img</code>, <code>amp-youtube</code> and other non-standard elements.</p>
 <p>It also creates a kind of lock-in. Not nearly the sort of lock-in that publishers get into with Facebook Instant Articles, AMP is after all available for everyone, not just big name publishers who sign a deal with Google.</p>
-<p>So why would publishers want to use AMP? Google, while its influence has dipped a tad across industries (as Facebook and Twitter continue to drive more traffic), is still a powerful driver of traffic. When Google promises more eyeballs on their stories, big media listens.</p>
 <p>In this deal, all big media has to do is give up their ad networks. And their interactive maps. And their data visualizations. And their comment systems. And their community of readers.</p>
-<p>That deal isn't just for big media though, your WordPress blog can get in on the stripped down action as well.</p>
+<p>So why would publishers want to use AMP? Google, while its influence has dipped a tad across industries (as Facebook and Twitter continue to drive more traffic), is still a powerful driver of traffic. When Google promises more eyeballs on their stories, big media listens.</p>
+<p>Unlike Facebook Instant Articles though, this deal isn't just for big media, your WordPress blog can get in on the stripped down action as well.</p>
 <p>Given that WordPress powers roughly 24 percent of all sites on the web, having an easy way to generate AMP documents from WordPress means a huge boost in adoption for AMP. It's certainly possible to build fast websites using WordPress, but it's also easy to do the opposite. WordPress plugins often have dramatic and negative impact on load times. It isn't uncommon to see a WordPress site loading not just one, but often several external JavaScript libraries because the user installed 3 plugins that each used a different library.</p>
 <p>AMP neatly solves that problem by stripping everything out.</p>
 <p>Why would anyone want to do this? Well, most probably wouldn't want to do just this. That is, AMP isn't trying to get rid of the web as we know it, it just wants to create a parallel one.</p>
-<p>Publishers would not stop generating regular pages, they will simply also generate AMP files, usually, judging by the early adopter examples, by appending <code>/amp</code> to the end of the URL.</p>
+<p>Publishers will not stop generating regular pages, they will simply also generate AMP files, usually, judging by the early adopter examples, by appending <code>/amp</code> to the end of the URL.</p>
 <p>The AMP page and canonical page would reference each other through standard HTML tags. User agents could then pick and choose between them, that is, Google's web crawler might grab the AMP page, but desktop Firefox might hit the AMP page and redirect to the canonical URL.</p>
-<p>What this amounts to is that, after years of telling the web to stop making m. mobile-specific websites, Google is telling the web to make <code>/amp</code>-specific mobile pages. Potato, potato.</p>
-<p>Still, hypocritical or not, this is a best case scenario for AMP.</p>
-<p>There are worse possibilities. What happens if AMP is widely adopted in an initial rush of enthusiasm and then abandoned few years later? All those millions of links shared in the mean time will suddenly lead to nothing. Don't forget, without Google's JavaScript library no one can see content encoded in AMP HTML. If history is any guide publishers will get an email letting them know that Google is turning off AMP a few months before it shuts it down and then all those links will just disappear.</p>
-<p>Another common defense of AMP is that AMP is an source project and it's all on GitHub for anyone to critique and improve. Google is fond of open source, which is better than closed in some ways, but not much different in others.</p>
-<p>AMP is not Debian, Google is very much in control of the project, regardless of where it might be hosting the code. No one is going to fork AMP HTML and get the web to adopt your version (if you want to fork something try the satirical <a href="https://github.com/soulgalore/benice-ampproject">Be Nice AMP Project</a>).</p>
-<p>Still, people are stepping in to call out some of the <a href="https://github.com/ampproject/amphtml/issues/517">most</a> <a href="https://github.com/ampproject/amphtml/issues/481">egregious</a> <a href="https://github.com/ampproject/amphtml/issues/545">decisions</a> in AMP's technical design. There are already open issues surrounding nearly every technical shortcoming mentioned in this article. At the time of writing all the issues remain open.</p>
+<p>On one hand what this amounts to is that, after years of telling the web to stop making m. mobile-specific websites, Google is telling the web to make <code>/amp</code>-specific mobile pages. Potato, potato.</p>
+<p>On the other hand this nudges publishers toward an idea that's big in the <a href="http://indiewebcamp.com/">IndieWeb movement</a>: Publish (on your) Own Site, Syndicate Elsewhere, or <a href="http://indiewebcamp.com/POSSE">POSSE</a> for short.</p>
+<p>The idea is own the canonical copy of your content on your own site, but then send that content everywhere you can. Or rather, everywhere you want to reach your readers. Facebook Instant Article? Sure, hook up the RSS feed. Apple News? Send the feed over there too. AMP? Sure, generate an AMP page. No need to stop there either, tap the new Medium API and half a dozen others as well.</p>
+<p>Reading is a fragmented experience. Some people will love reading on the web, some via RSS in their favorite reader, some in Facebook Instant Articles, some via AMP pages on Twitter, some via Lynx in their terminal running on a restored TRS-80. The beauty of the POSSE approach is that you can reach them all from a single, canonical source.</p>
 <h2 id="amp-and-the-open-web">AMP and the Open Web</h2>
-<p>While AMP clearly has problems, and just might be a big conspiracy to lock publishers into a Google-controlled format, it does, thus far, seem to be friendlier to the open web than Facebook Instant Articles.</p>
-<p>In fact, if you want to be optimistic, you could look at AMP as the carrot that Google has been looking for in its effort to speed up the web.</p>
+<p>AMP is not going to help the open web. With luck though, it won't hurt it either, which isn't true of either of its forerunners.</p>
+<p>If you want to be optimistic, you could look at AMP as the carrot that Google has been looking for in its effort to speed up the web.</p>
 <p>As noted web developer (and AMP optimist) Jeremy Keith <a href="https://adactio.com/journal/9646">writes</a> in a piece on AMP, &quot;my hope is that the current will flow in both directions. As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask 'Why can't our regular pages be this fast?' By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole web could be.&quot;</p>
 <p>Not everyone is that optimistic about AMP though. Developer and Author Tim Kadlec <a href="http://timkadlec.com/2015/10/amp-and-incentives/">writes</a>, &quot;[AMP] doesn't feel like something helping the open web so much as it feels like something bringing a little bit of the walled garden mentality of native development onto the web... Using a very specific tool to build a tailored version of my page in order to 'reach everyone' doesn't fit any definition of the 'open web' that I've ever heard.&quot;</p>
 <p>Indeed AMP is very much Google's moderately walled garden response to Facebook's impenetrable fortress of a garden.</p>
@@ -79,4 +81,5 @@
 <p>And therein lies the biggest potential problem with AMP. If Google decides to abuse its position as the default search provider for the web and prioritize AMP pages above others then AMP becomes a threat to the open web.</p>
 <p>So far Google has said that AMP pages will not get any priority over regular pages in search results. But that could change. It's hard to imagine why that wouldn't change. Why would Google have faster pages at its disposal and not prioritize them over slower pages? After all speed is already a factor in rankings and AMP does make pages faster.</p>
 <p>Of course it's hard to tell what AMP will do in the long run. Google throws out new projects all the time, sometimes seemingly at random. Some, like GMail, redefine the world's experience of something previously taken for granted. Other projects go the way of Wave. Remember Google Author? That was the last time Google set out to &quot;help&quot; the publishing industry.</p>
-<p>For the web's sake let's hope Google sticks with AMP. Because if publishers embrace AMP (and the biggest ones already are) and it ends up like Google Author, there's a whole lot of dead links and blank pages in the web's future. Again.</p>
+<p>For the web's sake let's hope Google sticks with AMP long enough to convince publishers that the real future is speeding up their own pages and embracing a POSSE-style approach. As Cegłowski writes on his AMP satire page, &quot;it is 2015, and websites should be small and fast enough to render on mobile devices rapidly using minimal resources... Requiring a readable version of these sites is a great idea. Let's take it one step further and make it the only version.&quot;</p>
+<p>Let's just make sure that fast, readable version is one that lives at a URL on the open web.</p>