Seperating Browser from Resource

Disclaimer: this has been said before in different ways – e.g. search for separating navigation from structure or separating behaviour from structure – just adding my spin.

The notion of separating content from style, pretty much, become the accepted norm of web design, the benefits well known

What’s been on my mind recently is the notion of separating browser from resource. By “browser”, in this context, I mean the user interface elements in a web application that allow users to get around (navigate), modify content (forms) etc. while “resource” means documents / content published on a web site.

There are multiple prompts for this line of thinking;

- A personal grievance: I hate writing admin interfaces for web applications. The “front end” – what a site’s visitors see – no problem but the admin interface, which is typically both more complex and at the same time, visible only to a limited use group, drives me nuts – lots of work for people who tend to have very evolved opinions.

- Another personal grievance: I (generally) hate using admin interfaces. Browsing / managing a list of users, for example, tends to be painful. The same admin tools being reloaded on every page request (slowing things down). Switching between the list of users and the view of an individual user tends to involve excessive DB queries (unless I’m being smart with tabbed browsing – ie. violating the intended use of the interface). And things like search functionality are never powerful enough, compared to, say, working on the command line with grep or attempting search and replace (side note: tool name of the year: http://fart-it.sourceforge.net/).

- The notion of REST (Representational State Transfer) as raised in Roy Fieldings dissertation and summarized neatly here. A while ago, Jeff kicked off a discussion on Sitepointforums about REST, asking the question “Is there anything there that we can apply to user interface oriented web applications?”. My interpretation on REST, seen from a web app perspective is “REST seems to suggest you have documents represented by URLs and tools for editing (and perhaps navigating) them.”. Mervyn makes a number on insightful comments in the discussion such as this. The bottom line; “what’s the benefit of a REST based architecture?” seems to be that your sites “resources” (content / data) become available to more than just web browsers – many different types of application can “consume” them (web services, specialised desktop content management tools, blog aggregators etc.).

- Recent versions of IE and Mozilla have decent support for XSLT (as demonstrated by Sitepoints RSS feed). This opens up the possibility of publishing “browser” separately from “resource” – for web browsers they can load the navigation / tools to “browse” a site separately from documents being browsed the while other applications consuming the can simply ignore the stylesheets. A given stylesheet may apply to many documents on the site (perhaps even the entire site) so only needs loading once. XSLT isn’t everyone’s cup of tea but think illustrates the point of having “sticky” user interface definitions, that stay with the browser, while documents / resources are loaded separately.

- Recent IE / Mozilla versions also have “workable” Javascript implementations. By that I mean it’s standards compliance is 95% there and it’s less effort these days to write code that runs fine under both browsers. Bit by bit this web developers are starting to realise that there’s alot more to JavaScript than meets the eye. If you look at this example you get the picture. Powerful user interfaces can be built this way.

- With XMLHttpRequest available in Mozilla, IE and Safari, using Javascript, it’s possible to build “sticky pages” that provide all the user interface elements needed for a site. In other words you begin by loading a page that contains everything needed for menus, tabs and even windows. From the “sticky page” resources can be loaded via XMLHttpRequest.

- Rich web clients, spearheaded by XUL, are on the horizon. I’ve experimented with “enhancing” (in fact degrading in this case) users browsing experience before here using XUL. By providing a “sticky menu”, locating individual documents no longer needs multiple page reloads to traverse navigation normally rendered “inline” as static HTML. In practice DHTML is still a safer bet that XUL today but think XUL is succeeding in getting people to rethink the web as we know it.

The main benefits, as I see it, of separating browser from resource are flexibility and re-use.

The documents / data you publish on your site become (potentially) available for consumption by other applications, other than web browsers, hopefully preserving their relevance as technology progresses. By making this separation an objective, it becomes possible to develop / collect standard tools / widgets (DHTML or otherwise) that can be applied to many sites; perhaps the forerunner here is the desktop blog aggregator. Being able to “grep” or search and replace, as a site administrator, using the same command line utility has a higher probability.

As a side effect, bandwidth is also preserved and perceived performance, from the point of view of an end user, should be improved, as the UI is only loaded once.

Anyway – this ringing true with anyone?

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • meryn

    I totally agree with your analysis. Finally, web technologies begin to mature, and will allow application developers to make full use of the power of the web architecture, also known as the REST architectural style.

    Web application developers should design their applications in a layered fashion.
    They can use a web server to expose a stateless (RESTful) Service Layer to the web.
    On top of that comes a the UI layer written in DHTML, which interacts with the Service Layer through HTTP. The added bonus is that other applications can reuse the service layer. (HTTP Service Layer ~ Web Services)

    Developing web applications in this manner will eliminate the need to store user session state on the server, because the user session state is kept entirely on the client. In the browsers memory, in javascript objects to be precise.

    See http://www.martinfowler.com/eaaCatalog/serviceLayer.html for a definition of Service Layer.

  • meryn

    A very succesful example of a HTTP service layer is the Atom API, a standarized API for CRUD operations on blog posts.

    See http://www.atomenabled.org/ .
    There’s also a DHTML user interface for this API, which can be downloaded from http://www.isolani.co.uk/blog/atom/JavascriptAtomApiClientUsingXmlHttpRequest

  • Pingback: SitePoint Blogs » MVC and web apps: oil and water