Chapter 1. Introducing Ajax
BY NOW, YOU’VE PROBABLY USED AJAX ON SITES LIKE GOOGLE MAPS (HTTP://MAPS.GOOGLE.COM) Amazon’s A9 search engine (http://a9.com), and Flickr (http://flickr.com). Despite their different domains, all these web sites make heavy use of Ajax. The technology lets them take a great leap forth towards the richness of standard desktop applications, and in a manner which still respects the established conventions of the Web.
Ajax and the Usable Web
No longer are you forced to wait five seconds a web page to reload every time you click on something. Ajax applications change in real-time. They let you drag boxes around instead of clicking on arrows and typing in numbers. They keep page content fresh instead of forcing you to keep hitting Refresh. They show meaningful animations instead of verbose messages.
At the heart of all this is a growing emphasis on web usability.[*] Perhaps you’ve heard the story of the dancing bear—everyone’s impressed with it even though its skills quite frankly wouldn’t get the bear into a dance academy;[*] it makes an impression because it can dance and not because of how well it well dances. The Web felt like that at first. Suddenly you could read news from the other side of the world, find hints on some obscure game, purchase a rare book. All valuable activities, regardless of how easy or difficult to perform them. Usability? We don’t need no stinkin’ usability!
Here’s what happened: people discovered that any coder and his dog can build the basic functionality (and you don’t always need the coder); amid the rush of B2B companies hyping multimillion dollar auction systems, I recall one CTO bragging that his summer students created the same thing for a few thousand bucks. So if companies in a saturated market can’t compete on raw functionality, what can they compete on? The things that matter to users. Most of the companies that have survived and prospered—companies like Google, Amazon, and Yahoo!—avoided feature bloat and promoted simple, though not dumbed-down, interfaces. It’s no coincidence that each of these companies have been busy incorporating Ajax features to that end. Each of these monster dotcoms not only uses Ajax, but has actually pioneered some of the concepts described in this book. You can throw Microsoft into that list as well.
In addition, a whole new generation of companies has risen on the strength of their simple, intuitive applications. 37signals has a suite of tightly focused applications used daily by a passionate user base. With an innovative photo-sharing interface, Flickr built a community of 1 million photo-sharing users in around 18 months.[†] Another recent entrant is Odeo, a podcast manager that works as an easy-to-use web application rather than running in the desktop like most of the competition. Like their giant counterparts, these newcomers are big proponents of Ajax and have helped define the concepts behind many of the Ajax Patterns featured in this book.
And then there are all the systems you and I will never see firsthand: the scores of web applications sitting on closed intranets. Like the dotcoms, there remain plenty of dancing bears in this category too. Companies welcomed internal web apps, but mostly for technical reasons, such as easy deployment, monitoring, and remote access—and also because it seemed like the “cool” thing to do. Usability was rarely the driving factor. Just ask a user who’s wondering where her keyboard shortcuts have gone in the “new, improved” web interface. I recall one web migration that increased an average customer transaction from 20 seconds to 2 minutes! One reaction has been to throw in the towel and retreat back to the desktop. But many companies have chosen to persist with the Web, accepting the idionsyncracies and using whatever workarounds are necessary to get the benefits of a web platform without the usual problems. It’s this spirit that has led to Ajax features evolving in the enterprise, and the popularity of Ajax continues to fuel progress. While many usages will remain hidden, one open example we do have is work performed internally at the Sabre travel company, which led to the open source OpenRico library (http://looksgoodworkswell.blogspot.com/2005/06/death-to-paging-rico-livegrid-released.html).
In summary, Ajax aims to keep the benefits of the Web, but without sacrificing usability. Most users are now comfortable working inside the browser—meaning that, for some applications, we actually get the best of both worlds: better usability and better infrastructure.
The Rise of Ajax
On February 18, 2005, Jesse-James Garrett published an online article “Ajax: A New Approach to Web Applications” (http://www.adaptivepath.com/publications/essays/archives/000385.php). The Web was becoming richer and responsive, closing the gap with the desktop. Garrett introduced “Ajax” to label the architecture behind the new generation of rich web apps like Google Maps and Google Suggest. Ajax isn’t a plugin, nor a proprietary technology. It’s an architectural style—a high-level design pattern—composed of many related technologies and ideas.
Ajax technologies and applications were around before Garrett’s article labelled them as such, but the article was a tipping point. Just like when the terms, “object-oriented,” “agile development,” and “postmodernism” began to be used, a converging trend had been given a buzzworthy umbrella term around which a community could form. “Ajax” gave us a label for the systems that were combining several powerful technologies. With this label established, the development community could suddenly share ideas about how the technologies fit together, debate in blogs about different design approaches, build libraries to support these kind of systems, and catalog common patterns.
Strictly speaking, the term is an acronym —“AJAX,” for “Asynchronous JavaScript + XML”—although Garrett has noted that other technologies like CSS and DOM are just as important in the Ajax equation. “Ajax” just happens to roll off the tongue a whole lot easier than “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest.” Consistent with his original article, Ajax is generally written “Ajax,” not “AJAX.” That’s a mindset, not mere cosmetic detail, because Ajax is a design style and attitude rather than a precise set of technologies; the technologies are whatever happen to let us build the things we want to build. Throughout this book, I refer to Ajax in terms of what it offers users and their organizations. Here’s a working definition:
An Ajax application builds on standard web technologies to deliver a rich, responsive, user experience.
If you look at the Ajax poster children like Google Maps and Gmail, it should be apparent how they fit this definition. They rely on nothing more than a standard web browser, be it Internet Explorer (IE), Firefox, Safari, Opera, or several others. The interfaces are rich in that they include input controls and display effects that go well beyond the familiar form-submission paradigm. And they’re responsive in that changes happen quickly and incrementally. The definition is there to be applied pragmatically—the last thing you’ll hear from me is a big argument about whether or not application X is Ajaxian or not. We’ll walk through typical characteristics of Ajax apps later on, but let’s now look at some examples of how Ajax is transforming the Web.
Ajaxifying the Web: The Story of Portals
If you Google for “year of the portal”, you’ll find ample evidence that every year since 1996 has been the year of the portal. It’s just around the corner, really. The idea has so much promise: the first thing you see when your browser opens up is a personal homepage with “My News” and “My Mail” and lots of other boxes just about “Me.” In short, a page created by Me for Me. So why have they never really taken off? One big factor is that most portal interfaces, frankly, are unusable.[*]
Consider the problems you face in using a legacy-style portal, using Excite.com as an example—many other conventional portals work in a similar manner (Figure 1-1).[*]
Customizing the page is the most critical task, but you have to register first; each of the customization controls on the homepage will close the portal and take you to a completely different registration page.
Adding new “portlets” —the blocks of content—is rather painful. You have to click on Add/Delete Content, which will whisk you off to a tabbed configuration interface. There, you add and delete portlets by updating a list of current portlets.
Customizing an individual portlet—e.g., setting the stocks you’re watching—will close the portal and send you to a special configuration page. You’ve lost the context.
Changing layout doesn’t happen directly on the page, but in the configuration area. The layout is managed on a miniature model of the real portal, with titles shown only. (Some portals require repetitive clicking on arrow buttons for layout; fortunately, Excite allows drag-and-drop on the model.)
Volatile content such as news and market information is present on the page, but refreshes occur only occasionally; the smallest allowed period is five minutes. Refreshes force the whole page to be reloaded, which is not only distracting, but also makes it difficult for the user to see what, if anything, just changed.
You can’t interact with individual portlets—for example, to perform a search. Any time you act on a portlet, such as submitting a form from it, the entire page will update or you’ll be sent to a new location.
Portals are so well-suited to Ajaxification that they are probably the most widespread Ajax genre right now; editing the Ajaxian.com blog in late 2005, we reached a point where we were hearing about two or three new Ajax portals a week! Some, like the popular NetVibes (http://netvibes.com) and Protopage (http://protopage.com) products, are startups. Among the more mature portal producers are none other than Google (http://www.google.com/ig/) and Microsoft (http://live.com). An explanation follows of how Ajax rectifies each of the problems mentioned above, using NetVibes as an example (Figure 1-2).
When a new user visits NetVibes, she is free to add and manipulate content, which will stay there for the next time she logs in from the same browser (via cookies). As explained in Lazy Registration (Chapter 17), this has always been possible, but Ajax makes the customizations richer and the transition to registering smoother.
Clicking on NetVibes’ Add Content link doesn’t cause a disruptive new page to be shown. It is simply the appearance of a new column (an example of the Microlink pattern). There, you can choose new portlet types and watch them appear instantly in the portal. Thanks to the remoting and display manipulation technologies of Ajax, a browser app can talk to the server and update elements without forcing a page refresh.
Portlets are customized in-page and without disrupting the other content. Clicking on an Edit link will lead to a small customization form being squeezed into the portlet (an example of Malleable Content). There’s no page refresh involved, and you can see the effects of editing immediately.
Changing layout is as effortless—and fun—as dragging portlets around the page, discussed in Drag-And-Drop (Chapter 15).
Portlet content is updated directly and without page refresh. Moreover, each portlet is refreshed on its own schedule. In theory, the weather portlet could be updated once a day; the news portlet every five minutes; the stock portlet each second, as explained in Periodic Refresh (Chapter 10) and in Portlet (Chapter 15). When a portlet updates, an effect like those described in One-Second Spotlight (Chapter 16), can be shown for the sake of user feedback.
You can have a conversation with an individual portlet, clicking on controls and watching it update. It’s as if the portlet is a mini-page; no page refresh occurs and no other content is affected.
The story of portals demonstrates how Ajax can radically improve the usability of a well-established web genre. Indeed, Ajax is breathing new life into many genres that, like portals, had stagnated. Flickr is an Ajax-heavy update of the old photo-sharing category. Gmail (http://gmail.com)reinvented webmail, Google Maps (http://www.googlemaps.com) reinvented maps, and Google Suggest (http://www.google.com/webhp?complete=1&hl=en) opened up new possibilities for search and data entry. Newer genres like RSS readers, wikis, social bookmarking and tagging are also benefiting from Ajax.
Webifying the Desktop: The Story of Office Applications
Attempts to webify office applications are almost as old as the Web itself. It’s now part of computer folklore that Netscape’s Marc Andreesen exclaimed, in the mid-1990s, that MS-Windows would be reduced to “a poorly debugged set of device drivers running Netscape Navigator,” expecting to herald in a new era of desktop-style applications running inside the browser. The benefits of the Web over desktop apps are clear and abundant—e.g., an ability to access data from any web browser in the world, easy upgrading, no tampering of local machines, and better collaboration. However, there are serious problems too, and the most severe is interface. In the past, it’s simply been impossible to produce a portable interface that’s good enough to justify switching from the desktop.
This is changing quickly though, thanks to Ajax.[*] A new generation of Ajax office applications (http://innerphaze.homelinux.com/blog/?p=28) are emerging as a serious substitute for MS-Word, Excel, and their desktop contemporaries.
One such offering is Writely, a Google acquisition billed as “The Web Word Processor” (Figure 1-3). Writely rightly avoids slavishly reproducing the desktop word-processing experience and instead aims for a feature set and interface that will work on the Web. The result is something that’s as much a turbo-charged wiki as a webified word processor. The list that follows describes some of its features.
The content under edit is What-You-See-Is-What-You-Get (WYSIWYG). As you edit, you get to see the final content—color, fonts, layout, and all. The idea is covered in Rich Text Editor (Chapter 14).
Writely allows several people to collaborate on the same document at once. Using technology described in the Periodic Refresh (Chapter 10) pattern, it’s able to keep updating the document and also the status of other authors.
Documents are easy to manage—you can “tag” (add keywords) and “star” (mark for attention) an element with immediate effect. Again, this is an example of fitting into web conventions. The Web Remoting (Chapter 6) patterns describe making the change persistent without forcing a page refresh.
The story of office applications illustrates there’s enough new substance in Ajax to contemplate serious web versions of applications that have been stuck in the desktop forever. In addition to Writely, spreadsheets are being supported by the likes of NumSum (http://numsum.com) and presentation managers are being supported by the likes of S5 ((http://www.meyerweb.com/eric/tools/s5/). Beyond the office, there are Ajax versions of instant messaging clients (see Meebo at http://meebo.com), terminal emulators (see Anyterm at http://anyterm.org/), and even programming environments (see Why the Lucky Stiff’s Try Ruby at http://tryruby.hobix.com/). Web applications will always be more limited than their desktop counterparts, but Ajax closes the gap to a point where many of them are suddenly “good enough.” Being “good enough” will trump many users’ desktop alternatives, thanks to the intrinsic benefits of working inside the browser.
Characteristics of Ajax Applications
Earlier on, Ajax was defined as a technology that “builds on standard web technologies to deliver a rich, responsive, user experience.” This shouldn’t be seen as a binary thing, because it’s useful to think of Ajax as a continuous spectrum—an application that happens to include a Flash widget, or one that avoids using any remoting technology can still be considered “partly” Ajaxian; it’s useful to do so if you’re designing that system as you can leverage the experience of other Ajax developers, which is the kind of experience encapsulated in the Ajax Patterns. And in documenting the Ajax Patterns, it’s certainly useful to learn from applications that aren’t “pure Ajax.” To that end, the characteristics here are intended as a general guide, but not hard-and-fast rules, for what constitutes an Ajax application.
Applications, Not Just Web Sites
These days, you’ll hear a lot more about “web applications”—or “webapps”—than about “web sites.” Driving many modern web projects is the perspective of the browser as a platform and the Web as an operating system. People aren’t just buying a book or browsing a manual, but are performing day-to-day work as well as socializing via the browser platform, often working on more critical, complex tasks than in the past. While Ajax can really be applied to anything running inside a browser, it comes into its own with these kinds of systems, where it helps keeps users engaged and productive.
Smooth, Continuous Interaction
Traditional web sites make you submit a form, wait a few seconds, watch the page redraw, and then start the whole cycle again. That’s because the tiniest server interaction, and even the tiniest display change, requires a call to the server, and then a complete page refresh. It’s a frustratingly slow and erratic sequence. Ajax changes the model in a few ways. First, JavaScript running inside the browser can manipulate the display directly—you don’t have to send a whole new page from the server in order to hide an element or rearrange the page. Second, server interaction can be handled via JavaScript, so you can upload user commands and download new information without any page refresh. Third, user actions such as mouse-clicking and typing can be handled by JavaScript, so the interaction is a lot richer than just filling in a form and hitting Submit. All of these enhancements make Ajax interaction feel faster and more continuous.
Live
With browser-server interaction no longer a major ritual, it’s possible to continuously poll the server for new information. Thus, an Ajax App can be programmed to always show the latest news, details on who else is online, or to send messages to the user. The content is “live.”
Supportive
Ajax Apps can monitor user actions and proactively support whatever task the user’s working on. Actions as small as a single keystroke can lead to a server call, where the server’s knowledge and processing power can be harnessed to produce useful content a subsecond later. For example, a form might change according to the user’s input, or an error message might appear as soon as a value is typed.
Visual Effects
Ajax Apps look similar to conventional web apps, but do tend to include a little more animation. Not the kind of flashy animation that’s just there for the sake of it, but animation that gets across a message about what’s happening and what the user can do next. For example, a deleted icon might slowly shrink and disappear.
New Widgets
Ajax widgets go beyond the standard HTML controls—text fields, selectors, buttons, and so on. Widgets such as sliders and progress indicators, built on standard HTML elements, are becoming popular. As well, we’re seeing conventional widgets enhanced. Instead of a boring old table, you might see a searchable, editable data grid. In place of a textarea element, you might see a rich text editor with “What-You-See-Is-What-You-Get” qualities similar to most word processors.
New Styles of Interaction
It’s not only widgets that are getting an upgrade, but styles of interaction. Here, too, Ajax developers have been borrowing from concepts in traditional desktop environments. Drag-and-drop, for example, has been a staple feature of windowing environments for two decades, but somehow didn’t made it onto the Web for a long, long time. Now we’re seeing it more and more, and it all makes so much sense, as the earlier portal example illustrated. Other styles of interaction are also becoming more popular. Keyboard shortcuts are being used to streamline activity. And some developers are being a bit more adventurous with mouse buttons, experimenting with double-clicking as well as the right and middle buttons. We’re yet to see mouse gestures like those available in the Opera browser and other programs, but anything’s possible.
Standards-Based
Ajax applications require nothing more than a standard web browser from the past few years, such as Internet Explorer 6 or Firefox 1.0. While the precise browser coverage depends on your objectives, the point is that Ajax makes the most of standard browser features and avoids browser-specific features and plugins where possible. This means more than standard technologies; it’s also about respecting standard user-interface conventions of the Web.
The Ajax Technologies
Here’s a quick rundown of the various technologies involved in Ajax. To begin with, there are several that have always been popular on the Web, which are relatively well-understood by the development community. They are still used in Ajax applications, though sometimes in different ways.
- HTML/XHTML
As always, HTML provides the structure of a web page. An Ajax App uses an HTML document to show the initial page, and the document is continuously manipulated to change the display and set up new events. Where possible, its XML-compliant variant, XHTML, should be used in order to make manipulation more robust.
- CSS
CSS enriches the display and, thanks to stylesheets, helps separate document structure from style details. Fortunately, browsers are now reasonably consistent in their support for CSS2, so the past few years have seen many web sites shift from table-based layout, which was always something of a hack, to the cleaner, more flexible, CSS-based layout. From our perspective, the great thing about all this is that CSS can easily be manipulated with JavaScript. With just one line of code, you can make an object disappear, move it around the page, or alter its appearance.
- HTTP, CGI, Form Submission
As with conventional web applications, Ajax communicates via HTTP. The difference is that instead of returning full pages, the server returns concise results that are then processed in the browser script. Form submission—often with CGI-style URLs—is also used, but again is initiated programmatically, meaning that no page refresh need take place.
- Server-Side Scripting
The server is still required to perform tasks like data persistence and input validation. However, in some Ajax architectures, it no longer performs any duty of display or application logic, leaving those things for the browser script to handle.
Ajax also adds a mix of newer technologies. I say “newer” with considerable reservation, because every one of them has actually been around for many years. It’s just that they’re only now becoming well-understood, standard across all major browsers, and combined together to produce a new style of application.
- JavaScript
One thing is true about any Ajax App: stuff happens in the browser. JavaScript is the client-side programming language that coordinates browser activity. Prior to Ajax, web developers might have sprinkled a little JavaScript into their pages, but few could claim to have a thorough understanding of the language. That’s now changing, with developers making an effort to master JavaScript just as they would strive to learn any given server-side language.
- XML and the Document Object Model (DOM)
A DOM object is a hierarchical data structure representing an XML document, and JavaScript can read and manipulate DOM structures. One particularly important XML document is the current web page, since HTML is, loosely speaking, a dialect of XML (for most intents and purposes, browsers will treat it as such, though it’s really only when you code in XHTML—an XMLicized form for HTML—that you’re truly using XML). Being a kind of XML document, the current web page is exposed as a DOM object in the browser, and by manipulating it, you can affect what’s on the page (see Display Morphing and Page Rearrangement [Chapter 5]). In addition, there will be other DOM objects as well if you choose to talk to the server using XML Message.
- Event model (“DHTML”)
The event model allows JavaScript to respond to events such as mouse clicks. This is the key to interactivity within the browser—a conversation between the user and the web site (see User Action and Scheduling [Chapter 7]).
- Web Remoting
Web Remoting is the ability for JavaScript to talk directly with the server—no page refresh required.
XMLHttpRequestdominates most of the headlines, but there are actually several viable remoting technologies (see XMLHttpRequest Call, IFrame Call, HTTP Streaming , and On-Demand JavaScript [Chapter 6]).
Anatomy of a Server Call
At a lower level, how does an Ajax interaction look? Here’s a typical sequence of events. Let’s begin with the application startup sequence (Figure 1-4):
User points browser to Ajax App. The user begins interacting with an Ajax application by visiting it in the usual way; e.g., by following a link or selecting a bookmark.
Browser loads initial content. The browser fills up with initial content sent out by the Ajax application. This includes the initial HTML to be displayed, the CSS to establish styling, and the JavaScript code to manage further interaction. The HTML is sometimes as raw as a general page structure, in which case the initial content will subsequently be pulled down in a second call. The code will usually set up event handlers to dictate how the system should respond to user actions.
Once the application has loaded, further activity will be triggered by events. Following is the typical sequence for each event (Figure 1-5):
User does something. Most events are triggered by user actions such as mouse clicks. As explained in Dynamic Behavior patterns, JavaScript functions can be registered against particular event types on particular page elements; e.g., you can arrange for the
purchase( )function to be called whenever a shopping item (the page element) is double-clicked (the event type). Thus, the user action will typically cause an event handler to be invoked.Event handler sends request to server. Certain events require server interaction—for example, the user has just entered some information that should be validated by the server; or the user has just requested some new information.
XMLHttpRequest—a key Ajax technology—is designed specifically for this purpose. It’s a way for JavaScript code to directly call the server, and in doing so, the code will indicate a callback function that will be notified when the response eventually arrives. Browser-server interaction is described in Web Remoting (Chapter 6) patterns.Server processes request. In the server, a web service (see the Web Service [Chapter 6] pattern) receives the request.
Server responds. The web service receives the request and outputs a response using standard HTTP techniques that will be familiar to anyone who has worked on traditional web applications.
Browser callback function receives response. Back in the browser, the callback function is notified that the call has completed and can read the server response. It’s free to use the response however it wants, but the most common activity is changing the display. This relies on manipulating the DOM, a representation of the web page that can be altered with JavaScript. See the Display Manipulation (Chapter 5) patterns for more details.
The sequence gives a quick overview of the technologies—there’s a hands-on introduction to each of them in the next chapter, and the first part of the patterns, Foundational Technology Patterns (Part II) covers them in more detail.
Ajax Trends
This book has certainly been a moving target. There were already quite a few Ajax applications available when the “Ajax” term was coined, and the space has since exploded, propelled by the rush of activity in what’s come to be known as the “Web 2.0” movement. Each day is bringing fresh ideas to the table, as more and more Ajax applications are released. It’s impossible to know where it will all lead, but this section identifies a few future trends and open questions.
Standards and Fragmentation
Better compatibility across browsers has made rich web development much easier. However, we’re at a crossroads now, because the same economic boom that’s fuelling Ajax application development is also fuelling innovations in the browsers themselves, leading to a serious risk of diverging technologies.
One group pushing for change is the Web Hypertext Application Technology Working Group (WHAT-WG). The key term here is “Application,” as the group is pushing for the Web as a true application platform, a goal that resonates loudly with the aims of Ajax. Under current proposals, rich controls and interaction techniques such as drag-and-drop will enjoy native browser support. All this is good for Ajax developers, but will probably come at the price of compatibility. It’s not clear which browsers will support which standards, and there are likely to be major discrepancies in the implementation schedules. Moreover, Microsoft is conspicuous by its absence from WHAT-WG, and it’s distinctly possible IE will end up with a very different API for all this functionality. As well as standards endorsed by WHAT-WG and W3C, there will inevitably be browser-specific features to consider as well. Microsoft will continue to evolve its Atlas framework, and it’s certainly possible that IE will give Atlas functionality—such as local data storage—that’s not available to other browsers.
If browsers do go down the mid-1990s path of diverging APIs, developers will have to decide on appropriate strategy. The options will include: targeting a specific browser (unfortunate, but will sometimes be the most pragmatic choice), ignoring browser-specific features, and relying on compatible plugins for behavior not directly supported by a particular browser.
Browser Adoption
There may well be many browser enhancements on the horizon, but will users upgrade to take advantage of those features? Most Internet users haven’t heard of Ajax and probably wouldn’t care a great deal if you told them about it. They’ll need a lot of convincing to upgrade their browser and even greater persuasion in order to switch to a different brand. On the other hand, there’s now a large population who grew up with the Internet and are quite comfortable with frequent upgrades and browser switches. Furthermore, browsers—like a lot of desktop software—have become smarter about upgrading themselves, so for users who have installed a recent browser edition that does this, they will always have the latest browser features available.
User Acceptance
Early indications are that users appreciate most Ajax features, but it’s still not clear if mainstream users will feel comfortable with features like drag-and-drop and full-blown applications like word processors running inside the browser. Another issue is the handling of URLs and the Back button. The problem is not as bad as some critics have argued, as explained in the Unique URLs (Chapter 17) pattern, but it’s true that features like page refresh and the Back button don’t work exactly the same way as in conventional applications. How will users deal with all these changes, and what tricks will developers discover to help the situation?
The Desktop
Being something of a substitute for the desktop, Ajax’s future will be affected by what happens there. Some have predicted the demise of traditional desktop genres as word processors and personal information managers. Certainly, Ajax has closed the gap, and the question is whether the gap will continue to close or widen due to desktop innovation. Microsoft’s Live strategy, as well as the rumored Ajax version of the Star Office product from Sun and Google, will be especially interesting to watch, as they essentially involve a hybrid approach: a rich desktop for deep, long-term activity and a lighter Ajax client with all the benefits of a web interface described earlier on.
Flash
Flash has an interesting role in the Ajax world. It’s clear that Ajax is stronger from a standards perspective—you can take a regular form and sprinkle some Ajax onto it by way of effects and dynamic validation. Even better, the form can be made to work with or without Ajax technologies available. Flash, however, does many things Ajax can’t, such as hardware access, rich graphics, and local file storage. And both technologies are moving targets. Will Adobe steer Flash towards being a direct replacement for Ajax or more of a complementary technology? Or might upcoming browser innovations trump Flash’s main selling points?
Rich Graphics
Dynamic vector graphics are now possible. IE supports Vector Markup Language (VML), and Firefox and Safari support SVG. We’ll likely see sophisticated APIs evolve and eventually 3-D graphics, opening up even more possibilities. Compatibility issues aside, there are going to be many design issues to consider. In theory, you can generate any display you like, so you could potentially ignore HTML standards altogether and build a set of controls from scratch. That’s an extreme example, but developers will face day-to-day decisions between sticking with the standard or opting for a richer custom control, and libraries will likely emerge to provide such controls.
The Two-Way Web
On the Web, it’s always the browser that initiates a connection. There’s no way for the server to jump into the user’s browser and say “Hey, your buddy just logged on!” Well, no standard way anyway; for a long time now, people have been trying every hack they can think of to enable what’s known variously as “server push,” “streaming,” “the two-way web,” and, more recently, “Comet” (http://alex.dojotoolkit.org/?p=545). These ideas aren’t central to Ajax, but there’s certainly a growing undercurrent of interest and a great deal of synergy with the core Ajax technologies. A few patterns in this book address the idea (HTTP Streaming, Periodic Refresh and Distributed Events), but it’s still difficult to do well, fraught with compatibility issues, and certainly a challenge to scale. Solutions are emerging—servers such as Twisted (http://twistedmatrix.com/) that support many long-lived connections, along with browser tricks to make the hacks less intrusive.
Local Storage
As Ajax has become popular, there has become a stronger demand for local storage. Right now, the only standard way to store data inside the browser is with cookies. But people want a way to store much larger data sets—many megabytes—and also to prevent the data ever being transmitted to the server. In addition, local data storage lets users continue to work offline, thus resolving a major argument against rich web applications. Some Ajax libraries, like Dojo, now hook into Flash’s local storage capabilities. In addition, there are plans ahead for Firefox to support it, and Microsoft’s Atlas framework has also indicated it will do so (it’s not clear if the support will be IE-specific). Is local storage really useful when Ajax makes it so easy to synchronize with the server? Will users understand what’s local and what’s not, and will they be able to manage their data? There will be design issues as well, such as how to handle synchronization after an offline session.
XForms
XForms is a new standard being defined by the W3C, a major upgrade of the standard web form. XForms separate data from view, offer rich widgets for data manipulation, and allow fields to respond to changes in other fields. All of this is already possible with Ajax, but XForms is a more standards-based approach. It’s an interesting question as to whether XForms will really take off now that Ajax is so popular, and if it does take off, how will it coexist with Ajax technologies such as web remoting?
JavaScript
Developers have begun taking JavaScript seriously as a result of Ajax, and the language will continue to evolve. In the future, we can expect to see improved support for multithreading, classic interface-implementation separation, and various syntax improvements (see http://weblogs.mozillazine.org/roadmap/archives/008325.html). In addition, server-side JavaScript might grow in popularity as it would help with Ajax applications, which often need the same logic and data structures on both sides of the network. For example, validation logic is often run in the browser for better performance, but it must be double-checked in the server for security reasons. In addition to the language evolving, design patterns will also continue to evolve as people push JavaScript to its limits and create more complex scripts.
Development Support
There’s already a plethora of Ajax-related libraries and frameworks available (see Appendix A), but we’ll likely see a lot more of these develop as Ajax goes mainstream and as the underlying technologies continue to evolve. IDEs and related tools will also evolve—we’ll hopefully have the same kind of support for JavaScript that programs like Eclipse and IntelliJ Idea offer today for Java. This includes code refactoring, error checking as you type, and suggestions for code fixes. There are also more specialized, web-related needs, such as traffic visualization and automated web testing. Though tools for these things have been around for a while, they’ll need to become a lot more sophisticated to support complex Ajax Apps.
Hardware and Bandwidth Improvements
There have already been surprises with Ajax, such as Google Suggest (http://www.google.com/webhp?complete=1&hl=en) showing it’s possible to make a round-trip to the server on just about every keystroke. With improving hardware and bandwidth, it will be possible to do even more things previously considered impractical. And more than just bandwidth, latency will also be a critical factor. Might Ajax be practical for real-time multimedia collaboration? Networked games? Interactive data visualization? The answers will depend on the extent of hardware and bandwidth advances, as well as the ability of browser and server software to exploit them.
Conclusions
This chapter has introduced the basic technologies of Ajax, provided overviewed characteristic examples, and given some indication of where it’s all going, though there will doubtless be some surprises along the way. Even if the “Ajax” name is fairly new, Ajax has been kicking around in various corners of the Net for some time now, and the rest of the book explains what we’ve learned so far about working with Ajax. In the next chapter, we’ll dive head-first into Ajax with a “pattern-led tutorial”—a hands-on introduction to the basic technologies of Ajax as well as the Ajax Patterns that guide their usage.
[*] See Thomas Baekdal’s “The Usability Revolution is Over—We Won!” (http://www.baekdal.com/articles/Usability/usability-revolution/).
[*] The dancing bear story is used throughout The Inmates Are Running the Asylum (Cooper, 1999), a book decrying the obsession with everything that’s “cool” at the expensive of true usability.
[†] The Flickr estimate is based on a projection from a June 2005 article (http://www.internetnews.com/ec-news/article.php/3512866) that cites the user base as 775,000 and growing at 30 percent per month, leading to over a million users in June or July. The company launched in February 2004 (http://www.adaptivepath.com/publications/essays/archives/000519.php) and was soon acquired by Yahoo!.
[*] There are several problems with portals that Ajax can’t solve on its own. Most importantly, the fact that portal servers don’t know what you’re doing in the browser most of the time suggests that some kind of browser plugin is necessary. Nevertheless, Ajax remains the most obvious way to create the Web interface to any such system.
[*] I’m not picking on Excite, which gained a lot of interest and did some good things with the technology that was available at the time; its inclusion here is testimony to its status as the quintessential example of the first generation of portals.
[*] As with the portals, Ajax alone is no magic bullet for web-based office apps—there are other issues at stake like interoperability and security of hosted content. That said, Ajax does remove one big barrier by at least making them usable.
Get Ajax Design Patterns now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
