Friday, April 15, 2011

Beginning the HTML5 Journey

So HTML5 is here - sort of. HTML5 is the new version of the language that "makes the web work". For a working definition of HTML, I recommend a simple search in WikiPedia. Yes, I am sending people to WikiPedia. This new version, still in draft with the organization that oversees the standardization approvals process for this sort of thing, is focused on taking more of the rich experience of the web back to the client side. What that really means is that JavaScript - long condemned by the development community for being slow, unreliable, poorly implemented at times, and more - is being fully embraced as the mechanism to cause user interface change on the client side.

Now, I know some people may want to jump up and start talking about how long AJAX and jQuery have been around. I will go ahead and pause while those individuals go do some searching and come back in shame. You see, those technologies that allow things like changing a screen without refreshing the whole page (AJAX simplicity) haven't been around long. Or better put, they haven't been useful for long.

So, HTML5 is taking all that cool JavaScript functionality, introducing some new ways to draw on your screen, wrapping in a little bit of application storage (formerly done via cookies for small bits of information or, more likely, server-side), and wrapping it up into a functioning standard. This allows the development community to then provide some pretty neat things to our users. Instead of making games strictly in heavy platforms like SilverLight and Flash, they can be more lightly-coded in HTML5 but provide the same experience.

The Food
With all of this goodness, what more could you possibly ask for? Well, funny you asked. The problem that we (collectively) face right now is browser interoperability. FireFox and Chrome have been leading the charge in being compatible with this new version, but each browser seems to have its own matrix of HTML5 components that it truly supports. The most lagging one out there is Internet Explorer. Even now, Microsoft is racing to try to catch up with Google and Mozilla, but there's a lot of disappointment. Let's break down what this really means and why it matters.

Application cache is this handy and simple mechanism allows you to create a single file, called a manifest, that details all of the files on a site that would need to be cached to local storage in order for the site to function while offline. That's right - offline. So, imagine that you write a cool HTML5 game (say a Tetris clone) but you don't want people on mobile devices (or their desktops) to have to be online and go to your site every time they want to play this game. But, if they are online, maybe the game would sync up with the game server and share information like your highest score, the leader board, etc.

This is a great concept - but is only really supported in mobile versions of the popular browsers. For instance, if I get on an Android mobile device, I can bring up this game and download huge files (imagine a role-playing game with a huge map of the world and all these little figures that represent people and places). I can have this manifest file so it all gets stored, go into "airplane mode" (offline) and still play. If I bring up the same site in Chrome on the desktop, it will still download the manifest file and download the files. But, when  you hit the arbitrary 5 MB limit for offline storage, Chrome will opt not to cache it or even tell you it has opted out of doing so.

If I take this same concept to Safari, the mobile will prompt me to increase my local storage (a great feature, by the way), but the desktop version will silently decide not to do this. Internet Explorer - same thing.

The iPhone/iPad/iPod series allows you to create a shortcut to the offline app on your "desktop" (home screen) and even lets the developer customize the icon that will be used to represent it. In this way, you can create web applications (or games) that feel like native applications because they run offline. This is a really great feature and I am surprised we aren't seeing more widespread adoption of this on other platforms. At the same time, I have found no desktop browser that supports this at all. How disappointing.

Final Thoughts
This is all just one example - where there is a multitude - of the same style of piecemeal following of an emerging standard that we have watched from these various companies throughout tech history. Can we expect this to get better? Absolutely. Will it be quickly? Probably not, but there is some good news on the horizon: as reported here, Microsoft's refresh of the .NET platform has some specific targets towards HTML5 in it. As the developer tools become more in-tune with HTML5 outputs, we will see a more rapid transition in browsers, also known as "the real world."

No comments:

Voice Comments