MoreWhite

The World Wide Web was not designed for Web Applications, and is a dead end for application developers. Let’s put things into perspective.

After TCP/IP has been standardized as the protocol of the Internet, Tim Berners-Lee invented its first great application - the World Wide Web: a simple collection of hyperlinked documents. Each document is identified by a fixed URL address, and written in a mark-up language called HTML. The documents are meant to be viewed in a web browser, which in turn uses a protocol for publishing and receiving HTML documents known as HTTP which works over TCP/IP.

This web of information proved extremely popular for large text collections, such as newspapers, encyclopaedias, blogs, etc. Similar to Adobe Reader and the PDF format, the web browser - a simple tool for reading and navigating HTML documents, proved extremely easy and safe to use for a long time. Web directories such as Yahoo! were created in an attempt to classify all of these documents, and make them easy to find.

Everything was simple until developers figured out a way to generate HTML documents dynamically, for each client request. Instead of static documents that are published by users and read by users, these documents are generated using an application and can thus be different for every user. A way to pass parameters along with such requests in URLs also became popular, allowing HTML pages to act as functions, rather than documents. Such functions quickly became building blocks of complete applications that visualized their results using the popular HTML format so that they could also be accessed through the browser. This highly inefficient approach has many flaws, most notably:

- Whole document has to be generated and transferred to the client even if a small part of it changes with each request.
- Applications typically have internal state that browsers don’t know anything about. This state may be lost if the user navigates back or to a random document altogether.

More concrete approaches to delivering applications inside the browser, such as Sun Microsystems’ Java Applets and Web-Start have failed miserably. Downloading and running code on-demand inside the browser almost seemed a failed cause. That is, until JavaScript proved that HTML documents can be made more interactive and animated without giving up on security. As browsers evolved, so did their support for JavaScript – a hack used to embed code within an HTML document. Most importantly, recent support for the XmlHTTPRequest object allows JavaScript to request new documents in the background, and update parts of the current document without user’s intervention – a technique commonly knows as AJAX.

It is amazing how far we have stretched the WWW and humble HTML, without ever considering its intentions. AJAX now allows us to interact with an application as if it’s a single HTML document. We have successfully hacked existing technologies into a way to deliver something it wasn’t meant to, moving ourselves away from the hyperlinked web of information published by people.

Google would me ultimately perfect without such hacks, and information on the web would be much more readily accessible, not hidden behind applications and databases.

Content on the web should be static, with a unique address – URI to identify it and share it with others. The purpose of applications is to create that content and publish it on the web, rendering it as HTML document, be it a database, a blog, a word document, etc. But why should these applications be HTML documents themselves, when HTML is extremely poor in rendering common software components, and was never designed to do so? Why can’t we stick to interactive desktop applications, like iPhoto, iWeb, and allow them to publish our content to the web?

Is it because web applications are easier to write? I don’t think so. The main reason is *accessibility*. We want users to access our applications without having to download, install, and configure them. We also want our data to reside on servers where we can access it from anywhere, but that’s not really an issue – desktop applications can easily save our data remotely, to iDisk, WebDAV, or an FTP drive.

What we want is for the application code to run on the server, yet have it draw the user interface as a typical desktop application on our screen. Sounds impossible? Not at all, such technology has existed on Linux for years: simply launch a remote application and tell it to draw on client’s X server. However, this has never really taken off primarily because of speed issues. The problem is that the application draws primitives – lines and shapes, instead of pre-defined components (as with HTML), requiring large network throughput.

An alternative approach, somewhat similar to HTML, would be to define a standard mark-up that can be used to render the UI of a desktop application. Such mark-up would define common UI components (textbox, toolbar, menu, window, button, etc) as XML elements. Similar idea will be used in Vista, knows as XAML. UI events will cause new requests to be sent to the server, and only the required changes in the UI will be sent to the client. Thus, an application can be launched by providing the ‘application browser’ with the URL of the document containing UI mark-up. The browser can then render the mark-up using operating system’s native GUI library.

Such an approach would mean total security too – no custom code is ever run by the client. Alternatively, support for JavaScript will make such applications more ‘offline’, and will require connectivity with the server only for data access – as with AJAX. In either case, it will bring the same UI standard experience to Internet applications.

I plan to begin working on this in the near future. One question still bugs me though: what if users actually prefer the look and feel of HTML-based applications? Would you want Flickr to look like a desktop application?