Yahoo’s purchase of Oddpost and IBM’s acquisition of Alphablox has sparked off a discussion on rich web applications. Phil Wainewright points to a post by IBM insider Koranteng Ofosu-Amaah :
The “rich web application” strategy is a very powerful appproach to development – and one we first used when I was when working on Lotus K-station (the post-mortem on that is for another day). It entails complete leverage of the browser which, after all, is the ubiquitous client. If the browser adds features you inherit them automatically. A short description of what I think is needed:
A client side framework for managing ‘widgets’; an ‘widget’ is construed as a parameterized blob that produces markup (either in-line html or iframe-based). The data model is pushed to the client, the page is stitched together on the client, augmented by chrome and a code layer handles drag and drop, preview mode, incremental rendering and client side caching etc.
The idea is to fetch an HTML skeleton, decide what content you need, fetch that as XML, and cache it wherever you get a chance. Render incrementally.
The pattern is simple:
Database XML (Optional) Javascript Object Bindings UI Bindings (HTML) + UI management codeAnd: It’s the Latency, stupid.
When dealing with distributed applications, it’s the issue of latency that will determine which applications will rule. Users ultimately want applications that are 1. fast to load 2. capable and 3. intuitive. They want all these at the same time. This is where making increased use of the DOM should shine compared to most simple html based UIs. Of course, you have to work hard when writing DOM apps to figure out where in your architecture you can do things incrementally and where to cache. But that’s what engineering is all about and how one would get paid.
In K-station the ‘widget’ was a portlet, your portal pages was the drawing canvas that the framework managed and you could navigate from page to page, incrementally building your page in memory and switch back and forth instantaneosuly. With client-side caching, all you’re doing is the css display property. In the presentation editor, the analog of the widget was a drawing object (text, image, group etc). GMail and Oddpost follow the same pattern and it is the incremental rendering and caching that distinguishes them in their performance characteristics and makes them ‘feel’ like desktop apps.
The major missing infrastructure piece in rich web applications is going offline and synchronizing with good security.
An interesting point made by Koranteng: “Mozilla is now the best platform for doing such development.”
