As we count down the final hours of 2011 and prepare to celebrate with family, food, and fun, it's time to look over our shoulder and remember what made the last year important. What events defined 2011? Sure, there are political and sports and entertainment stories galore, but I'm more interested in our common friend, HTML5. What did 2011 mean for HTML5?
From where I sit, reviewing 2011 reveals the ascendency of HTML5.
The rise of HTML5 did not happen overnight, or even in a single year. You might say "HTML5," or more generally, the reinvigorated web standards development stack, began its slow crawl out of developer purgatory in 2004, when Apple, Mozilla, and Opera all teamed-up to create the WHATWG (Web Hypertext Application Technology Working Group…rolls right off the tongue). WHATWG stepped away from the lumbering W3C to revive the interest and progress in evolving HTML as a technology that addresses the needs of real app development.
But that was 2004 and this is 2011. We're seven long years from the foundation of WHATWG and the beginnings of HTML5. Why are we only now seeing the meteoric rise in HTML5 interest? Why didn't HTML5 demand more attention in 2009 or 2010? What delayed HTML5's take-off? Three things:
It's important to remember that HTML5, itself an umbrella term for many individual web standards, is at the end of the day nothing more than a "recommendation." HTML5 is not a product being developed by Google or Apple or Microsoft. It's not a "thing" that will ship next year. It's a clearly defined suggestion for how browser authors should make their browsers work.
Therefore, when talking about any delay in HTML5 adoption, browsers are front and center. Developers and users depend on browsers to deliver the support for HTML5 necessary to make the technology usable.
Browsers have been slowly adding HTML5 support for years, but absent strong competition, browsers like Firefox, Opera, and Internet Explorer were content to focus on evolving the "chrome" of the browser (tabs, extensions, built-in search, etc.) instead of the underlying HTML and JavaScript engines.
It took the introduction of a dynamic new browser in 2008- ironically enough called Chrome- that primarily focused on nuts-and-bolts of the web to really get all browsers thinking about the importance of HTML5.
AJAX? A reason that delayed the ascendency of HTML5? Yes.
When Jesse James Garrett famously coined "AJAX" in 2005, it became the singular obsession of web developers for the next four years. Everything and everyone was focused on AJAX. Developers were happy if they could just add some AJAX to make things a little bit more awesome.
As a byproduct, the work being done on HTML5 during this time was largely obscured. Was it happening? Definitely! Things like Local Storage, Semantic Tags, Canvas, and Cross-Document Messaging were all being discussed as early as 2005 in WHATWG's "Web Applications 1.0" draft spec.
Of course, most of these HTML5 things also lacked browser support in 2005, but the interest in AJAX in many ways sucked the air out of the room, suffocating HTML5 interest well in to 2009. Now, AJAX is old news- everyone that wants it has it- and there is air in the room again to talk about the next wave of "Web 3.0" (have we reached a new major version?) technology.
When you talk about HTML5 as an app platform, you're really talking about delivering "rich" software through a web browser (let's set aside new approaches to "packaged" HTML5 for now). That's the allure. The ability to build rich software that runs everywhere, that doesn't require an install, and that you can quickly evolve via centralized, automatic updates.
For a long time, though, when HTML and JavaScript hit their limits, the browser plug-ins (Flash, Silverlight, and even Java) stepped-up to fill the gap.
Plug-ins offered most of the benefits of HTML apps- software delivered through a browser, easily updatable, runs (mostly) everywhere, and, other than the initial plug-in installation, doesn't require installs for specific apps. So, much like AJAX, plug-ins stifled the interest in HTML5. Why search for HTML5 when plug-ins handle the problem of rich, browser-based software?
Developers needed a reason to look past plug-ins for HTML5 to be interesting. That reason arrived with the HTML5 spark.
Apple and Chrome helped spark major interest in HTML5 by pushing the work that had been done on HTML5 while everyone was playing with AJAX to the forefront. This happened in 2007 when Apple unveiled and shipped the original iPhone, and then in 2008 with the introduction of the Chrome browser by Google.
If you recall, the original iPhone had no app store and no "native" model for building apps. The only way to extend the phone with new software was via the browser- a browser which explicitly offered no room for plug-ins like Flash or Silverlight.
This is the match that lit the fire under HTML5.
Suddenly browser plug-ins didn't run everywhere. Suddenly plug-ins didn't have the same allure as "pure" HTML-based apps. The iPhone, with its Webkit-based browser, required developers to re-evaluate what could be done using only the native technologies of the web to build software. It forced developers to evaluate HTML5.
Then Chrome came along and poured gasoline on the fire Apple started. With a ridiculously fast shipping cycle, near invisible (but valuable) automatic updates, and a hardcore commitment to pushing HTML5 technologies, Chrome forced browsers to once again get serious about competing on performance and support for web standards (a necessary ingredient for HTML5 to work).
Apple pushed developers to HTML5. Chrome pushed other browsers to HTML5.
The fire was lit and the conditions were right to turn this spark in to a blazing HTML5 firestorm. All that was needed now is more fuel for the fire. That fuel arrived through some unlikely bedfellows in 2011.
Here are the players: Microsoft, Apple, Google, Adobe, Amazon.
Without context, if you were to guess what all of these companies would be doing together, you'd probably guess they were involved in some kind of ugly patent lawsuit. And 9 times out of 10, you'd probably be right.
Not this time, though. In a very unusual aligning of the world's tech giants, some of the industry's fiercest competitors are all working in their own way to support and promote HTML5. Let's review:
You could even toss Facebook in to the mix, especially with their recent purchase of the team behind SproutCore and rumored HTML5 app platform.
Bottom line: There is near unprecedented support across the industry for HTML5. And 2011 is the year where this support became virtually universal.
Finally, let's put a fine point on why 2011 (and not, let's say, 2010 or 2012) is the year of HTML5's ascendency. I think the actions of this past year make it hard to deny that 2011 will be marked as the year where HTML5 became a platform that can't be ignored.
Collectively, it's hard to deny that 2011 represents anything less than the ascendancy of HTML5. As we exit 2011, we're still at the early stages of HTML5 adoption, and there is no question that HTML5 apps will become more ubiquitous in 2012 and 2013. But HTML5's success in the years that follow will be underpinned by the major steps and historical transitions that happened this year.
So hat's off to an amazing 2011, and here's to even more exciting HTML5 progress in 2012!
Burke Holland is a web developer living in Nashville, TN and was the Director of Developer Relations at Progress. He enjoys working with and meeting developers who are building mobile apps with jQuery / HTML5 and loves to hack on social API's. Burke worked for Progress as a Developer Advocate focusing on Kendo UI.