Wednesday, January 20, 2010

Does Browser HTML5 Support Matter?

A few weeks ago I watched a saddening interview that a Google guy conducted in NYC; What is a Browser? It was sad because effectively no-one even knows what a browser is. The neat thing about that fact though is that the browser is so ubiquitous that people don't even know it exists.

The other day a co-worker and I were talking about whether or not HTML5 stuff matters anymore. Did Flash get enough market coverage to own "rich" client-side-software forevermore? Will content developers use HTML5 stuff? Are content developers relevant anymore? These are the kinds of questions that came up in the conversation. Here's my perspective.

It's done a lot for us (thanks Macromedia), but it's still too proprietary and takes too much tooling to do anything interesting with it. Furthermore, video quality (at least what the industry has adopted) is pathetic, and in a world wherein video is becoming more and more relevant (thanks to ease of production of HD content, as well as increasing bandwidth), it's not going to cut it much longer. There's a quarter-ton of Flash content out there though (e.g. YouTube), so, in some capacity, it's here to stay for a long time.

Content Developers
HTML5 exposes some incredible functionality at the JS/HTML/DOM levels. However, while the erosion of the plugin API walls allows for a more fluid/native/stable browsing experience, today's Content Developers aren't going to be able to leverage most of the features directly. Relatively complex programming concepts are making their way up the stack which is great (un-chain the beast!), but the Content Developer brains out there aren't going to map 1-to-1 with the skill-set it takes to harness the beast's strength. New tool chains (ala Macromedia/Adobe app suites) will have to emerge in order to allow today's Content Devs/shops to build using most of the new features.

Put another way, the folks I know leveraging , web sockets, & new local storage interfaces in interesting ways are heavy hitting engineers. Convenience libs will evolve however, and the masses will be able to leverage the new features in the end. It'll just take some time.

Will the features get used? Or, if they build it, will developers come?
HTML5 implementations will yield the most significant browser innovation in a long time, but who's pushing for the changes to begin with? Google for one. Last year's Google I/O conference was a HTML5 circus; I was shocked. I'm stoked Google's pushing hard on HTML5 content/app creation, and apparently betting their entire app strategy on it. I'm still perplexed by Chrome though, and am convinced they're using it simply to stoke Mozilla into building all the right features into Firefox, at which point they kill Chrome. Firefox will do the right thing, of course, w/ HTML5; they're pushed by community & Google. Apple's still off in the weeds with Safari/WebKit; I hope they do the right thing w/ HTML5, but don't really care (other than insofar as it affects my iPhone browsing experience). Microsoft... who cares (other than enterprise which has billions invested in a toolchain that won't adopt HTML5 stuff anytime soon); they're irrelevant in my world anymore.

So, if you resolve that the browsers will provide "good HTML5" support, who will predominately use the features? Will today's content dev shops announce to their clients that they support "HTML5" and build to it? Or will it be the firms building the browsers themselves (e.g. Google) that have vested application advancement interest?

Ten years ago I would have said the developers would dictate and bring about the changes. Today... not so much. If HTML5 goes anywhere in today's world, it will be because the big guys pushed it, promoted it, and built to it. The world has changed in this regard.

What is "good HTML5 support?"
The stuff that matters, and why, in HTML5 follows.
  • . we haven't been able to natively draw yet. c'mon.
  • offline data storage/caching. use gmail on an iPhone to see how powerful this is. you can't build apps without state. you can't build real apps without persistent state. offline data storage will bridge a huge gap between "online" apps and "desktop" apps.
  • web sockets. this feature has the most potential; both to do evil and good. apps being bound to obfuscated HTTP interactions has been extremely limiting to the content/web-app dev tier, so opening connections up to the page/JS will be powerful. However, the thought of some of the folks who build web-apps having access to a socket also gives me chills.