4.1. Ajax App
Ajax, Balanced, Client-SOA, DHTML, Fast, Fat, Interactive, Platform, RichInternetApplication, Rich, Thick, Web2.0, and WebApp
Figure 4-1. Ajax App
4.1.1. Goal Story
Pam's begun entering staff appraisals into a new Ajax App. She's pleased to see the data entry is much faster: fields are validated as soon as they're filled out, searches are integrated into the form rather than in annoying popups, and the remaining form fields keep mutating to reflect what she's entered so far.
How can you create a rich application?
See Chapter 1 for more details on the forces driving Ajax, which are summarized here.
Produce an Ajax Appa rich application capable of running inside any modern web browser. The user fires up an Ajax App by typing in a URL, clicking a link, or activating a bookmark. The Ajax App is then downloaded into the browser and the user can begin working with it immediately.
Ajax is fundamentally a user-centered pattern. As mentioned in the first chapter, the major force driving Ajax is the needs of users and their organizations to get more out of the Web. For too long, people have endured pages that take forever to load, widgets that make no sense, and forms that conveniently "forget" their data when they take too long to fill out. There are good reasons for people to continue using a browser, as noted in Chapter 1, but it's in the interests of web site owners and employers to do a better job at making that interaction productive and enjoyable.
Ajax aims to improve user experience within the constraint of respecting browser standards. Standard-based design obviously has the benefit of portability, but also has a usability component in itself; users interact with hundreds of web sites and appreciate consistency, a quality that quickly erodes when you rely on plugins, browser-specific features, and "creative" design ideas. Sure, incorporate a novel widget or a funky layout when it works, but for most things, the standard way works best.
Non-standard technologies also break consistency; one reason Flickr (http://flickr.com) began migrating from Flash to Ajax was because users want to right-click to save images, a standard broken by Flash (http://www.ajaxian.com/archives/2005/05/ajax_summit_eri.htm). Again, don't be afraid to use a technology like Flash to achieve something standard browsers won't dothat's the whole idea behind the Richer Plugin (Chapter 8) pattern. Some people will say it's not an Ajax App if it uses Flash, but the definition here would include a mostly Ajax App that delegates to Flash (or other plugins) to fulfill some specialized task. In any event, the definition really isn't worth arguing about (after all, you can define "Ajax" however you like); the important thing is to ask what helps userssometimes, it's better to incorporate some Flash or Java; other times, a desktop solution really is the best approach.
22.214.171.124. Will your application be "Ajax Deluxe" or "Ajax Lite"?
There are two archetypal architectures for Ajax, and all applications lie somewhere along the spectrum between these extremities.[*]
Which will you use? The Deluxe approach suits a development team with more advanced web programming knowledge and access to relevant tools and cross-browser libraries, and generally leads to a nicer, more effective user interface. It also facilitates a well-partitioned architecture, since the presentation logic can be completely isolated inside the browser, and the business logic completely isolated in the server. However, Deluxe applications may place a strain on the browser and network capabilities, and might not even be possible if the browser is outdated. Ajax Lite is a better answer for older browsers, since the Ajax features can usually be "turned off" to support graceful degradation.
126.96.36.199. What browser requirements will there be to run your Ajax App?
One of the reasons why Ajax has taken off now, in spite of people having tried similar things earlier on, is that browsers are now more consistent. For an Ajax App, you'll need to decide which browsers you're targeting and which browsers just aren't worth the effort. XMLHttpRequest is the main constraint, because it usually appears later in a browser's feature set than other foundational technologies. Roughly, we're looking at browsers from around 2001 onwards. A typical guideline is: Internet Explorer 5+ for Windows, Firefox 1+, Mozilla 1+, Safari 1.2+, or Opera 7.6+ (http://en.wikipedia.org/wiki/Ajax_%28programming%2). Other browsers such as Netscape and Konqueror might be considered too. Whether you'll support all these browsers, or just a subset, depends on how important the diversity is, how much expertise or library support you have, and how much time you can devote to testing.
188.8.131.52. How will you treat browsers with insufficient technologies for Ajax?
Building on the previous point, what happens when your application requires features not provided by the browser being used. As explained in Cross-Browser Component (Chapter 12), you can either check for specific features or you can check browser versions. If you do the former, you have the opportunity for graceful degradationto cut out one specific feature or provide a simpler alternative. It's more work, but lets you support more users. The alternative is to give up and suggest the user upgrade browser, sometimes the only thing you can reasonably do.
184.108.40.206. How much processing power will be required of the browser?
220.127.116.11. How much networking capacity will be required?
With Ajax Apps, there are two networking factors to consider:
In some cases, Ajax actually reduces throughput requirements by avoiding full page refresh. Yet, it's important to consider, because there can still be a strain caused by patterns like Periodic Refresh (Chapter 10), which continuously pulls down new data. When you consider that some Ajax features (e.g., Live Search [Chapter 14]) require round trips to the server on just about every keystroke, you can see why latency is becoming a growing theme in web design. For smaller packets, which are common in Ajax Apps, latency is actually a much greater source of delay than throughput, especially across long distances (http://richui.blogspot.com/2005/09/ajax-reducing-latency-with-cdn.html). Again, it comes down to benchmarking and deciding what's feasible. If a round trip takes several hundred milliseconds, responding to each keystroke will probably cause more frustration than joy.
4.1.6. Real-World Examples
Please refer to the examples in Chapter 1.
4.1.7. Code Example
Please refer to the code examples in Chapter 2.
18.104.22.168. Conventional web app
Conventional web apps do have some advantages:
22.214.171.124. Flash app
As pointed out earlier in the "Solution," a standard web app that uses some Flash here and there can still be considered an Ajax App. Here, though, we're comparing Ajax to full-blown Flash, which creates the kind of applications that won't do anything unless Flash is enabled.
Flash and Ajax are actually a close match. Google Maps (http://maps.google.com) caused surprise when it came out, as many assumed that only Flash could produce something as rich inside the browser. Yahoo! then turned it full circle by producing a similar product, Yahoo! Maps (http://maps.yahoo.com/), in Flash. Despite the similarities, significant differences do remain. Compared to Flash, Ajax has the following benefits:
Following are the benefits of Flash over Ajax. Whether these are compelling enough to write a pure Flash app depends on the circumstances; keep in mind that the most appropriate solution is often a combination of Flash and Ajax when it's not possible to stick with pure Ajax.
126.96.36.199. Java applets
For some Java developers, Ajax is déja vù. In the mid-to-late '90s, Java applets were destined to take over the browser and turn the desktop into a trivial sideshow. It didn't happen for various reasons, and Java applets are now rarely seen on the Web. Still, they persist in the enterprise, and as with Flash, it's possible to combine the technologies. Some have speculated that all the interest in Ajax might breathe some life into the world of applets; it doesn't seem to be the case so far, but it's too early to be sure.
Ajax has several advantages over Java applets:
Java applets have several advantages over Ajax:
Sun has more recently introduced Java Web Start as a cross between the desktop and the browser. Web Start apps run off the desktop, but can be launched by activating a URL in the browser. The huge waiting times of applets are avoided because libraries can be held locally and shared across applications. It's a useful alternative to applets and more geared toward the enterprise, though it also hasn't taken off in a big way.
188.8.131.52. Desktop app
There has always been a decision to make between the desktop and the Web. Ajax ramps up the web argument, with even mainstays of the desktop, like word processors and spreadsheets, becoming commonplace in the browser. Microsoft's "Live" strategy, which involves Ajaxified versions of its Office apps, is a major case in point. Still, other applications like games and multimedia tools won't be budging from the desktop for a long time to come.
Ajax offers the following advantages over the desktop:
Ajax has bridged the gap, but desktop apps can still do many things that are beyond the realm of standard web browsers (see also Richer Plugin [Chapter 8]):
184.108.40.206. Mobile app
With mobile apps growing in parallel with Ajax, it's worth considering them as an alternative, albeit a less direct one. As it happens, Ajax itself may actually become a good platform for mobile apps, with Opera now providing Ajax support on its mobile platform (http://www.opera.com/products/mobile/platform/).
4.1.9. Related Patterns
All of the patterns in this language relate in some way to Ajax App. In particular, the earlier "Solution" points to the Foundational Technology patterns that really define what Ajax is all about.