What we need is a Web browser that doesn't just serve up documents, but serves up applications."

Early in 2006 I was given a design brief: a UK-based shipping company wanted to replace its shipment tracking system with a Web-based solution.

Its existing system consisted of this: each widget grower had a contract with the widget producer; this contract was tracked via an Excel spreadsheet; every Friday the shipping company would e-mail the latest copy of the spreadsheet to the widget grower, which would fill out the details of the latest shipment and the details of each and every container in that shipment. This would then be passed back to the shipper, which would then forward it to the widget producer, which in turn would fill out the production usage, quality control results, and the dates and times of when each container load had been used. They would forward it back to the shipper and the cycle would continue. Add in the two separate ports and warehouses in the U.K. and about 16 contracts with different widget growers in countries as far away as Brazil and South Korea, and you start to see that keeping track of the latest version of each spreadsheet, where it is, and what is happening to it was beginning to become something of a mission unto itself.

This is where I came in. The simplest Web-based solution to this would be an online document store in which the widget growers, shippers, and producers could just log in, check out a spreadsheet, edit it, and check it back in. Instead we landed on the Web 2.0 solution: a truly online spreadsheet, tailored exactly to the task at hand, with permissions set on data fields (so that a widget grower couldn't cheekily amend the widget producer's own quality-control results, for example). The whole thing would be in real-time and delivered through Internet Explorer.

This is the sort of real-world application development leveraging the Internet that goes unnoticed by the photo-sharing, music-downloading, blogging masses. In the same way that the largest fraction of software developed and deployed in the world is internal business software, not games and file-sharing clients. As such I had an advantage; this wasn't to be some Microsoft Office Excel killer, it was a tailored, targeted, bespoke application that would look a bit like a spreadsheet but behave exactly like a widget-growing, shipping and production tracking application.

After several months of meetings, prototypes, and endless hours of debugging, the final product was rolled out this summer. The client is happy; their clients are happy; it works exactly as designed; it can export to Excel; you can copy and paste in and out; and it works on IE6, IE7, and Firefox 1.5. I collected my paycheck and they've been using it without any problems ever since.

It does, however, contain over 2,000 lines of JavaScript, and the "spreadsheet view" is an HTML table, with HTML embedded links and images to power said JavaScript. The rows are inserted via the DOM and to edit a cell in a particular row the script has to copy the data from the table row into a faked-up hidden "edit row" containing text boxes using CSS that's hacked to pieces and swapped with the original row. The Save button at the top left of the application cycles through every table row on the page, checking against a bunch of custom attributes slapped into each TR tag to decide if the row needs deleting, updating, or inserting to the database. It builds XMLHttpRequest objects and loads them with a custom CSV-style mashup of data to be sent to the server, which in turn sends a similar mashup back, so that the data on the screen can be kept in sync with the data in the database...on the other side of the planet.

I find myself in a bizarre position. The fact that I'm an expert in this kind of thing and have the technical know-how and aptitude to design and pull off such a complex beast on time and as designed means that I got paid quite well for the six months it took to develop, and I'll continue to get paid as and when upgrades are needed. If any old John Doe could have opened up Visual Studio and slapped it together then I probably wouldn't find myself getting paid quite so much for my services. But the thing is it really could be that easy, or at least, close to it.

Instead of a dedicated platform for developing Web-based applications we have HTML, the DOM, JavaScript and the funderful XMLHttpRequest object. Instead of declaring a pair of <DATAGRID> tags in HTML, I frankly had to hack the %$#@ out of a <TABLE>, normally a static read-only piece of a static read-only document. Compare the Visual Studio .NET Windows Datagrid with its Web-based counterpart. There's no comparison: a confident user of the former wouldn't immediately be able to even recognize the latter.

Finally we get to the rub: The document-based Web as we know it is not a platform for developing complex applications; sure it's possible and there are plenty of bright people working at places like Google who are doing it as we speak and creating frameworks to make it easier. But is this really the way forward? A tree-based object model accessed by an interpreted scripting engine tacked onto a specification designed for static read-only documents?

Now would be a really good time in history to stop, step back, and look at what we have and what could be done better. What we need is a Web browser that doesn't just server up documents, but serves up applications: full screen native GUI, network-transparent and, most important, fast, lightweight, real-time applications. Ideally we'd want to start over, build a whole new spec running on an entirely new platform and set of protocols.

It's unlikely to be that easy. Java promised us Internet-based apps, but spectacularly failed to deliver anything other than mobile phone shoot-Œem-ups. Flash is only just beginning to be taken seriously, and may yet mature into something business can use to track its widgets. Let's take a moment to dream about what we could have.

First, it would be easy to write for with a choice of languages ­ the current request-response framework of the Web can be catered to by PHP, CGI, and ASP to name just three. Write your app in one and you get to access the posts, gets, and cookies natively. So it should expand on that and have a native client object alongside the server object so an author can simply call:

client.Document.Forms["someForm"].txtSomeInput.value = "hello from the server"

And have the asynchronous action happen without any extra effort. And the reverse should be true: the script in the browser should be able to asynchronously call server functions like this:

function btnMyButtonOnClick()
{
     doSomething();
     server.doSomethingWithTheDB( gsFavouriteColor ); doSomethingElse(); }

Again, the legwork would be done for you; a newbie programmer would be able to create something like this in no time, but true enlightenment wouldn't be needed. Custom objects and classes should also be transparently handled across the network, but we don't want to belabor the author with XML and SOAP, it should "just happen."

Second, it should have state, and that state should begin by initializing the application's main source file on the server when the client first connects. The application would maintain state between calls, allowing the use of global variables and custom classes that persist. Calling an async function from the client would begin a thread on the server app, but the advanced programmer could, if he wished, have power over this too and create a call stack, for example, to force events to occur in the order they were sent from the client (not necessarily the order they arrived). Finally, unlike the current Web methodology, there should be a clear disconnect event sent when the user closes the window or a connection stay-alive ping times out.

Thirdly, each user of the app would get his own instance on the server, but these instances would be able to access the Master Application that contains them all, and all its public functions and classes. A chat application, for example, would be able to access the channel list with just a call to application.fetchChannelList(). And to pull up the details of another connected user with application.getUserDetailStruct( intUserID ).

Finally, the author wouldn't be forced into using the current HTML DOM and its small inflexible set of user input controls. There should be a much wider range of inputs, controls, panels, and widgets and has a native grid-based layout system. I keep mentioning the MS Datagrid over and over but imagine being able to create a small spreadsheet object in just a few lines of code and let the user add, insert, remove, and edit rows and columns in the comfort of his own native GUI. This object wouldn't need serializing and sending to the server as far as the author is concerned, pressing submit would give the server a mirrored copy of the control, with full access to its innards.

Such a thing is possible, and we need it sooner rather than later. It would seem simplest to treat the project in two halves. The first half of the challenge is to integrate the new user controls ­ where possible ­ within the existing Web framework. The WHATWG Web Forms 2 and HTML 5 spec are already headed down this road, with such simple but badly needed inclusions as date and time inputs with in-built validation. The second half needs a paradigm shift, a move away from the top-heavy and stateless HTTP protocol to a true lightweight binary client/server relationship between the user and the application.

The thing is a lot of the inherent problems in such an approach have already been solved: Connectivity and synchronicity over a slow or unreliable connection? ID's Quake addressed this 10 years ago and so too has almost every FPS since. Cross-platform compatibility and interaction? Any number of file-sharing and chat applications will yield the answer to that one. All it takes is the will to step away from the Web browser and start something new. As a final thought it might be worth noting that for 20 years now the X Windows system has allowed the development of applications that can transparently display their GUI on one computer while doing the actual processing on a server somewhere else...probably the other side of the planet. Sound familiar?