Dave Crane >> Nobody likes a web framework or twenty more than the java community, of which I'd count myself a member, I hasten to add! On the one hand, Ajax steals some of the thunder from the server-side frameworks. It's possible to write fairly autonomous clients in JavaScript that just hit the server when they need data, in which case, much of the presentation tier disappears. On the other hand, it's possible to modify the presentation tier to generate smart-client Ajax code instead of static HTML, in which case the presentation tier framework very definitely still has a job to do. I tend to lean towards the smart-client-and-data architeture, but I'd hesitate to say that that's universally the right way to go.

"Ajax steals some of the thunder from the server-side frameworks..."

Java is keeping up on both these fronts. On the one hand, there are the afore-mentioned Tapestry, Wicket and JSF efforts underway to Ajaxify the heavyweight presentation tiers, and arguably maintain the lock-in to one's server technology of choice. On the other hand, Java has been pretty active with web services and the whole SOA space, which plays very nicely with the independent JavaScript client approach. So Ajax and Java look to have a long and happy future together, although Ajax is definitely shifting the balance of power to some extent.

"Ajax and Java look to have a long and happy future together..."

IndicThreads >> Is Ajax more of a concern for the web designer or for the server side developer? How do you think would the division of work in Ajax project teams work out?

Dave Crane >> Every project is different, but speaking from my experience in a large Ajax J2EE project, everyone is affected to some extent. The designer needs to understand how the interface is generated automatically, and its easy to do this badly, and have the designer and JavaScript coder treading all over each other. There are strategies for separating the client-tier logic from the content, which we cover in the book (I think this is the chapter that was previewed on The Server Side, for those wanting a sneak preview). As far as the server-side teams are concerned, the balance of power between client and server is shifting again, as I mentioned in my previous remarks.

"Balance of power between client and server is shifting..."

IndicThreads >> Can Ajax applications that have powerful JavaScript running on the client still achieve a clean separation of presentation and logic or does a lot of logic move to the JavaScript on the client side?

Dave Crane >> Yes, it can, but it has to do it differently. In a classic web app, everything important happens on the server, it's like a mainframe talking to a dumb terminal. To get the benefits from Ajax, it's necessary to move some of the logic to the client, but in order to be secure, it has to be a partial duplication of the logic that the server tiers do. I wouldn't trust a site that validated my credit card only using JavaScript, for example. It'd be way too easy to craft HTTP requests in a malicious client program and dupe the server into thinking it was talking to the bona fide Ajax app.

"To get the benefits from Ajax, it's necessary to move some of the logic from the server to the client..."

Ajax client apps will often contain a lot of JavaScript. I think that, going forward, it'll be necessary to pay a lot of attention to the design of that code, to provide clean layers within the JavaScript. That's something that we talk about quite a lot in the book.