An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.
By the way, no plug-ins are required to achieve this level of interactivity. A lot of experienced Web programmers will argue that AJAX has been around for a while, just under a different name (XMLHttpRequest). But the XML culture really needed to hit its stride before something like AJAX that relies on it could take off. That time has come and Google has turned a lot of heads with its implementations of AJAX. Garrett explains:
Take a look at Google Suggest. Watch the way the suggested terms update as you type, almost instantly. Now look at Google Maps. Zoom in. Use your cursor to grab the map and scroll around a bit. Again, everything happens almost instantly, with no waiting for pages to reload.
Google isn't the only company using the technique. Another incredibly forward thinking company that's looking to relieve organizations of their addiction to Microsoft's difficult-to-unseat Outlook/Exchange Server/Windows Server trifecta -- Scalix -- has built a highly interactive, fully browser-based Outlook-like e-mail client using the same techniques. After getting a demonstration of it, one can't help but say "All this, in a browser, with no plug-ins? Remarkable!"
The absence of plug-ins to achieve these sorts of levels of interactivity may be more special than most people know. Because a plug-in that's written for Internet Explorer doesn't just plug in to Firefox, there are plug-ins that exist for one browser, but not the others. Developers of non-Microsoft browsers as well as those of the plug-ins have had to jump through hoops to ease the pain on end users who want the freedom to pick a browser (or a non-Windows operating system for that matter), rather than be forced into using one because of differing plug-in architectures and APIs.
Incompatible plug-in architectures aren't the only culprits to have foiled our hopes for an interactive Web experience that seamlessly works across all browsers. Dynamic HTML (DHTML) -- another widely deployed technology for making Web pages a bit more interactive with things like exploding menus -- also comes in multiple flavors that don't work across all browsers. Books like this one that are dedicated to understanding how to take advantage of proprietary DHTML (and Cascading Style Sheets, another compatibility sore spot) are also teaching Web programmers how to lock out some users (or force them to use a technology they don't want to).
AJAX represents a huge opportunity to different communities within the Web industry. First and foremost, if you're running one of those sites that has browser compatibility issues and that could also benefit from a more interactive user experience, then you should be giving AJAX a long hard look. I was reminded of this today when, in the process of testing the Cingular flavor of RIM's Blackberry 7100 (the 7100g), I visited my Cingular Blackberry Web Mail account with Firefox only to receive the following error:
I cropped it for fit and what you can't see is that older versions of Netscape are listed as compatible versions too. But the point is clear. I need to switch to a technology that I don't want to use (or in the case of the older versions of Netscape, don't have) in order to make use of the site. Assuming that RIM's partners (Cingular, T-Mobile, etc.) would want to make Web mail available to all of their customers regardless of their choice of browser, and given that e-mail is precisely the sort of Web-based application that can use a bit more in the way of interactivity (as demonstrated by Google's GMail), RIM is the perfect example of a company that needs to understand AJAX and get with the program. My guess is that RIM is not alone. There are thousands of others.
In addition to getting mail from these vets, I also get mail from newbies, including high school students whose parents are telling them to make a career out of tech. They all ask the same question: What programming skills will make me most marketable tomorrow? For a while, I answered this question with Java (all flavors... mobile, desktop, and server). But proficiency in Java alone wasn't enough. Since Java often interacts with other entities such as databases, Web pages, and Web servers, some solid background in those areas was required as well. For a long time, you couldn't go wrong with Java and I still believe that it's a safe bet.
Recently, when I've recommend the aforementioned Java soup, I also toss XML and Web services into the soup. I advise people to build and experiment with applications that involve interactions between Java and .Net because, as services oriented architectures really begin to take off and companies start to realize the benefits of integrating their systems with other systems (including ones external to their own), the people with proven skills in getting those two environments working together will rise to the top. Knowing the LAMP stack can't hurt either. Because of how versatile the language is, a good PERL programmer can still make a killing these days. And for you C/C++ jockeys out there, have you noticed how some of the biggest and most interesting companies to work for are hiring the creme-de-la-creme out of the open source world? One way to get noticed is to get involved as a very visible contributor to the most visible projects.
Today, after seeing what companies like Google and Scalix have done, I'm adding AJAX to the list. According to a company spokesperson, "RIM has plans to add support for Firefox and Safari and plans to roll it out in the fall. RIM is looking into AJAX but cannot confirm any plans at this time." If companies like RIM aren't waking up to the beauty of AJAX, they darn well should be. When they do, there will be a vacuum of developers who can help those companies go from 0 to 60 in 4.2 seconds (which is what they'll need to do in this wacky Web world). Ones that really know AJAX best practices (for example, with a lot of older browsers and non-AJAX capable kiosks still out there, what's the fallback plan?). If that doesn't spell opportunity, I don't know what does.