Mark Pilgrim writes good stuff about the Model-View-Controller architecture, but misses one of the main reasons to use it: asynchrony. An MVC application is inherently capable of running asynchronously, with very weak coupling between the model, view and controller. If you're building an Internet-scale application, latency is horrible and unpredictable, and RPC-driven patterns make the latency problems visible.

This reminds me of the second time I visited Groove (almost two years ago now, the snow around Beverly was a foot deep, and we stayed in the nicest B&B ever). I was talking with Ray and saying something vague about a epiphany I'd found at LambdaMOO: that you can build sophisticated asynchronous groupware atop a realtime platform (MOO activity is mostly chat, but everything's persistent, and beside the realtime interaction in rooms there are lots of really powerful applications there ranging from mailing lists through to a byzantine political system), but not vice versa (Lotus Notes will never deal with simultaneous document manipulation in a seamless way, because the platform exposes nothing at all about presence or sessions or real-time users interacting). So I was well pleased that Groove's infrastructure is built on realtime awareness and a "live" distributed object model. I called this "synchronous" and Ray corrected me quickly: "No, it's all asynchronous". That took a long while to sink in, but it's absolutely true and really critical. All the network operations in Groove - their entire MVC-based model - are completely asynchronous: fire a message, and it'll be delivered, but please don't wait for a response before carrying on with your own local operations. This is the most asynchronous system I've ever seen, and it works because of message queues.