Forum Moderators: open
While I understand that there are perfectly valid uses for AJAX, it seems that the majority of AJAX implementations out there are total overkill. Developers opt to use AJAX instead of much better and more reliable solutions.
As defined by the pioneers in AJAX implementations, AJAX is meant to be used whenever constant data communication is needed between the user and the server. It is overkill for a one-time submission. It is only when you need to handle multiple transactions, and this in a sequential way (i.e. a new request is sent prior to fully handling the first), that AJAX shines. For regular form submissions or one-time trips to the server (or even when multiple data transactions with the server are needed, just with a large gap inbetween) it is mostly overkill. On the latter, you will find yourself spending many times more time and effort on the solution by using AJAX.
Further, and this is something that everyone seems to totally ignore, users do not know what AJAX is or how it works. Your visitors are used to the way forms submit and the typical feedback from such transactions. Do not break established user behavior! Unless your AJAX implementation is truly an application, you don't need AJAX and should not use it.
Let's make a list of good and bad uses of AJAX. If there are disagreements, let's discuss them. This will help sort out the general confusion about applicable implementations and uses for AJAX.
I will start.
Good use: Google Earth
Here AJAX is used to allow you to zoom and move around the map seamlessly. You get immediate response from the server and can send new requests while data is yet loading. This is a good use as it falls within the definition of "constant communication with the server".
Bad use: Form submittal
Here AJAX only purpose is to take data from a form and submit it to the server. Nothing new here. Using AJAX introduces several potential problems, but solves none. Submitting the form using AJAX really has no benefit over traditional methods. It also break the expected behavior for your users. Usability and accessibility decreases. Risks of multiple submissions increases. And, the funny thing is ... you will still need to provide a non-JavaScript solution for those using browsers or other tools which can not handle JavaScript, or who have it turned off. So, there you are with two tools -- one AJAX, one conventional -- when the conventional alone does the job. Overkill :)
Recent "my Ajax deosn't work" threads appear to show that the common understanding of "Ajax" is "anything involving XMHTTPRequest". I think one should be expecting to receive information from the server too, and of course strictly there should be some XML involved (although JSON may be neater).
It's a pity that we have this name. I believe that, ironically, the self respecting amongst us would be able to accept a general term for procedures of this type if the moniker was less stupidly flashy. Maybe TWERP or DULL.
Still, as Rambo said, at least people are showing an interest and respect for Javascript again.
but it wasn't until the combination of technologies got a name that it spiked people's interest.
IMHO the big push for XmlHttpRequest came when Google started using it widely (Google Suggest was one of their first implementations, if I recall correctly).
Anyway, I don't see any harm in using AJAX to enhance forms. To check whether an entered URL really exists, or find out whether a user name is still available. Small things for which submitting the whole form would be overkill. Such uses indeed require more effort by the developer, but hey, aren't we here to improve the user experience?!
It also enables developers to have the validation rules on the server only, while still being able to perform client side validation. Keeping the rules in one place might actually reduce the amount of work that needs to be done.
AJAX is a silly name. In my town Ajax is the local football club. Ajax also is the name of a liquid used to clean toilets...
But.. I have found one good application for the technology. I've incorporated AJAX into my own local order entry system to provide me with customer names and product part numbers. By typing the first few letters of a name or part number I can access a drop down list. This generally moves my order entry system a little closer in function to other applications that we regularly use, which is good from an end user viewpoint.
The only other place I've used it is on a form, where the user might get a dropdown list of city names to select from. As you pointed out, the average web surfer isn't used to this sort of thing, and it could cause more confusion than convenience.
I don't see any harm in using AJAX to enhance forms. To check whether an entered URL really exists, or find out whether a user name is still available. Small things for which submitting the whole form would be overkill.
I could not agree with you more! Yes, using AJAX to enhance a form in ways you just described is an example of good use. But to use AJAX for the sole purpose of submitting the form is not.
grandpa:
I've incorporated AJAX into my own local order entry system to provide me with customer names and product part numbers. By typing the first few letters of a name or part number I can access a drop down list. This generally moves my order entry system a little closer in function to other applications that we regularly use, which is good from an end user viewpoint.The only other place I've used it is on a form, where the user might get a dropdown list of city names to select from. As you pointed out, the average web surfer isn't used to this sort of thing, and it could cause more confusion than convenience.
Also examples of good use. Imagine a quickorder type functionality, where product names and/or part numbers are typed in, a lookup is performed, the closest match is included. Well, that simply would not be feasible without the use of AJAX. Imagine a quickorder form with JS arrays holding thousands of part numbers product names each. AJAX is vastly superior in this case.