Over at theserverside.com Alexander Jerusalem wrote: Does JSF + AJAX really make sense? He raised some serious questions about how should the client and server interact and how could we maintain the server state when the client updates the form elements dynamically.

His worries are very well founded and stem from the fact that current web application frameworks are mostly server centric. The server is playing a monoply on the data model, action control and even view state.

Here's a look from the other side of the fence. I was not doing much Java development as of late and instead of using bell-and-whistle based frameworks I was participating in a big project that had the following properties:

• Huge client base that consumed the processing power and the bandwitdh of the server(s)
• Distributed implementation which should be done as simple as possible due to time constraints
• Distributed data set (per user data are private and thus caching has no real system wide effect)
• To stress the first point. Processing and bandwidth were at premium! we had to save on both.
  

Now the server centric frameworks that are all around us are far from suitable for such a beast. In fact it does not have to be a beast at all! We followed the KISS model and made ourselves a winner!

Recipe for success:

• Build a stateless server application (only loggedIn? should be tracked)
• The server only responds to fine grained actions (for some actions the server responded with JSON data, for most of the action the server simply said: "ok")
  
• Put this app on as many servers as you wish as long as they share the data and can share the loggedIn? peice of info.
• Build a statefull SPA client:
• Full model and model cache (use the cache to avoid visiting the server often)
  
• Full fledged controller (the client decides what happens next)
  
• Complete View rendering and management (Javascript templates any one?)
• Connect everything using Ajax and JSON (how thinner can we get?)
• Forget about HTMLUnit (use your own Javascript infrastructure to test and direct your DOM)

What was good about such an application?

• Fast prototyping
  We managed to get a prototype (no server side thing) up and running in no time. Even during development the evolving prototype would be one step ahead by relying on static data rather than server responses
• Prototype reuse
  The prototype actually became the application! It was continously under refactoring but the team managed to always keep it under control
• Real Distributed Application
  The clients now do the controlling part and the parsing and rendering of view templates. They keep the view state and the model state (through the cache) only updates are propagated to the server. Much less processing on the server(s) now
• Bandwidth Savings
  Down to 25% of the original bandwidth consumption (more savings expected) and due to decreased server load we are now able to use mod_deflate for even better savings
  

So did we find ourselves a killer framework for next generation web apps? I doubt! but I believe that we have now the optimum solution for our type of problem. Some other problems might need different solutions and might not benefit from such an approach. But to see Alexander's words in another view: Yes sometimes Ajax and JSF dont co-exist. Sometimes you'll need to drop JSF for Ajax to work the way you want!