Premise
We are being innundated with examples of Ajax that are quite good but too many people take these examples and turn them into bloated, slow or just plain bad real-life applications.

Good Ajax Gone Bad
While Ajax is a compelling idea, too many people are jumping on the Ajax bandwagon and using it in ways that are overboard. In this post, we are going to look at some of the times when Ajax goes bad. Before we do, I want to say that these are merely examples of inappropriate or unnecessary use but they demonstrate concepts that can be useful. That having been said let's hit the list.
Ajax validation

Back in the day validation was done at the server and we realized that it was slow all the way around. You had to wait for a form POST to occur, the server processed the request and sent back a new form with prompts if the data was invalid. Lather, rinse, repeat.

Then we discovered Javascript and started doing client side validation and life got better because you could give real-time feedback to your user. The problem with client side validation is that you are limited in what you can test. You can look for numbers that look right, strings, possibly even email address but sometimes you need to validate input against a database in real-time. You may need to check for a unique user name when someone is creating a new account or have calculations that are too complex to be represented properly in Javascript. What do you do then? You fallback to old methods and even worse you use a mixture of Javascript validated forms in one area and posted data in another. Inconsistency in the interface is a constant source of confusion and a sign of a poorly written application.

Then there was Ajax which lets a user type a value and then call out to the server to do validation. So in other words you simply moved the post from the submit button to individual controls. You make calls from the form asynchronous and more flexible than the older methods and now you can provide the real-time response with server validated data so what can be wrong with that? The problem is that some people choose to do all validation using Ajax and it is unnecessarily slow. Why do you need to call the server to see if a field is empty? Do you feel you simply have too much time and bandwidth on your hands and want to burn it up?

I was recently at a site that has an Ajax framework and they use it to run the website. It was brilliant and shows much promise but they also validated input on each control using Ajax so the sign up process is SLOW.

The solution
Use Ajax wisely. If a validation is too complex or is in need of real-time information that is essential, you should use Ajax. If you are doing basic validation you ought to stick to conventional Javascript. The difference will be transparent but the performance will increase.

DHTML Abuse
Prior to Ajax, we just called it DHTML. Suddenly Ajax is around and we start referring to DHTML as Ajax and while it falls under the new blanket of Ajax it really has nothing at all to do with Ajax proper. Worse yet is the inclusion of DHTML into Ajax and its acceptance to the point of overuse and inappropriate use. There are many cool Ajaxed sites on the web like start.com and netvibes.com that use DHTML to provide a higher level of customization but they toss in DHTML bits that are overkill. While we like to believe that allowing a user to position blocks of news in random spots is cool it is still unnecessary.

I am sure people will disagree with that statement but the proof of it is the OS that you are using or at least most of you. Windows XP allows the user to position folders, icons, etc. in arbitrary locations but the default behavior is to have Windows position them for you and many of us never think about it.

While total customization is nice, it can result in ackward situations for corporate users due to the complete lack of consistency in the interface. We as developers on the bleeding edge tend to write code for the sake of writing it but the real use for much of this technology is the office and creating odd environments for users will lead to alienation and disuse.

I.E.-centric Development
Another common and huge mistake is developing Ajax applications for Internet Explorer only. Not only is this common, it is also accepted by making amazingly simple and lazy statements like "90% of all users have Internet Explorer." That may or may not be true but there are other facts to consider.

1. Firefox recently celebrated 100,000,000 downloads.
2. Windows is NOT the only Operating System.
3. It is relatively easy to support non-IE browsers for most tasks.

Due to heavy workload, I am sometimes embarrassed when I must admit that our framework (Canons which is mentioned in passing in another article) only works with IE/Win and Firefox for Windows and Linux. Despite what I consider a shortcoming, we at least support the two biggest browsers around and I am convinced that Canons will support Opera, Safari, Konqueror and more. Why? Because we have taken the time to write a code base that anticipates other browsers and can actively support their quirks and it didn't take much time to accomodate the others. While it is impossible to support all browsers, you can certainly take a little time and support the ones that can handle Ajax.

Code heavy development
I think web apps like Kiko are awesome but using 300K of Javascript is out of control. Caching of Javascript is hit or miss and even if it were 100% on all the time, the wait for 300K to download even on broadband and then to have the Javascript parser evaluate the code can seem like an eternity.

You can optimize code, CSS, refactor code, etc. but you can shrink the code.

Related Posts

Simple Ajax Code-Kit (fixed)
What happened to...
Ajax Tabs Reloaded: based on the Havoc Studios article
Forms with moo.fx part 1
Forms with moo.fx part 2

---