Google has released an AJAX development toolkit for the Java platform. You can read more about it here. Now we have toolkits from all three major companies, Yahoo, Google and Microsoft. Let the war begin. In the mean time let me go ahead and dissect the source code to see if I find anything interesting. After all the underlying technology is still JavaScript that does the trick.
If you are new to AJAX and want to know all about it, please read this wiki. I couldn't have put it in better words myself.
Now that you have at least some understanding of AJAX, let's look at what we need to be aware of. First of all for those who did not understand the above wiki, here's what it all boils down to. When you write a desktop application, you use at least one additional thread (other than the main thread). The reason you do that is, you don't want the screen to hang due to some complex computation that would eat up all the resources. It is simply bad user experience when the client cannot do anything (cannot even move the window around) because of resource intensive calculations. So what do you do? you create a new thread and do all calculations on that thread without blocking the main thread. AJAX can be thought of as threading (just an analogy, I don't mean actual threading) for the web. You create an iframe and all computations / saving of information / loading of information, you do through that iframe. To the user the screen is not refreshing / hanging up until the next screen loads. That's the basic of AJAX, better user experience. This is turning out to be a big post! so let's get to pain points. We shall leave the coding for another post.
Paint point 1: Debugging - it just is a hell to debug an AJAX application. You obviously cannot put detailed alert messages on the production server, so you have to resort to other techniques like logging of errors in the background (i.e. sending detailed messages back to the server in a background thread and storing that information in a database). Obviously this method could turn out to be very costly if you have too many error messages. Things get even more complicated even in the development environment if you have hidden frames and server side errors happen within those hidden frames.
Pain point 2: Knowing when to stop - this is just plain old experience. Obviously I could have created the feedback / post entry system of this site in AJAX, but what's the point. If my screen is fast enough or if I am not going to save a lot on the server as well as the client, why do it and go through all the pain.
Pain point 3: Training - remember that the world is used to the traditional three tier architecture where you code a bunch of server side files that spit out html code. Even if you master AJAX and write up awesome code, it is going to be very difficult for the fresh kid out of college to understand / adapt to this new world of client side (javascript) hacks.
Pain point 4: Learning curve - (Thanks Lilly) you may be a good web developer but it does not mean you are a good JavaScript developer. With all the drag and drop components that are in the market, you don't have to code a single line of JavaScript (exaggeration) and still have a decent web solution. The first step is to learn JavaScript + DHTML, this should get you ready to learn AJAX.
Pain point 5: Session timeouts - imagine your screen doing most of the stuff using AJAX and the user being idle for X hours causing the server session to time out. When the user comes back and clicks anything, the AJAX code would fail because the server time out. You need to handle all such situations.
Pain point 6: Framework - there are a lot of frameworks that are coming up in the market, but none have reached maturity yet. Which means that if you need something fancy you have to code it i.e. build your own little framework. Remember to build a framework i.e. all your AJAX code in one JavaScript. All other web pages need to talk to this framework to get any AJAX done. If you don't follow this you will have JavaScript code all over the place and it would become a nightmare to maintain it.
The biggest pain point of them all: Not every one can build an AJAX app. I don't mean to insult you in any way, but Yahoo is the best example. They have redesigned their mail application into an AJAX app. The UI looks and feels just like desktop Outlook, but the app is very resource intensive. IE takes a whopping 150 MB and the browser slowly starts to crawl after about 30 minutes of usage. I am sure the Yahoo developers will figure it out and improve it over time, after all it is still in beta, but imagine you getting into a similar situation. Debugging those leaks is going to be darn hard. Which brings another point. Browsers in particular IE have a lot of memory leaks, before you know, as the user navigates around, the browser keeps bleeding memory and eventually comes to a grinding halt.
Obviously security is a key issue and you may be susceptible to a JavaScript injection attack, just like the sql injection attack. You always need to keep security in mind as you code your stuff.
Moral of the story: The aim of this post is not to scare you away. The intention is only to educate you so that you make the right decisions before jumping into the the AJAX bandwagon. My advice, go slow (slower than when you work with any new technology). Do small things at a time and slowly evolve your framework. Eventually you will be a winner by taking one step at a time.