Like the rest of us developers out there, you've probably been captivated by the promises that AJAX and Web 2.0 make. Sure, there's a great deal of hype surrounding any new technology wave, but somehow this feels different. For the first time since the Web application made its debut, there's a real sense that a new paradigm shift is upon us.

Now you might be someone who's been pulling off browser magic for quite sometime and to you this latest development may seem obvious, which to a large extent it is. The groundwork for this new era started in the late nineties and developers with an itch to scratch have been heading in this direction ever since. So what has changed now? Well, like paradigm shifts of the past, we've reached the tipping point where the technology and its benefits are attainable by anyone. The concepts and technology behind AJAX are no longer exclusively in the minds of the hackers who brought them to light.

For any new concept to be widely adopted, it has to be shown to offer a benefit to the public-at-large in a way that's undeniable. Netscape did that with the graphical Web browser, and so the Internet was born. You can argue that the Internet existed long before that and has nothing to do with the Web browser, and you'd be right, but you'd also be wrong.

The Internet didn't really matter until Netscape Navigator demonstrated to the world why it mattered. The same holds true for AJAX; it existed under a number of different names, but it didn't really matter until the world saw what Google had achieved. Listening to Jesse James Garrett talk about why he coined the term AJAX, I can't help but wonder if anyone would have noticed his seminal article if Google hadn't just released GMail weeks earlier. Garrett's analysis of the need and where the future lay was stellar, but if the world hadn't just been brought to the tipping point by Google, it's questionable whether it would have been enough to push us over the edge.

Fleeing the Desktop
Looking back at how Web applications began is an interesting exercise because it helps us understand why we all jumped on board in the first place. When Web applications started to appear, they lacked much of the rich user interface capabilities that desktop applications had. Developers, who previously manipulated the user interface with a high degree of accuracy, were asked to craft complex data-centric applications on top of something that was essentially a static content distribution system. The stateless and detached nature of the Web added further complications that caused developers to design applications in an entirely new way that often limited an application's potential.

Of course, there are a number of things that Web applications offer in exchange for these limitations (see Figure 1). First and foremost, simple applications are easier to prototype and build. If you just need to collect some data and then do some basic server processing on it, you can whip something out fairly quickly. Displaying data in a simple table structure is equally easy. And application installation and management is centralized. Push the application out to a Web server and presto, everyone with a decent Web browser can access it. If you later discover a bug in the application you tweak the server code and everyone will instantly be running the patched version. That's highly valuable.

However, while the benefits that Web applications introduce generally out weigh the handicaps they impose, complex Web applications often find the handicaps too restrictive. As a result, numerous "Web-friendly" technologies have been introduced over the years to break the Web application free of its limitations.

Java applet technology is probably the most famous of these failures. It promised desktop-like applications for the Web, which would have been great if it weren't for the 16MB runtime environment that must be installed on every desktop! Granted, it was a third that size in the beginning but bandwidth was also a lot scarcer. The technology was also plagued by compatibility issues between various versions of the runtime environment and to make matters worse different browsers would often have different kinds of problems running them.

Some other technologies that have been deployed along the way include ActiveX Controls, Java Web Start, .NET Smart Client and Dynamic HTML (DHTML). Each one of these approaches has their own set of challenges that ultimately make them difficult to work with in broad-scale deployments and none of them completely match the ease of Web development. It's worth noting that although DHTML still plays a large role in some AJAX frameworks and toolkits, it was essentially a failed technology until AJAX brought new life to it.

What's important to reflect on is that none of these add-on or alternative technologies managed to fill the gaps in Web development in a way that carried forward the benefits of the Web. What's different about AJAX and why it matters in a way unlike the others is that it doesn't just try to play nice with the Web, it's a true evolution of the Web in a way that keeps the tenets of the Web alive.

Picking a Horse to Ride
Emerging technology is disruptive and the more broadly it's applied, the more disruptive it is. In terms of AJAX, it may be the most disruptive technology ever to hit the software world, largely because it has the potential to reshape the most successful technology ever ­ the Web. The thing about a disruptive technology is that it causes the market to be flooded with a number of different options that we can choose from. Conceptually, the idea is straightforward and, as a result, many itchy developers have jumped in and tried to solve the problem in ways they think are unique. Right now, there are over 130 frameworks out there to choose from and even with all those, there are still people proclaiming that AJAX is straightforward enough to handle on your own.

This market explosion that we've seen is standard fare for a disruptive technology and it's helpful in that it ultimately leads to a better set of solutions in the future. The problem is that if you're trying to determine which horse to ride right now, it can be quite difficult to work through the options to determine what solution best fits your needs. What you need is a buyer's guide, like the kind you can get to help you pick the best car for your needs. Something that will break down the issues for you and outline the benefits of the various choices you have available. Of course, AJAX hasn't been around long enough for there to be a comprehensive tool that's that straightforward. But what we do have is a study that Gartner, the research firm, released in 2005 that attempts to categorize different AJAX approaches into roughly four categories (see Figure 2).

As part of the study a number of projections were made about AJAX adoption over the next five years. It figured that early AJAX adoption would primarily consist of using snippets and widgets to enhance existing Web applications but shortly thereafter applications would start to transition to Rich Internet Application (RIA) frameworks that provide a consolidated approach to handling browser and server-side logic. It predicted that 60% of new applications would be based on an RIA framework by 2010. Specialized frameworks were outlined as a custom approach that should be left to very large consumer-centric Web applications like Google Maps and Yahoo Mail since the overhead of maintaining those frameworks is quite high and the specializations are unlikely to benefit most applications.