AJAX Requests – Data or Markup?

I just got back from the Real World AJAX seminar in NYC on Monday.  Pretty good event with lots of good stories. 

One issue that caught my attention was the issue of how the back-end returned the data to AJAX applications.  Most of the speakers preferred data, except for David Hansson from Ruby on Rails seemed to favor markup as the return type (at least that is what I understood him to say). 

This debate is pretty interesting.  From an Enterprise Java standpoint, the decision I believe has implications to the usage of the JSF, Struts, and Portals (in a JSR 168 sense).  Look at the picture below:




As I look at this, and think about non-functional concerns (clustering, security, etc...), the middleware can become quite complex.  JSF and Struts applications usually put a beating on Http Session, Portals even more so.  We now have duplication in MVC, both on the server and the browser.

I believe, from an enterprise standpoint, Ajax applications are better suited for exchanging data with the middle tier.  This makes the middle tier much more stateless, and therefore much more scalable.




The browser does become a bit more complex.  (Although, in the prior picture, the browser would still have a considerable and almost equal amount of work to do).  the additional work is managaing some state (the same as a well designed Http Session App with small foot print) and translating the data from some XML format to JavaScript.  In many cases this work has to be done somewhere in what is considered a web tier, because the business layer will not serve up mark-up.

If the UI workflow becomes more complex, then one should look to BPEL type engines with Human tasks and not complicate the issue with too much custom middleware.

Of course the initial hit to the server would have to go through some type of MVC middleware.  So the Struts, JSF, and Portals of the world will still have to serve up the inital pages, but from then on.

Eventually, I wonder if the initial hit could even be rendered by the browser with the server serving up some full XML document that the broswer knows how to translate to a full page.  There is much CPU out there in client land that we can take advantage of.  Although, the danger of the second coming of Fat clients has to be dealt with, we have to make sure there is no business logic out there or else security becomes a big concern. 

The browser should.

• Invoke services on the server.
• Move data from structures to Widgets.
• Collect input.
• Store minor state (multi-page wizard updates, some session id, etc...)
• Render Widgets.