AJAX and Atlas: An Overview of Two AJAX Implementations	2.5/5.0 (4 votes total) Rate: Select 1 - Terrible 2 - Poor 3 - Average 4 - Good 5 - Outstanding
Ben Reichelt April 20, 2006

One of the big buzzwords that rose to fame in 2005 was "Ajax." The term "Ajax" was first coined by Jesse James Garrett in his essay "Ajax: A New Approach to Web Applications" (www.adaptivepath.com/publications/essays/archives/000385.php), and it refers to the use of asynchronous JavaScript and XML to drive Web applications. Rather than reloading the entire Web page every time data needs to be transmitted, only small, necessary chunks are sent and received, with JavaScript manipulating the UI in response to the data received. This gives the look and feel of a regular client application while still being hosted inside of your Web browser. While Ajax methodologies have been used for years - most notably in Microsoft's Outlook Web Access - they have just recently become incredibly popular via services such Google's Gmail and Google Maps.

Since Ajax has taken off among Web developers, there have undoubtedly been many frameworks, APIs, and libraries to allow people to leverage Ajax with ease. I'd like to take a look at two of these Ajax packages for ASP.NET and show the differences and similarities of them. I will compare one of the earliest libraries available: Ajax.NET and Microsoft's ASP.NET 2.0 product, code-named Atlas.

As I started doing my research for this article, I wanted to make a grid in Excel that would compare these two products side by side, to see where they were similar and where the differed. I found out rather quickly (and against my assumptions) that they were really not as similar as I had thought. I had tinkered around with Ajax.NET last summer when it wasn't quite as mature as it has become, and I thought it was awesome. It made our Ajax development so much easier by hiding many of the tedious details involved. Since Ajax.NET worked so easily, I had assumed that Atlas would be implemented in much the same way, but boy was I wrong!

Ajax.NET is a simple installation. When you download the library, you get a .NET assembly and a Word document that describes how it works, known issues, etc. In order to use Ajax.NET you include a reference to the assembly, aptly named Ajax.dll, for each project or add the assembly to the GAC if you are going to be using it in many projects.

The way that Ajax.NET works is also rather simple. There are classes in the assembly that are Attributes designed to be placed on your server-side methods in ASP.NET, of which the most important Attribute is the "AjaxMethod." When you apply this Attribute to your methods, the Ajax.NET library will then mirror that method in your resulting JavaScript code on the client side. For instance, if you have a method with this signature "int Add(int x, int y)," and you decorate that with the AjaxMethod attribute, there will be a resulting JavaScript method on the client side called "Add(x, y)." This is really all you need to know in order to use this library to start making Ajax-enabled Web applications. The library contains the JavaScript necessary to communicate to the server to call the appropriate method on the server, and then when the call returns to the client-side page, it will execute a JavaScript callback method of your choice that contains the return value from the server-side method call. Getting up and running with the Ajax.NET library is incredibly easy - you can practically get it working by mistake.

An interesting side note about Ajax.NET is that it actually uses very little XML to work. Instead of returning XML to the client and then converting the XML into the appropriate object form, Ajax.NET uses the JavaScript Object Notation (JSON) to send the results to the browser. JSON is kind of like shorthand JavaScript - it's a syntax of JavaScript that allows you to dynamically define objects in your code. Ajax.NET simply returns a string as JSON code that gets run as a script on the client side, and presto! - you have your objects. The benefit of using JSON is that it needs no parsing or serializing on the client side because it's already in code form, and it can also be less cumbersome than XML, meaning the requests/responses can be that much more efficient. The only downside that I can see is that it makes your requests locked into a JavaScript implementation; that is, you can't easily call a Web service that returns JavaScript code from a C# windows application, but that's a small price to pay for practicality.

The Ajax.NET library was under some hot-and-heavy development late last summer and early fall. It was created by Michael Schwarz and he continued to improve it as the year went on, eventually adding support for special controls that would make use of Ajax, JavaScript namespaces, and a whole JavaScript client library that gives you much more power on the client side. One of the key features of Ajax.NET is its ability to return complex types from the server to the client-side code; rather than being limited to ints and strings, you can return built-in classes to the .NET framework like DataSets and Arrays, or even your own custom object types. This makes it extremely easy to transfer data to the client and leave the burden of rendering up to the browser. To change the filtering or paging of a list on your Web page, for instance, all you need to do is return an array of list items to the browser and it can loop over the items and write the appropriate HTML code. By having your custom objects on the client side, it allows you to program your JavaScript in a more object-oriented fashion, and it also allows you to leverage the code you've already written on the server side.

Therefore what the Ajax.NET library boils down to is that it exposes your server-side methods and objects to the browser so that you can use them in your JavaScript, and use them asynchronously to give your users a quicker, richer experience on your Web sites. It is a lightweight library with little barrier to entry, and as I've described above it's easy to install and integrate it into your applications.

Microsoft's Ajax product, code-named Atlas, is currently in pre-beta stages and the most recent release is the December CTP. Atlas is more than just a library that makes Ajax Web applications easier - it's really a framework that sits on top of ASP.NET 2.0 to provide built-in support for Ajax applications in ASP.NET. This is a key difference between Ajax.NET and Atlas: Atlas will only work in ASP.NET 2.0 because it leverages many of the changes that have been made, while Ajax.NET can be used in ASP.NET 1 or 2, because of its simplicity.

Atlas consists of server- and client-side components to en-able Web developers to add Ajax to their projects. These pieces all work together to make Atlas feel very much at home in ASP.NET. Since Atlas was introduced at this year's PDC conference in September it has already undergone significant improvement. I tried to use one of the starter kits soon after Atlas was announced, but I could not get it to work (this could certainly be a case of developer ignorance as well). More recently, I found a great sample Atlas application at Scott Guthrie's blog (http://weblogs.asp.net/scottgu/archive/2005/12/26/433997.aspx). The sample application that Scott has created is a simple to-do list application that tracks your tasks. The sample is actually pretty full featured with paged, sorted lists and inline item editing, with no page postbacks. What's even more impressive is that Scott claims to have written the app in 15 minutes on a plane! I highly recommend downloading Scott's sample if you are interested in playing around with Atlas - it's simple enough to comprehend and it shows the different kinds of functionality in Atlas.

The client-side component of Atlas has several JavaScript files that get included that provide base functionality for Atlas to run in your browser. There is a browser-compatibility layer to abstract the differences in browsers' JavaScript implementations. This ensures that Atlas users aren't restricted to Internet Explorer. Atlas currently works in IE, Firefox, and Safari. Another client script mimics the .NET Framework base class library with classes like "WebRequest" and "WebResponse," Atlas also comes with built-in UI functionality such as data-binding support, so you can bind the results of server calls to client side controls in much the same way you would in your ASP.NET codebehind. The goal of Atlas is to allow you to write your code in the same way, except that it will now run on the client instead of the browser.

Due to the tight integration with ASP.NET, you really won't need to type that much JavaScript code. Because Microsoft has built special server controls that you can drag and drop in the designer, a whole lot of the monotonous script code has been taken care of, and is usually abstracted even in the resulting HTML. If you download the sample app mentioned above and take a look at the HTML source of some of the pages, you'll see that there's really not much JavaScript code at all, save some typical __doPostbacks; still, Scott has managed to have Ajax-paging, Ajax-editing, and Ajax-filtering on his lists! The beauty of this is in the server controls working together with the client-side Atlas run time. If you do some digging (and it can be a lot of digging) you can locate a piece of Atlas code that does what many of us have done before, except that we always thought it was a hack; Atlas hijacks the __doPostBack JavaScript method. By overwriting the __doPostBack method, Atlas can intercept any control that would normally do a page post and instead posts the page asynchronously using Ajax; however, it can also retain all of the good stuff that ASP.NET needs to run on the server side, such as event targets and event arguments.

A key ingredient to Atlas working so well is the addition of the ScriptManager and UpdatePanel server controls.

The ScriptManager control is a pretty smart control. It will detect that a page is using Atlas and will override the page's HTML rendering. Instead of rendering the entire page in response to an Atlas call, the ScriptManager will send only the HTML that corresponds to what needs to change on the page. This leads us to the UpdatePanel control. UpdatePanels are used in the HTML markup to separate areas of the page that can be dynamically updated in isolation. The ScriptManager knows which UpdatePanel of the page should be updated and only gets that HTML, rather than the whole page. When that HTML is received on the client side, the HTML is inserted into the UpdatePanel using JavaScript. So instead of passing complex data types to the client for processing, as Ajax.NET does, Atlas does all of the processing on the server side and still renders HTML - just not complete HTML pages - and then lets the client code determine where to put the partial HTML.

Ajax.NET and Atlas are both viable solutions for adding Ajax functionality to your Web applications - you just need to pick the right tool for the job. If you are creating a new Web application using ASP.NET 2.0 and it's not going to be released for a while, maybe you can use Atlas and the seamless integration with ASP.NET 2.0. Suppose you have an existing ASP.NET Web site and you want to incorporate some little Ajax widgets here and there. In that case you would certainly want to consider using Ajax.NET because it is lightweight and works with .NET 1.1. I personally like the fact that I can bolt Ajax.NET onto just about anything very quickly and with little fuss, whereas with Atlas you get the feeling that once you start using it you're kind of locked into the Atlas world because of how it takes over the client-side code.