The return of client-server

As I've been planning and prototyping my next major project, I realized that we really haven't figured out what the optimal archicture for Web 2.0-type applications is yet.  The big difference is that some of the application itself lives on the client now, not just the HTML that the back end spits out.  There's plenty of documentation out there on writing pre-Web 2.0 Web applications, but it's still pretty much up in the air as to how much of the application should actually live on the client versus the server.

I'd call this another application layer beyond the presentation layer, because it's not just presentation.  A lot of the new Web applications out there (e.g. NetVibes) live almost entirely on the client, and just use the server to store data.  In fact most of the new Web applications use the client not just for data presentation and manipulation, but also for input validation and even storage (the use of Flash as a small-scale storage medium is blossoming).  It's almost like adding that old client layer back in from client-server computing.

The problem is, it always takes a while to get new architectures right.  I've found that when I use services like NetVibes, once I create too much data and the client app gets too fat, it starts to break.  But from what I can tell, they use the client to render the windows, lists, feeds, pretty much everything.  I don't really think JavaScript is heavy-duty enough to handle that much of the application, and I don't really care to start worrying about system specs again in the future.  With $100 laptops coming, the client side has to stay lean and mean.  I actually just found a post by Phil Wainewright describing the service model of Employease, which I think is a great example of a good architecture in this new world.  That is, they provide a list of services that can be called from either the client or another server, depending on the business need.

On the other hand, users are getting used to rich client experiences, and there even benefits to it.  For example, pretty soon we'll be able to use the client for identity verification and personal security.  And we'll be able to use the clipboard in our browser experience.  And lots of other cool stuff.

I don't think any of the regular big boys in software development have really figured it out yet.  Microsoft is trying to straddle the fence on this with their Atlas API, but they're getting terrible reviews and the code it generates is way too fat.  I think Dojo is by far the best designed API out there, they have the right idea with providing rich-client Widgets and offloading the heavy lifting transparently to the server with their great IO engine.

Somebody needs to do a study on rich client scalability and architecture design, or maybe it's out there and I just haven't found it yet.