I’ve been talking to people a lot recently about the future of the web as I’ve worked on SproutCore.  I think most people agree on at least two things:

1. Future web apps will be expected to be more “app-like”.  That is fast, fluid, and feature-rich. (the 3Fs of the next web)  Because of Ajax people are less and less willing to wait for their browser to refresh just to change a setting or edit some data.   
2. No one likes plugins.  This future must somehow be built primarily on “web native” technologies - HTML, JavaScript, and CSS with Flash lending an assist where necessary.

As web apps creep towards more desktop-like behavior, they are quickly approaching that uncanny valley, where some switch will go off in users minds and they will suddenly expect web apps to have all the attributes of a desktop app.  Reasonable or not, its up to developers to figure out how to make this happen.

Here’s the fundamental problem:  web apps tend to be slow because they often live mostly in the server.  You take an action, wait on the server to respond, take another action, wait on the server to respond.  etc.  This is just a form of the old “terminal” approach used by mainframes.  Like the mainframes, the performance of an app like this is necessarily limited;  you simply will not be able to make this lag go away.

A lot of people say that Ajax is the solution to this.  In some ways it is but for most apps I’ve seen, Ajax is actually just a way to optimize this terminal behavior a bit.  Instead of refreshing the entire page for each click, you only update a part of it.  (By the way, did you know that mainframe terminals had their own version of Ajax?  It was called the IBM 3270.  The IBM 3270’s primary benefit was-you guessed it-partial screen updates.  It revolutionized mainframe computing…until the PC came along.)

So clearly we’ve seen this pattern before.  Users want a richer, faster more fluid experience than our old terminal-like technology can provide.  Tools like Ajax extend the life of our old model somewhat but they are too limited to deliver the kinds of experiences people will ultimately want.  So how do we solve this?

I propose that we look to the same solution IBM and friends came up with: client-server.

Client-server computing simply means that instead of building one app on the server and projecting it to the browser, you build two complete apps - one on the client and the other on the server - that both share your business logic and can operate on their own, sharing data when needed.  This allows the client to do most things with your data without consulting the server, hence delivering on the 3Fs.  In this case, the client will be written in Javascript and running in your web browser, but that does not change the model.

Thanks to more bandwidth, smarter browsers and faster PCs, the client-server model on the web is finally possible again, and without the major drawback that plagued itin the past.  Before you had to download and install clients onto every machine which was difficult to do and expensive to maintain.  Now, a 200K compressed “web app” of HTML, JS, and CSS can download and start running in just a few seconds.  And for the most part we don’t have to worry about cross-platform issues like before.

But not everything is peaches and cream.  For starters, writing an app in Javascript on the web is akin to writing C on the desktop: it is just one level above the “bare metal”.  When you start building full client apps in the browser, even simple things like displaying a list of items efficiently, can quickly consume endless hours of mind-numbing work to get it right.

The productivity issue can be solved pretty easily though.  You just need a framework that will do a lot of these basic tasks for you.  A good framework that leverages the natural strengths of Javascript and gets you 80% of the feature you need but stays out of your way for the other 20% you need to build can actually make writing these apps easy and a lot of fun.  

These frameworks are coming (SproutCore is one of these, of course), so I’m not to worried about that.  The even bigger challenge for client-server will not be a technical one, but a people one.  Many people in the web world do not have much experience with the client-server model.  Those that do consider this new-old pattern to be counter to the nature of the web.  Adopting this new approach requires some really mind-bending work that many people naturally resist.

In the end though, the fact is that the growing demands from users for fast, fuild, and feature-rich (3Fs) is going to demand that people begin to adopt this model.  Once the frameworks mature that make it easy to build these apps, then the pressure will really be on.  Expect to hear a lot of war stories as technical teams work through this philosophical shift and then expect some amazing work from those that get it early on.

The trends of history are clear.  Client-server and terminal-style technologies rotate in dominance every 15 years or so and client-server’s time has come.  The smart money is on client-server — coming soon to a browser near you.

Tags: Uncategorized //