Collaborative web applications

This week, I'm going to step back from AGCA and start venturing into some higher level topics.  This week, let's talk about web applications.  

Not just any web applications mind you, let's talk about collaborative web applications.  The term is new, but the idea isn't.  You've probably heard of at least a few of the following: Google Docs (aka, Google Drive now), Google Wave, Office 365, Dropbox... 

These applications are pretty nifty.  They allow you to log in from wherever, and edit/view documents.  But not only that, they also allow you to interact with other users of the same system.  If someone else opens up the same document, they see any changes that you make as soon as you make them.  In other words, the state of the application is mirrored in realtime across all the browsers in which the application is running.

Building these applications in a web-browser also forces you to rely heavily on the browser metaphor, HTML5 functionality, and on HTTP.  Integrating an application's design with this ecosystem is often kludgy, but can bring several extremely nice benefits:

• A distinction between communications channels and communications sessions: You usually can't rely on a single, stable connection to the server, so the communications protocol will typically place each message in a separate HTTP request.  This in turn means that the application is resilient to being suspended (i.e., switching apps on an iPhone, or putting your laptop to sleep), or moving across networks (switching from cellular to wifi, or plugging your laptop into an ethernet jack).
• Stateless servers: The use of HTTP generally encourages servers to be stateless -- each request is served in an identical manner.  This means that the server can be designed to scale, without sacrificing the client's ability to suspend/resume its participation in the computation.
• A Refresh Button: Web browsers have a refresh button.  The application has to be resilient to users pressing it if something is misbehaving.  This in turn makes error recovery much easier -- if the application is misbehaving, restarting it is trivial.
• Layout through the DOM: Web-based applications have been designed from the ground up to be GUI-oriented.  A text-based interface is possible, but frequently more work than a simple graphical user interface.

Applications like this are incredibly cool, and incredibly useful.  So why don't we see more of them?

• Why doesn't blogger have the same functionality?
• Where are the collaborative whiteboards?
• What other kinds of awesome applications could you implement in this space?

The short answer is that the infrastructure isn't there.  And it's hard.  Ask any first-year distributed systems student -- they'll tell you that state replication isn't easy, even when your data is only coming from one source.  Web developers are used to dealing with nice, simple, standardized backend infrastructures.  Apache, MySQL/Postgres, and maybe some sort of CMS like Django are reasonable expectations... but none of these support the sort of scalable realtime state replication required to implement a collaborative web application.

Just a thought.