Thursday, November 15, 2007

What is Ajax?

We were getting a number of querries from our clients and friends, asking about what AJAX is?



With the development of Microsoft's Live, everyone is going crazy about
AJAX. So, we at Xaprio Solutions thaught of publishing this small
article about AJAX, which will help you guys understand it better.



Like DHTML, LAMP, or SPA, Ajax is not a technology in itself, but a
term that refers to the use of a group of technologies together. In
fact, derivative/composite technologies based substantially upon Ajax,
such as AFLAX, are already appearing. The Term AJAX refers to,
Asynchronous JavaScript and XML.



For a number of tasks, only small amounts of data need to be
transferred between the client and the server, allowing a number of
Ajax applications to perform almost as well as applications executed
natively on the user's machine. This has the effect that pages need
only be incrementally updated in the user's browser, rather than having
to be entirely refreshed.



"Every user's action that normally would generate an HTTP request takes
the form of a JavaScript call to the Ajax engine instead", wrote Jesse
James Garrett, in the essay that first defined the term. "Any response
to a user action that doesn't require a trip back to the server -- such
as simple data validation, editing data in memory, and even some
navigation -- the engine handles on its own. If the engine needs
something from the server in order to respond -- if it's submitting
data for processing, loading additional interface code, or retrieving
new data -- the engine makes those requests asynchronously, usually
using XML, without stalling a user's interaction with the application."



Traditional web applications essentially submit forms, completed by a
user, to a web server. The web server does some processing, and
responds by sending a new web page back. Because the server must send a
whole new page each time, applications run more slowly and awkwardly
than their native counterparts.



Ajax applications, on the other hand, can send requests to the web
server to retrieve only the data that is needed, and may use SOAP or
some other XML-based web services dialect. On the client, JavaScript
processes the web server's response, and may then modify the document's
content through the DOM to show the user that an action has been
completed. The result is a more responsive application, since the
amount of data interchanged between the web browser and web server is
vastly reduced. Web server processing time is also saved, since much of
it is done on the client.



The earliest form of asynchronous remote scripting, Microsoft's Remote
Scripting, was developed before XMLHttpRequest existed, and made use of
a dedicated Java applet. Thereafter, remote scripting was extended by
Netscape DevEdge at around 2001/2002 by use of an IFRAME instead of a
Java applet.

Powered by ScribeFire.

No comments: