Home 
Site Map 
FAQ 
Seven Things Every Software Project Needs to Know About Ajax
It's been approximately 18 months since Jesse James Garrett fatefully coined the term that would go on to nearly reinvent the face of Web development. A lot has happened in the last year and a half, including the Web 2.0 phenomenon getting into high gear, the creation or resurrection of many a company building or using rich Internet technologies, and the proliferation of really great dynamic, online software. It's clear that Ajax as a name, a concept, and a popular browser development technique is here to stay, and our Web applications will never be the same again.
While most of us know that the Ajax approach was fairly well known before the term ever came about, the timing was apparently just right for the idea of Ajax to capture our imagination and apply such a pithy name to an important new development trend. And just as powerful browsers, high-speed connections, online software trends, and development tools were reaching the sweet spot that needed to form for Ajax to be popular, so also came the embrace of a world extremely interested in turning their boring, static Web pages into full-blown, sophisticated applications. Since then, I've heard of or seen literally hundreds of Ajax products, tools, utilities, debated the disruptive potential of Ajax, speculated about how Ajax will be the face of our SOAs , and even watched as RIA technologies in general have risen up that truly complement the few things that Ajax does not do well, such as multimedia.
- The Browser Was Never Meant For Ajax. About a week into your first Ajax serious application you'll discover that Ajax pushes the browser nearly beyond its limits and there are definite lower engineering tolerances to get used to. The fact is, without powerful 3rd party development tools, designing clean Javascript software of any size requires some genuine discipline and effort. So too does Ajax debugging applications in multiple browsers (a real headache), and doing any serious background processing or threading can require heroic measures, particularly if you're mixing in other components that use the rather limited number of simultaneous timers available. The good news: Simple Ajax -- sprinkling in a little DHTML -- is much less daunting than Ajax In The Large. But be warned and be prepared to scale up your level of development and testing effort significantly with each doubling or trebling of your application size.
- You Won't Need As Many Web Services As You Think. I used to think that going the Ajax route required the development of a bunch of new Web services in order to feed the application data and provide a backing store. In reality, I'm finding a great many projects are quite happy to scrape HTML and/or use plain old HTTP POSTs to existing service endpoints that have no formal Web service structure. This is further turning the tide towards Ajax by making it very, very easy to "dip your toe" into Ajax development and reuse almost any preexisting HTTP service on the back end instead of SOAP or REST/WOA. While this can encourage poor architectural choices, it does make very incremental conversion to Ajax almost effortless and turns out to be a natural thing to do, though it can certainly lead to headaches later.
- Ajax Is More Involved Than Traditional Web Design and Development. The loss of HTML user interface conventions, the almost limitless potential for hidden or latent functionality, the programmatic creation of page elements instead of declarative, and other intrinsic aspects of the Ajax approach throw out much of what we know about Web design and development. Web designers must much more deeply understand the capabilities of the DOM, Javascript, CSS, and how the browser renders graphics, layouts, and elements. Developers find testing both difficult and tedious. Though tooling is continuing to improve across the board, it will take years for the industry to develop best practices, lore, patterns, and shared knowledge to make Web application development straightforward. Huge kudos to folks like Yahoo!'s Bill Scott for trying to fix many of these problems -- particularly the loss of GUI standards -- by actually moving the state of the art considerably forward with things like the Yahoo! UI Design Patterns library. The bottom line: Ajax development, at least for now, usually takes quite a bit longer than traditional Web development and requires a higher level of skill.
- Ajax Tooling and Components Are Still Emerging and There Is No Clear Leader Today. Though Dojo is getting one heck of a running start, the race is very far from over. For instance, the Dojo framework itself is still just at version 0.3. And close at its heels are an amazing range of tools, frameworks, and component libraries. Though OpenAjax will make this mosaic of products play nicer, most developers will get deep experience with two or three of them and stick with them. For now, I would say deeply committing to a particular product is usually not the best idea. Innovation, competition, and market leadership is likely going to bounce around for a while. In the meantime, be sure to check out script.aculo.us, Prototype, Google Web Toolkit, Yahoo! UI Library, JackBe, Zapatec, Bindows, Nexaweb, General Interface, Backbase, ActiveWidgets, and last but not least Microsoft Atlas. There are many others and I encourage you to look at Max Kiesler's roundup of 50 Ajax frameworks, with many others in the comments (and growing). Finally, Microsoft's Harry Pierson has diligently taken me to task for my Ajax spectrum comments, noting that Microsoft actually has more serious experience fostering an interoperable component community than just about anyone else.
- Good Ajax Programmers are Hard to Find. Zimbra's Scott Dietzen has lamented recently about the real difficulty in finding good Ajax talent. See point #3, but building sophisticated Ajax applications requires more computer science skills much more than it does Web design skills. And I find that experienced programmers tend not to enjoy Javascript programming and debugging. This too shall pass, but not for a few years, and not for a good while in the Bay Area.
- One Must Actively Address Ajax's Constraints of the Browser Model. Though the final result can be very rewarding, Ajax is not a perfect Web development approach and it has a few genuine weaknesses. One is that it tends to break the model of the Web including preventing users from bookmarking content, breaking the use of the Back button, and more. Fortunately, smart folks like Brad Neuberg have addressed much of this, as long as you're willing to put out the effort and understand why it's important to recover this functionality. Ajax also lacks much of what still makes desktop software a strong contender; the ability to run disconnected from the network and access to local disk storage, though Flash local storage and the upcoming Apollo platform can help address this.
- Ajax Is Only One Element of a Successful RIA Strategy. As I've written before, the addition of RIA platforms such as Flex, OpenLaszlo, and WPF/E to a RIA strategy is virtually required to properly exploit the range of capabilities you'll want robust online applications to have. This is particularly true around rich media support such as audio and video -- which Ajax is virtually incapable of -- but even such mundane things as good printing support. These are all things that the more sophisticated Flash-based RIA platforms really shine at and are easier to program in to boot. Ajax will increasingly get a serious run for its money from these platforms, particularly as they provide back-end server support for things like server-side push, formal Web services, enterprise environments, and more.
Latest News
