Ajax:a New approach to WEB applications

Ajax:a New approach to WEB applications

Ajax: A new way to develop Web applications

by Jesse James Garrett

February 18, 2005
Original URL: http://adaptivepath.com/ideas/essays/archives/000385.php

Read this article that pioneered the term Ajax. This is a must-read article for all Ajax developers.

——————————————————————————————————————————————————
If anything about current interaction design can be called "glamorous," it's creating WEB applications. After all heard someone rave about the interaction design of a product which wasn ' t on the Web? (Okay, besides the IPod.) All the cool, innovative new projects is online.

If today's development of interactive features has a compelling appeal, it should be the result of Web application services.

Think about the last time you heard someone complaining about the interaction of a product without web-based? Now the popular, innovative taste of the project has started to have online capabilities.

Despite this, Web interaction designers can ' t help but feel a little envious of our colleagues who create desktop software . The Desktop applications has a richness and responsiveness which has seemed out of reach on the Web. The same simplicity that enabled the Web ' s rapid proliferation also creates a gap between the experiences we can provide a nd the experiences users can get from a desktop application.

Even so, web interactivity developers have to be a bit envious of those who develop desktop applications because desktop applications have a richer and more efficient interactivity that seems to be a high level of difficulty for Web applications. This is the pros and cons of simplicity, which makes Web applications fast-growing and creates a generation gap: the generation gap between the operational experience that Web applications can provide and the experience users can get from desktop applications.

That gap is closing. Take a look at Google Suggest. Watch the suggested terms update as you type, almost instantly. Now on Google Maps. Zoom in. Use your cursor to grab the map and scroll around a bit. Again, everything happens almost instantly, with no waiting for pages to reload.

The generation gap is disappearing. Look at Google Suggest, and observe when we enter a word process, the prompt word is almost at the same time in the update; take a look at GoogleMaps, click on the map with the mouse point, slightly scroll the pulley to zoom operation, you can see it is almost at the same time in the zoom, We do not need to wait for any page update operations.

Google Suggest and Google Maps are both examples of a new approach to Web applications so we at Adaptive Path has been c Alling Ajax. The name is shorthand-asynchronous JavaScript + XML, and it represents a fundamental shift in what's possible on the W Eb.

Google Suggest and Google Maps are two examples of new Web application technologies that we call Ajax in Adaptive Path, an acronym for asynchronous JavaScript +XM. Ajax may represent a fundamental shift in web technology.

Defining Ajax

Ajax definitions

Ajax isn ' t a technology. It's really several technologies, each flourishing in its own right, and coming together in powerful new ways. Ajax incorporates:

Ajax is not a new technology, it is composed of a number of technologies that have become prominent in their own fields in a new and more powerful way. Ajax contains the following aspects:



standards-based presentation using XHTML and CSS;

Dynamic display and interaction using the Document Object Model;

Data interchange and manipulation using XML and XSLT;

Asynchronous data retrieval using XMLHttpRequest;

and JavaScript binding everything together.

Using XHTML and CSS for standard-based representations;

Using the DOM (Document Object model) to display and interact dynamically;

Using XML and XSLT for data exchange and operation;

Using XMLHttpRequest for asynchronous data acquisition;

Using JavaScript to bind the above technology applications;



The classic Web application model works like This:most user actions on the interface trigger an HTTP request back to a We b server. The server does some processing-retrieving data, crunching numbers, talking to various legacy Systems-and then returns An HTML page to the client. It ' s a model adapted from the WEB's original use as a hypertext medium, but as fans of the Elements of User Experience kno W, what makes the Web good for hypertext doesn ' t necessarily make it good for software applications.

The classic Web application model works: Through the client Web interface (Web page), the user's actions trigger an HTTP request to the backend Web server. The server does a series of things: Get the data, analyze the data, interact with the various legacy systems, and then return an HTML page to the client. This Web application model comes from early hypertext Web applications, but as readers of the elements of user experience know, the ability to make the Web more hypertext-capable is not necessarily as effective as application software.




Figure 1:the Traditional model for Web applications (left) compared to the Ajax model (right).

Figure 1, a comparison of the traditional Web application model (left) with the Ajax model (right)

This approach makes a IoT of technical sense, but it doesn ' t make for a great user experience. While the server is doing it thing, what ' s the user doing? That's right, waiting. And at every step in a task, the user waits some more.

The traditional web work mode is technically feasible, but it does not help the user much. What can a user do when the server is working on something? Yes, just waiting, waiting at every step of each task.

Obviously, if we were designing the Web from scratch to applications, we wouldn ' t make users wait around. Once an interface are loaded, why should the user interaction come to a halt every time the application needs something fro M the server? In fact, what should the user see the application go to the server at all?

Obviously, if we were able to design the Web from the start by using the application model, we wouldn't let the user have more waiting responses in the operation. When a page is loaded, why do I need to wait for the user to get something from the server in each interaction? In fact, why should the user be aware of the communication between the Web application and the server?

How Ajax is Different

What is the difference between Ajax?

An AJAX application eliminates the start-stop-start-stop nature of interaction in the WEB by introducing an intermediary- An Ajax engine-between the user and the server. It seems like adding a layer to the application would make it less responsive, and the opposite is true.

Ajax applications will eliminate the inherent nature of the "run-wait-run-wait"---web page interaction. This application is done by introducing an intermediary medium. This intermediate medium, also known as the Ajax engine, is between the user and server tiers, and it seems that adding a layer to the application will make the response slower, but the opposite is true.

Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine-written in JavaScript and US Ually tucked away in a hidden frame. This engine was responsible for both rendering the interface the user sees and communicating with the server on the user ' s Behalf. The Ajax engine allows the user ' s interaction with the application to happen asynchronously-independent of communication With the server. The user is never staring at a blank browser windows and an hourglass icon, waiting around for the server to do Somethin G.

At the beginning of a task, the browser is no longer loading the page, but instead loads a Ajax engine written in JavaScript, folded in a hidden structure. This engine is responsible for showing the user interface and communicating with the server as a user. The Ajax engine allows for asynchronous interaction between the user and the application interface, independent of the communication between the application interface and the server. As a result, users will never see a blank browser window and an hourglass in order to wait for the server's response after an operation has been sent.




Figure 2:the Synchronous interaction pattern of a traditional Web application (top) compared with the asynchronous patter N of an Ajax application (bottom).

Figure 2: Synchronous interaction mode for traditional Web applications (top) vs. asynchronous mode (bottom) for AJAX applications

Every user action, normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine inst ead. Any response to a user action this doesn ' t require a trip back to the Server-such as simple data validation, editing dat A in memory, and even some navigation-the engine handles on its own. If the engine needs something from the server on order to respond-if it's submitting data for processing, loading Additi Onal interface code, or retrieving new data-the engine makes those requests asynchronously, usually using XML, without S Talling a user ' s interaction with the application.

For each user action, the pass produces an HTTP request that, in turn, uses JavaScript to invoke the Ajax engine. For some user actions that do not require a server response, such as simple data validation, editing data in memory, or even some navigational operations, the AJAX engine handles itself. If you need to get data from the server in response to the customer, such as the engine submits the data that needs to be processed to the server, loads other interface code, or acquires new data, the engine uses XML to make these requests asynchronously without blocking the interaction between the user and the application.

Who ' s Using Ajax

Who's going to use Ajax?

Google is making a huge investment in developing the Ajax approach. All of the major products Google have introduced over the last Year-orkut, Gmail, the latest beta version of Google Group S, Google Suggest, and Google Maps-are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Goog Le Suggest, and Google Maps.) Others is following suit:many of the features that people love in Flickr depend on Ajax, and Amazon's a9.com search Engi NE applies similar techniques.

Google is investing heavily in Ajax technology, and several of the key products Google has launched since last year are Ajax technologies such as Orkut,gmail, the latest beta version of Google Groups,google Suggest and Google Maps. (For more technical details on the use of these Ajax products, you can view some analysis of gmail,google suggest and Google maps.) There are other toolkit examples, such as Flickr's many fascinating features that are developed using AJAX, and Amazon's a9.com search engine uses similar techniques.

These projects demonstrate that Ajax isn't only the technically sound, but the also practical for real-world applications. This isn ' t another technology the only works in a laboratory. and Ajax applications can is any size, from the very simple, single-function Google Suggest to the very complex and sophis ticated Google Maps.

These examples show that Ajax is not just a purely technical term, but a real world. It is not the kind of technology that exists only in the laboratory. Ajax is a vast application, from the very simple Google suggest to the very complex and intelligent Google Maps, there is nothing to do.

At Adaptive Path, we've been doing our own work with Ajax over the last several months, and we ' re realizing we've only SCR Atched the surface of the rich interaction and responsiveness that Ajax applications can provide. Ajax is a important development for WEB applications, and its importance are only going to grow. And because there is so many developers out there who already know what to use these technologies, we expect to see many m Ore organizations following Google's leads in reaping the competitive advantage Ajax provides.

In Adaptive Path (company), we have been in touch with Ajax for several months and realize that we are only using a small fraction of the very rich interaction and responsiveness that it offers to applications. Ajax is an important development of Web applications, and its importance has only just emerged. As more and more developers become familiar with how to use Ajax, we expect more organizations to reap the enormous benefits of Ajax under Google's leadership.

Moving Forward

Look forward

The biggest challenges in creating Ajax applications is not technical. The core Ajax technologies is mature, stable, and well understood. Instead, the challenges is for the designers of these applications:to forget what we think we know about the limitations Of the Web, and begin to imagine a wider, richer range of possibilities.

The biggest challenge in developing AJAX applications is not the technology itself, the core technology of Ajax is already mature, stable and easy to understand. The challenge is to come from developers, because when it comes to developing AJAX applications, developers need to throw away old-fashioned ideas about the web and start using the web to conceive of potentially more powerful, more interactive applications.

It's going to being fun. It will bring us pleasure.

Ajax:a New approach to WEB applications