I laughed out loud today when I saw what the book giveaway was (I think you'll see why I may need to buy it for a few folks I work).
One of the problems facing Ajax these days is that is the victim of its own hype. Sort of like where XML was 5 years ago... (remember nonsense like "we don't need a database, we have XML!"?), resulting in a rush to use it for things that it really isn't suited for,
I use Ajax extensively in my applications, but only for instances where server access is absolutely necessary.
When it comes to validations, if context-free validation can happen on the client, there's no need for a useless server round-trip just because it uses "sexy" technology. (And, of course, the server code never assumes that client-side validations have taken place when the data is finally submitted).
Ajax has a well-deserved and important place in our web development toolboxes, but like any other tool, it should be used wisely. [ May 04, 2007: Message edited by: Bear Bibeault ]
I definitely echo Bear's comments. I've mentioned in a few posts here that I'm in the final stages of a major, highly complex app at work that we've been developing for a year or so now, and it's very heavily AJAX-based. It had to be because of the requirements, there's just no way to have pulled off what we did without it.
We're the first project at my company to approach web development this way... well, not really... the lasst four major systems I built were along the same lines, but this is the first "official" AJAX project, and definitely the most high profile.
The interesting thing is that now that we're viewed as a huge success, we've kind of proved that the approach is viable. I've sat in a number of meetings recently, or had such meetings described to me, where people are jumping on the AJAX bandwagon, trying to cram it in everywhere they can. This is clearly not the right answer because as Bear said, it's one tool in the toolbox.
I like that the thought process is shifting to more "next-generation" archicture, i.e., RIAs. I've been preaching that approach for probably 5 years or so now at least, but it's starting to get traction now that we've pulled off what we did. But, you can easily go too far and think you have to do everything that way, and that's just not the right frame of mind either.
How do you know when its appropriate? I'm not sure I can give you a concise list of criteria... I tend to listen to what the business analysts and/or customers are saying... if they say things like "fat-client", or "dynamic UI" or "non-blocking operations", things along those lines, then an AJAX type of app is probably appropriate. I can tell this project I'm referring two, plus the last three major systems I developed, all started with comments like "we want a Windows-based application on the web". Now, putting aside whether they should have just been Windows apps to begin with, that pretty clearly leads you down a certain path, certain approaches to things. You start to hear those sorts of requirements more and more, especially now that people see it's possible to do it, to a large degree.
subject: When AJAX vs. scripting (mainly for Frank Zammetti)