You can think of Ajax web development as being the quantum mechanics of the web development world. The paradigms are different, the players are different, and even the rules are different. Traditionally a web application goes through a "roundtrip" to process and update data to the user. That is, the web browser sends the server a request and then an entirely new page loads to complete a "roundtrip." This is a synchronous processing method where the client and server take turns I a synchronous manner. Ajax, by definition, thanks to the 'A', is asynchronous, so you no longer have to wait for an entirely new page. The user sends a request, goes about his or her other business and then receives an update on what he or she requested. No more waiting for just one thing to be completed at a time. To avoid the needless "roundtrips", the user just sends a request on the fly to the server for some specific data and receive only the data he or she requested without the waste of getting an entirely new page.
While I have been developing Ajax applications since before this millennium, it has only recently become popular with the general web population. The most obvious example of an Ajax application is Google's Gmail. People often ask me why Gmail is so different than other online message/e-mail services. In my answer there are of course allusions to the life-saving concepts of labels instead of folders and conversations instead of e-mails, but also there is my answer regarding its use of asynchronous technology.
In Hotmail and Yahoo! Mail, when you want to, for example, mark a message or series of messages as read you have to press a button and wait for the server to complete a "roundtrip." That is, you have to wait for the server to send you an entirely new updated page. In Gmail, with its use of Ajax technology, there is no roundtrip. So, while the other e-mail services refresh the entire screen when a user presses the button, thus sending a tremendous amount of redundant information to the user, Gmail works with only the appropriate components. In this case, it would send a message to the server telling it that you want to mark a series of messages as read and the server will send your browser back a confirmation all without a roundtrip and alter the screen accordingly. This process saves bandwidth and therefore, time.
That is just one example of a popular Ajax application. Another great example is Google Maps. I've never personally talked to a person who wasn't absolutely amazed at this website (ok, it's an application, but most people call it a website.) You can navigate all around the United States on just one little screen. The application almost never does a "roundtrip", thus gives the user a lightening fast user experience.
When some people think of XML, they think of a data format and when some people think of HTML they think of a presentation format. Well, while it may sound like I'm building up to a correction, these theories are actually absolutely correct. XML is for data and HTML is for presentation. But with Ajax and in the world of modern web-standards, there is a technology which combines the two. Thus enters XHTML.
XHTML combines XML and HTML to create something that is not data, and definitely not presentation, but creates rather a page structure. XML by itself cannot render data and therefore cannot solely be used to put controls (i.e. text boxes, buttons, etc…) on the screen and HTML is actually unparsable by today's standards, so it can't be used in strict production environments. XHTML combines the visual aspect of HTML with the parsability of XML to create the new canvas used in modern websites and web applications. With the various types of XHTML, a developer can choose that which best suits his or her own needs at the moment. It's actually a little known fact that there are two primary types of XHTML: one that is text based, which is really just HTML written in XML, and one that is application based, which is true XHTML.
In modern Ajax development when you are creating applications you should seek to use the applications version of most technologies. Why? The text version is not parsed like the application version. Deployment of applications requires a way of mechanical testing. Usually this is done with a compiler, which will check your code for errors, but what about uncompilable things like HTML? While with HTML and text based XHTML, you have to do this manually, by using the application based version XHTML you can parse and validate your code just like any compiler would. That is, no Java or C++ application would ever run with poor syntax because the compiler will prevent it from ever being deployed. So is the same with application based XHTML. If your XHTML code is improper, that is, has poor syntax or other problems, then it will not run. You will be able to catch your errors much earlier and you are forced to take XHTML errors as seriously as you would Java or C++ compiler errors. This allows you to ensure that your web applications are proper, thus bringing you another step closer to having web application development really feel more like windows development…and the quality assurance team will love you for it.
While that exhausts the acronym, there are more parts to Ajax. The one that seems to be the most important to many people, including myself, is one that didn't receive a letter in the acronym and that's web-standards. Some people think that web-standards bring you the ability to write standardized code that will work anywhere. Well, anyone who has been a web developer for more than a month knows that this isn't currently the case. While this is of course the ultimate goal, and until then all web browsers clearly miss the mark, the truth about web-standards today is that they are standards because of the high level of standards they bring to your development.
By writing code that is web-standards compliant; you are ensuring your application to be compatible with the future and are saying that you want your application to be usable for another two, five, or even ten-years. Without the use of web standards, who knows how long the proprietary code you used will last? That's a tremendous risk that no company can ever take. Web standards provide a way to ensure that your applications will work ideally for the long haul. Not only that, they are also the best way to ensure they are the most powerful for the long haul. Proprietary features are the equivalent of get-rich-quick schemes in that while they provide you with the initially buzz that originally sold you on the product with the buzz soon dying off leaving you with a distaste for the temporary world you involved yourself in.