Wednesday, August 19, 2009

Browser as a Platform, HTML 5, WebSockets

In 2009 QCon London presentation "Browser as a Platform" Mozilla’s own Ben Galbraith and Dion Almaer presented their view of current state and potentials for the future state-of-the art in pure browser based applications. Very enthusiastic and entertaining presentation, lots of familiar icons and visuals from many organizations, some Bespin tease, all great stuff and fun.


But it got me thinking more about aspects of HTML5 that got very limited spot light (at a bit unfortunate cost of constant comparison to Flash and other plugins) - WebSockets and Server (sent) Events.

WebSockets and Server Events should become the real game changers of the browser world. Rendering technology (HTML DOM and JavaScript) issues and browser issues (threading et al.) are mere growing pains of an infant, but it is when we start looking at (and talking about) full duplex communication capability from the browser (WebSockets) and about standardized browser "PUSH" Comet style (Server Events), we'll know we've reached the maturing phase of an adolescent first class, full fledged presentation technology.

Communication is the key.

HTTP served us great as an information exchange protocol over many years, achieved great standardization and ubiquitous penetration. It enabled new architectural styles such as SOA; it is deeply reflected in REST, among many others. It also held the information flow back a little bit, which could be good and also bad. With browsers, it held it back.

Post-back driven web applications of earlier times, even with AJAX "wizardry" of late have kept the browser from becoming first class player in presentation technologies. Not that there are not great examples to the contrary, there are many amazing applications delivered in plain browser client.
But any first class player has to be able to achieve this in a simple, easy and replicable manner. It maybe simple, it is not always easy and not very often replicable to deliver browser application where user doesn't notice there is a browser involved and is interacting with the system in natural and intuitive way. Applications need to be specially tailored, users need to be trained.

It is the limited information flow paradigm that has held the browser from becoming first class player, capable of delivering of any application to all users, even more than the browser and presentation issues. After all, simpler presentation is often better and as great as Canvas and SVG (RIP?) are, their utility is centered around specialized set of applications.

But in any case, only after the information flows naturally to seamlessly enable application's flow and support user's thought process, can we present the information effectively and without technology infused stops and gaps. That is why I see the changes introduced by WebSockets and Server Events as profound and truly significant additions to the capabilities of browser based applications.

We'll still probably hear more about the presentation aspects, JavaScript Engines and threading tweaks of the next generation browser and standards, but the more we hear, talk and focus on the information flow features, the further stage has been reached on the Hype Cycle of "New" Technology.


No comments: