In Part 1 of this two-article series, I discussed the potential benefits of an Ajax/REST architectural style for Web applications that require dynamic and personalized user interfaces but must also scale. Given those requirements, I explain why the Ajax/REST architectural style is superior to traditional server-side Web application architectural style in terms of its run-time characteristics. But your users can enjoy these positive run-time characteristics only after you've successfully envisioned, planned, developed, tested, and deployed your Ajax application. This article addresses development-time characteristics of Ajax/REST applications. It aims to help readers who are interested in using Ajax in real applications to answer two important questions:
- Should you use Ajax technology in your IT applications?
- If so, how can you improve your chances of successfully developing and deploying Ajax technology?
The newness of the Ajax/REST architectural style presents challenges to organizations that have traditionally used the server-side Web application style. Though Ajax has several compelling architectural advantages over the traditional model, an immediate and total transition to a pure Ajax/REST architecture isn't realistic for all organizations. Those that lack Ajax development skills can begin their Ajax exploration by incrementally adding Ajax functionality to existing server-side Web architectures. As these organizations begin to gain experience with Ajax/REST, they can confidently attempt more interesting and ambitious projects.
Should you use Ajax?
Ajax is an architectural style composed of a set of technologies. Technologies are not good or bad in and of themselves; they are neutral. A technology is more or less useful only insofar as an organization can apply it to solve a particular problem or to fulfill a particular need. So to answer the "Should I use Ajax?" question, you must evaluate what your organization is trying to achieve, how Ajax can help (or not help) you achieve it, and whether your organization has the right people to succeed.
Consider the spectrum of adoption options
You may be wondering what it means to "adopt Ajax." To take advantage of Ajax, an organization need not rewrite an application using a pure Ajax/REST architecture. I recommend that you start small and get your feet wet to gain experience and confidence rather than diving directly into a pure Ajax/REST architecture.
Adopting Ajax can mean doing something lightweight and subtle -- perhaps reimplementing a minor feature of your Web application to be cooler and more responsive. This lightweight style is exemplified by the Netflix movie feedback feature. Customers can quickly score movies by clicking on between one and five stars. Each click immediately updates their Netflix preferences and adjusts recommendations accordingly.
At the high end of the adoption spectrum are applications such as Google's Gmail and Maps, which have redefined the state-of-the-art in Web application development. These applications are notable for their many intuitive interactive features, visual pizzazz, and ability to adjust their user interfaces constantly based on user actions and user data.
It's certainly fun to imagine the positive response you'd get if you released something as sophisticated as Google Maps for your industry. But be realistic. Google has perhaps the best Web development organization in the world, so it's dangerous to use it as a benchmark of what's possible with Ajax. And don't forget that Google (wisely) doesn't announce new applications until they're ready for prime time, so we only see the successes. I would speculate that even the brainiacs at Google have occasionally failed with Ajax and we simply never learn about those failures.
Pure Ajax/REST is a young architectural style that's still difficult to implement compared to more-established Web application styles such as JavaServer™ Pages technology (JSP) and PHP. Unless providing a next-generation Web user experience is a primary requirement and you have world-class Web development team, your organization will fare better by initially adopting "Ajax in the small" like Netflix rather than "Ajax in the large" like Google.
Assess how Ajax can help you achieve your goals
Ask yourself what characteristics of the Ajax programming style make it attractive to your applications' needs. Does your company seek productivity gains that a more responsive UI could provide? Do you want to deploy an application that's both highly dynamic and personalized, yet still scales? Is "coolness" a differentiating feature for customers in the market segment that you target? Any of these are valid reasons, and there are others. The point is that you must be able to articulate a compelling reason to adopt Ajax. Here are three things Ajax does well:
- More-responsive UIs. In a traditional server-side Web application, any interaction with the server requires a page refresh, meaning a two- to five-second delay and a jarring full redraw of the page. Ajax lets the user interact with the server via a "fire and forget" interaction style: the user performs an action and the system can process it in the background while the user continues with other work. And the UI only needs to update regions that have new information to display, rather than always redrawing the entire page. If done well, an Ajax-style UI can let the user achieve and maintain flow, improving both user satisfaction and productivity.
- Sexiness. For externally facing applications and products, it's no longer enough just to have a good product that does what it needs to do. Too many options are out there for your customers. You need a product that will gain attention and captivate users. As the saying goes, "sexy is a feature." This doesn't mean you include every bell and whistle your developers can imagine -- look at how the iPod with its minimalist design has blown away other portable music players with 10 times the number of controls. The key is to provide an elegant design filled with subtle features that help users do what they need to do in a pleasant, enjoyable way.
Gmail is a good example. On the surface, Gmail's just another Web-based e-mail application, and those have existed for 10 years. But Gmail gets the little things right using Ajax. Ever lost a long, unsent e-mail message because you accidentally closed your browser? The Gmail developers considered this and unobtrusively save a copy of your unsent message to the draft folder every minute or so. Ever found it annoying to look up an e-mail address that you use all of the time? The Gmail developers considered this and provide an unobtrusive address-completion mechanism based on past e-mail messages you've sent.
Sexiness is often important for external and commercial applications, but it's much less important for internal business applications. It's all about context.
- Personalization without sacrificing scalability. As traditional server-side Web applications have grown more dynamic and personalized over the past 15 years, developers and middleware have increasingly tended to store a lot of session state on the server side. This approach enables personalization but hampers scalability. As you learned in Part 1, Ajax applications tend to store session state on the client side and interact with the server via stateless services, allowing highly dynamic and personalized Web applications without sacrificing scalability.
Make the call
Would any of these three benefits help your organization succeed? If not, does Ajax provide some other unique advantage that could contribute to your organization's success? If you don't have a compelling, concrete reason for exploring Ajax, I suggest you drop it until you find one. If you do have a compelling reason, read on.
Succeeding with Ajax
So you've decided that Ajax could provide some unique value to your organization that justifies the increased risk that it brings along as an emerging technology. This section discusses how to incorporate the Ajax technologies and techniques into your application and software development process successfully. I'll deal with some special considerations for developing "Ajax in the large" in the next section.
Start small, gain experience, build confidence
Nothing sinks a useful emerging technology faster than a project that attempts to use it and fails spectacularly. This is usually the result of trying too much too soon with inadequate skills. But it's difficult now to find developers with nontrivial Ajax development experience; the technology is simply too new.
To deal with this problem, development organizations should look to gain experience with Ajax by implementing it on real projects, but on noncritical features. Focus on quickly getting something small deployed into the real world. Learn from your mistakes and adjust. If you try to go too big too soon, you introduce a great deal of risk to your project. And the bigger you go, the longer it will take to go through a full design/develop/test/ deploy cycle, which is the key for gaining real, practical experience.
This advice applies more to organizations attempting "Ajax in the small," but with "Ajax in the large," you can still start small by developing in an iterative manner, as I discuss in Special considerations for "Ajax in the large."
Find the right people for the UI and for the services
It's tempting to think that your team of Web developers who have successfully delivered PHP, Java, or .NET server-side Web applications over the past 10 years will seamlessly transition into expert Ajax developers, but this is unlikely. Although you're still playing in the Web development space, both the Ajax architectural style and supporting technologies require developers to unlearn old assumptions and to learn new idioms and patterns. Making the transition is possible, but it takes time.
In traditional server-side Web development you process link clicks and form submissions, and respond with a full HTML page. Often a workflow spans a number of pages, so your server-side application logic must maintain a conversation with the browser. The server must remember the entire application state from click to click so it can provide an apparently seamless workflow as the user interacts with the Web application. In an Ajax world you move away from this "green screen" model to a true client-server model, where the client is stateful and dynamic, and where the server is responsible only for providing atomic, stateless services. This new programming style requires different types of skills on both the client and server sides.
This is yet another reason why it's important to start small. Your Web developers might not have the level of skill and experience to create a Gmail-caliber Ajax application now, but they should be able to deliver something small and real on top of an existing server-side Web application. With time and experience they'll gradually be able to implement more-sophisticated scenarios using Ajax.
On the server side, Ajax presents a shift because you can get out of the unattractive business of managing session and workflow state on the server. The Ajax style of "stateful client / stateless server" is much simpler to understand and manage once you gain experience with it, but this change in architectural style requires new skills. Your service developers should have a strong understanding of the HTTP protocol, knowledge of the REST architectural style, and experience developing distributed services such as remote method invocation (RMI) and remote procedure calls (RPC). Though the REST architectural style has some basic differences from RPC, some of the nonfunctional principles involved (security at the borders, network latency, and nonreliability) carry over.
Use a framework
The DOM, CSS, and
XMLHttpRequest (XHR) "standards" vary significantly from browser. Developers who don't choose a preexisting framework to sort out these differences will spend many unplanned cycles writing their own plumbing code to normalize the cross-browser inconsistencies. And it will be a long time before your plumbing code reaches the level of quality that frameworks available today have already achieved. One promising framework is the open source Dojo toolkit (see Resources).
Learn and use tools
- Inspecting structure: DOM inspectors. Because much of the visual structure of an Ajax Web page is created dynamically as the user interacts with the page, it's not enough simply to view source in order to explore the page's live structure. The source likely won't even loosely resemble the UI you're viewing. You need to inspect the DOM structure as you interact with the page. A nice complementary feature to a DOM inspector is a "live source" viewer that reverse-engineers what HTML source code would look like for the current state of the DOM, giving developers accustomed to viewing HTML source an intuitive way to think about page contents.
- Inspecting client-server interaction: XHR monitors. A final important tool for your Ajax toolbox is an
Test in a realistic environment
It's been well documented that without extra effort on the developer's part, Ajax breaks some of our basic expectations of a Web site: for example, the Back button, bookmarking, or the browser's "loading" control might not work. My "start small" advice will help you here as well. As long as you use Ajax only to implement incremental new features that update a page's state but don't affect navigation or workflow, the Back button and bookmarking are nonissues. But the loading time can be an issue, especially if you test only on your local development environment, where network latency isn't much of a factor.
Consider this: In a traditional Web application, when users click on a link or submit a form, even if the subsequent page load takes 10 seconds, they see immediate feedback from the browser's "loading" control. In an Ajax application, clicking on a control that triggers an XHR request doesn't activate the "loading" control. The danger of testing only on a local development environment is that the HTTP request, response, and subsequent UI update appear to happen instantaneously, making the lack of browser "loading" feedback seem to be a nonissue. But in a production environment where the user might be hundreds or thousands of miles away from the server, this lack of feedback can be confusing and frustrating. The user wonders: "Did I click on that control? Let me click it again. Still nothing!"
The key point is to test in a realistic environment, where these usability problems will be easily noticeable. The earlier you catch them, the earlier you can respond appropriately.
Another aspect of testing in a realistic environment is to ensure that you execute each functional test on each browser type and version that you support. For example, if you claim to support Firefox 1.5 and 2.0 and Internet Explorer 6 and 7, then you need to test constantly on all of those browsers. This may seem obvious, but it's easy for developers to fall into the bad habit of developing and testing only on their favorite browser and later needing to rework code as problems are found on other browsers.
Special considerations for "Ajax in the large"
Although I've recommended that you don't try to create an Ajax application as ambitious as Gmail or Google Maps, business factors or engineering bravado might compel you to try. My first reaction is: don't do it -- start small and gain experience. But if you're intent on building a big pure-Ajax application right now, read on.
It's all about your people
Your development team is even more important now, because you're not simply extending a proven architecture with new technology, but you are embarking on a new architecture. Your team will need to make major design decisions with little Ajax experience -- design decisions that could go horribly wrong.
Don't underestimate the importance of good CSS on your application's quality. The lack of someone with deep CSS understanding can lead to unnecessarily awkward and unmaintainable code, which will make your first and second rewrites much more difficult.
Rewrites, did you say?
Plan on rewriting it ... at least twice
Whenever you're working on greenfield development, the chances of getting the major design decisions correct the first time are low. You can either lumber on with a brittle and flawed design, or you can do the agile thing and constantly refactor your design as you gain knowledge and experience of what works and what doesn't.
Ajax presents unique challenges because both the user experience and the underlying architectural patterns are deceptively different from their server-side counterparts. You'll probably find subtle but persistent flaws with your UI: the Back button doesn't work as users expect, there's not much feedback when the user invokes a remote action, and so on. Unfortunately, it's hard to design solutions for these problems until you've experienced them and understand how your design must change to fix them.
Beware of entering the framework business
Framework code introduces more levels of abstraction and indirection that make code paths harder to understand. A good rule of thumb is to work at the concrete application level as much as possible and only think about moving some code into a framework or reusable library when at least three different parts of your application could use the services provided by the code.
Iterate, iterate, iterate
A major antipattern of greenfield development is that you spend too much time between initial design and having a tangible product that real people can use and provide feedback on. So, on your big ambitious new Ajax application you should try to get something basic working and demo-able within a few weeks to start getting feedback. The UI will be primitive and the code might be ugly, but you'd have the same result if you developed for six months before letting people play with your new application; the only difference is you'd have 10 times as much code and UI to chuck.
Favor quick iterations over long design periods, and constantly let real users experiment with the product in an environment that simulates production conditions. The high end of this approach is to have a test server that you update every several days with new code that your users and project leaders can experiment with and provide feedback on.
The biggest risk of adopting Ajax technology is the general lack of practical experience in the industry. Because of this, I recommend starting small, letting your development team gain experience and confidence without causing major risk to your project. If you decide you want to take the full plunge into pure Ajax at this point, do so with a realistic understanding of your low probability of success. Unless you have a world-class Web development team and the kind of development organization that supports iterative development and experimentation, you'll probably fail.
Over time, though, things will get easier and less risky as more practitioners gain experience and as frameworks, tools, and best practices emerge. Ajax will become safer and more routine... if not nearly as exciting.
I'd like to thank my Rational colleagues Erich Gamma, Grady Booch, Josh Staiger, Pat Mueller, and Scott Rich for sharing their insights and providing feedback on this article.
- "Ajax and REST, Part 1" (Bill Higgins, developerWorks, October 2006): Learn the advantages of the Ajax/REST architectural style for immersive Web applications.
- Ajax Design Patterns (Michael Mahemoff, O'Reilly, 2006): Mahemoff's chapter on Ajax testing provides a nice summary of the state of Ajax unit testing circa 2006.
- Ajax resource center: Your destination for everything Ajax on developerWorks.
Get products and technologies
- Dojo Toolkit: Dojo is an open source Ajax framework with libraries to help with module management, event handling, and remote communication. Dojo's packaging system that lets you easily build and deploy a custom version of your Ajax code and only the parts of Dojo that you need.
- Eclipse Ajax Toolkit Framework (ATF): ATF provides an integrated Ajax toolkit including a DOM inspector, XHR monitor, and "view live source" functionality.
- Internet Explorer Developer Toolbar: DOM inspector and other tools for IE.
- LiveHTTPHeaders and TamperData: XHR monitors for Firefox/Mozilla.
- Fiddler and HTTP Analyzer: XHR monitors for Internet Explorer.
- Ajax discussion forum: For questions regarding Ajax development, this forum, moderated by Jack Herrington, can help you get started.