Brief FAQ of AJAX Programming Concepts

Q: What is the AJAX?

A: Well, it is the Asynchronous Javascript And Xml. The technology exists since 1995-98, however the term AJAX is used since 2005.

Q: How does the AJAX work?

A: The AJAX works as follows:

• the javascript in a browser reacts to a client-side event. An instance of XMLHttpRequest class is created inside a web browser. It acts like a "browser" inside the browser - it can handle GET/POST request from within the javascript,
• the XmlHttpRequest connects to the server and a server-side component handles the request,
• the request returns to the original page and a XML response is handled by another javascript routine which updates the state of the page according to the response content,

Most of todays frameworks actually do not rely on XML as the response protocol but instead the JSON is used. It also means that today we rather use AJAJ than AJAX (Asynchronous Javascript And JSON). Client-server roundtrips are usually called callbacks instead of postbacks which occur in standard form-posting scenario. The most reduced infrastructure, where the response takes form of an HTML fragment which is used to replace part of a page in user's browser, is often referred to as AHAH (Asynchronous HTTP and HTML).

Q: So, why do we need AJAX?

A: To minimize the ugly effect of page reloading? No. It can be achieved much easier.

There are in fact two important reasons for AJAX:

• to minimize the amount of data sent to and from the application server (we do not POST the entire HTML form and do not respond with the entire HTML page)
• to improve the user performance (for example: to provide a dynamic context-sensitive content when the user types into a textbox)

Q: Why do we need AJAX frameworks?

A: It is easy and possible to write an AJAX-style application without any support from a high-level framework. You just learn how to use the XMLHttpRequest and are on your own.

This, however, could be very inefficient. For any action which needs to be "AJAXified" you need three core components:

• (I) a client-side javascript code raised by a browser event, responsible for creating a request to the server
• (S) any server-side component which handles the GET/POST of the request from previous step
• (R) a client-side javascript which handles the response of the server

I call these three components I, S and R (Init, Server and Response) and I call the whole AJAX mayhem "the I-S-R problem".

The nice aspect of calling all these three components is to realize that they are, in fact, quite independent. You can expect frameworks which attack all three issues in one coherent way, however nothing stops you from using completely different components for each of the three.

Q: I am lost in the plethora of AJAX frameworks. Can they be somehow classified?

A: I did some research and I've found the I-S-R perspective quite handy. When I see a new framework, I immediately focus on its I-S-R components and thus I am able to compare the framework to other which focus on similar issues. I think that five different approaches to AJAX can be identified:

I Incomplete I-S-R frameworks

Examples:

• AJAX.NET
• Outpost
• AjaxAspects
• WebORB.NET
• JayRock
• Bindows
• TIBCO General Interface
• ... many, many others

Profile:

• you manually program the client-side user interface ...
• ... or manually program the server-side components ...
• ... or manually consume server responses on the client-side
• sometimes semi-automatic creation of callbacks (for example: server-side interface is "mirrored" on the client side by a set of proxy interfaces and a convenient way of calling server-side API with these proxies is provided)

None of these "incomplete" frameworks provide the complete way to handle the I-S-R problem. The interesting thing is that this is where you can mix different frameworks which operate on different levels of the problem so for example you can use Bindows as the GUI provider and the JayRock as the server-side gateway.

II Custom AJAX components

Examples:

• Gaia Ajax Widgets

Profile:

• someone builds a set of ASP.NET components which, instead of providing values for standard form POSTs, handle their events in an AJAX-style. Usually these components "mimic" the ASP.NET components and you "switch" from ASP.NET library components to such AJAX-enabled components by just changing <asp:Button> to <XYZ:Button> etc.
• it's great to see that someone knows how AJAX works, however I belive that "component switching" is just a wrong direction

III Ajax Managers

Examples:

• Microsoft's ASP.NET AJAX
• Ajaxium
• Anthem.NET
• Comfort ASP.NET
• Telerik's RAD AJAX

Profile:

• you get an AJAX Manager, an ASP.NET component which, when put on a page, automatically converts all postbacks to callbacks. Sometimes it takes 15 seconds to AJAX-enable your application,
• more advanced frameworks are in the II and III group in the same time - you have AJAX Managers which convert existing applications into AJAX-enabled applications plus a bunch of optimized components is available for more advanced UI stuff

IV "Client-side logic with server-side tools" frameworks

Examples:

• GWT
• Script#

Profile:

• client-side logic is built with server-side technology (C#/Java) and then magically converted to a bunch of javascripts
• you develop "javascripts" using strongly-typed languages, you test "javascript" with your favourite testing frameworks
• it sounds great until you try write a code which opens a file ...
• ... and then you realize that, in fact, you are using a really small subset of server-side technology and "opening files" does not belong to this subset ...
• ... so whenever you are to perform a server-side action, you are on your own (which means: use a framework which makes RPC possible, perhaps something from group I?)

V Server-side AJAX

Examples:

• VisualWebGUI

Profile:

• "dumb client, almighty-server", there's no "logic" on the client-side but rather messages passed to and from the server
• it is the server which holds the complete state of the application and the user interface and the client-side only renders it
• all client-side events are processed on the server
• this approach is the most resource demanding of all
• in the same time, it's most safe, since many typical internet attacks just don't work here (for example, Cross-site Request Forgery or ViewState Tamplering attacks are impossible).
• it's impossible to easily AJAX-enable existing ASP.NET applications with this approach

For an up-to-date list of .NET Ajax Frameworks, visit the AjaxProjects page.

Q: Any concise AJAX references?

A: If you need something really concise, "Teach Yourself Ajax in 10 Minutes" should be great. I can also recommend "Ajax Design Patterns".