AJAX pain points
May 5, 2006 § 3 Comments
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 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.
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.
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.