Pragmatic Dictator

Observations on the long running “browser as a platform” debate.

We often talk about browser-based apps but really what we’re talking about (at least for now) is browser-accessed apps (web apps). This is because the browser doesn’t really house much app logic – it mostly does the presentation and bundles up data for processing by remote logic. AJAX has made it easier to do this in more user-friendly/intuitive ways but the computational load and location of logic is clearly at the back-end.

The browser is a powerful force in that it’s pretty much on every desktop. It’s become part of a computer’s DNA. Delivery of an “app” via the browser means it can permeate to virtually all desktops and is endowed with the appearance of “zero install time”. Of course, we forget about the time spent downloading and installing browser upgrades and plugins because it’s been made “low-pain”.

It’s widely held that the bulk of innovation goes on in the browser but that’s at least in part inaccurate – the innovation is in the apps themselves which typically exploit the increasing level of networked’ness that is a hallmark of today.

The current divide of web app logic between browser and web back-end has another benefit. Essentially it endows the app builder with the ability to choose their deployment platform. The front-end (browser) has a limited but well understood set of presentation technologies (HTML, JavaScript etc) that the back-end must deliver against but one can use pretty much any back-end technology to generate the content to be consumed by the front-end. Thus the app builder can select their preferred webserver, libraries, languages etc for the task knowing that it has almost zero effect and dependency on the front-end. However, note there is some pain out there caused by variations in browser behaviour which mimics the kinds of trouble desktop-based apps face daily.

The nature of networking (bandwidth constraints and latency) exerts some force on the architecture of web apps which means we must use single bulk refresh to do the work rather than lots of querying. And bulk refresh is slow, AJAX helps here because we can hide that bulk update in the background to some extent but there’s a computational penalty in the form of polling.

One thing web apps aren’t so good at right now is exploiting the typically huge number of spare CPU cycles available at the client-side. All the load is in the data-centres and networks, a classic centralized architecture with all the usual scaling issues. Perhaps the most significant aspect though is how un-green this is. Surely there’s some sense in utilizing that client CPU for more than just presentation logic?

Expanding use of client-side compute power beyond presentation will begin to change the architecture of the typical web-app. For it to work we’ll need to do more serious app logic client-side which might take us back to longer downloads of that logic and threaten the “zero cost of install” perception. It’s also possible that browsers will need to support more sophisticated programming languages. The browser as a platform could become more difficult of a concept to execute well because we will encounter challenges such as providing consistent API behaviour across filesystems etc. We’ve seen these kinds of problems played out previously – Java anyone? One possible way around the API issue might be to adopt a more abstract approach such as having the browser provide all this stuff via a REST-based web interface available to in-browser app logic.

In complete contrast to the web app is the desktop app where rather than do almost all work in the back-end on the net somewhere we do it all in the front-end which limits computation and storage to what’s “near” (on or accessed via networks local to) the desktop machine.

Likely as not the ultimate solution is a hybrid of web and desktop app – seamless integration into the browser with sufficient client-side desktop API access to make genuine client-side processing easier whilst accessing network resources like servers and storage so users can “break out” from the limits of their own machine. The trick will be in defining a workable limit to browser APIs and programming languages which balances the need to avoid the cross platform consistency issues against sufficient functionality to make client-side apps appropriately powerful.

Technorati Tags: architecture, distributed systems, web

This entry was posted on Wednesday, February 14th, 2007 at 5:09 pm and is filed under Architecture, Distributed Systems, Web. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.