1.8. 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.
1.8.1. 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 functionalitysuch as local data storagethat'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.
1.8.2. 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, browserslike a lot of desktop softwarehave 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.
1.8.3. 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?
1.8.4. 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 has an interesting role in the Ajax world. It's clear that Ajax is stronger from a standards perspectiveyou 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?
1.8.6. 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.
1.8.7. 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 emergingservers such as Twisted (http://twistedmatrix.com/) that support many long-lived connections, along with browser tricks to make the hacks less intrusive.
1.8.8. 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 setsmany megabytesand 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 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?
1.8.11. Development Support
1.8.12. 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.