Welcome to my comparison of AJAX frameworks for ASP.NET

• ComfortASP.NET V0.65 (beta)
• MagicAJAX.NET V0.3.0
• ZumiPage V2.10
• ATLAS CTP July 2006
• OutPost V1.4
• FastPage V2.0
• Telerik r.a.d. ajax V1.03 (+Hotfix)
• Anthem Panel V1.3.2

• Anthem Panel added
• OutPost updated
• "Steps/Code required for Integration" added 
• Some minor fixes

First, let me explain why only these Frameworks are included although there is a lot more AJAX stuff for ASP.NET out there. All the frameworks listed here have one unique AJAX feature: They allow updating page content without programming AJAX directly - i call it indirect AJAX programming - a compareable concept is called Hijax. To make it concrete: Direct AJAX programming would mean dealing with client scripts, DHTML, method proxies, client side rendering and so on... Another important property the framework must have is the ability to support non-AJAX controls and enhance them with AJAX features. Therefore, frameworks that supply only controls with built in AJAX-features (Buttons, Trees, Grids, Lists and so on...) are not included in the comparison. Please drop me a note if I forgot a framework that also allows indirect AJAX programming.
This is the first step of a comparison that may be extended in the future - depending on the feedback I'll get. Many thanks goes to the people that already gave me feedback!

Please notice that the investigated features are really not all of the interesting things these frameworks can do. The main criteria for the comparison were the features that can be compared to those that come with the ComfortASP.NET framework.

Some general words about indirect AJAX programming:
What are the possible concepts to get to that goal?
I personally found 2 main concepts how indirect AJAX programming could be done.

The first concept is the page based concept. The idea with this concept is to transport all page content to the client to display a 1:1 equal page as it would have been without AJAX. One challange of this concept is the support of client scripts that must always be refreshed as the whole page content is updated (and therefore resetted like in real ASP.NET) with every AJAX postback. It follows the rule: "there is no persistent client state between postbacks" - that's really a big difference to direct AJAX programming. I personally think that keeping application state away from the client in an ASP.NET application is a good thing.
Another challange with the page based concept is to reduce the size of the response. No one wants the HTML of the whole Page being sent in an AJAX response. The idea to solve this issue is to transfer only differences to the previous request in a consecutive response. This must be performed by the framework automatically to make any sense and so providing nearly the same benefits to the users as in direct AJAX programming.

The second concept is the control based concept. The idea is to transfer and update only the content of the changed controls of the page. The benefit is, that the resulting page is updated partially and the client can keep the static areas of the page untouched. ComfortASP calls this concept "selective update" - in ATLAS it is called "partial update". OK, that sounds simple - but - how can I tell the framework which controls I want to update? Here comes the differences between the frameworks. One way is to "mark" other controls via a container control (typically a Panel control) for AJAX. This seems to be a common way to integrate indirect AJAX programming, because most of the frameworks support this concept. Another way is to "register" the controls (in code behind) for an update (ZumiPage does that) without any special container control. The third way is to directly render the HTML stream of the desired Controls into the response stream of the AJAX framework (ComponentArt Callback Control goes this way) by writing the required code.
I personally have already developed a customer specific AJAX framework (it's not available for the public) that does a fourth way of "telling" the framework which controls should be rendered - it has an automatic control change detection mechanism, that supports different detection strategies.

I really tested all of the compared features you see below, but I am not an expert for each single framework so I can't take a 100% liabilities for the correctness of results you see here. If you find any incorrect statments, please contact me and I will correct it as soon as possible. Please attach a reference to the source of your information or any code that confirms your statement. If you have further suggestions for improving this comparison, just drop me a note.

Comparison of frameworks that support full Indirect AJAX programming:

<configuration>
 <system.web>
  <httpHandlers>
   <add verb="POST,GET" path="default.aspx" type="{Framework assembly}"/>
  </httpHandlers>
  <httpModules>
   <add name="ModuleName" type="{Framework assembly}"/>
  </httpModules>
 </system.web>
<configuration>

2) Some frameworks allow additional configuration of features in individual web.config sections. This allows you to control certain (mostly global) features without code changes.

3) The "Hello World" example (see chapter transfer sizes for source) is a simple web page that displays the server date in a label field after a button was pressed:



4) Some frameworks offer a manager control (or something similar) to provide designer and runtime control over specific features.

5) Not all of your clients may be able to use your AJAX features. For example if the browser simply doesn't support them. So it may become important to be able to downgrade to pure ASP.NET.

6) The frameworks compared here allow indirect AJAX programming. For ASP.NET it is important to handle the ViewState correctly, even in an AJAX request to be able to keep the current Server Side programming model without too many code changes.

8) Turning AJAX on and off at design time is an important feature to help you finding bugs and AJAX problems. You can easily compare the content update with and without AJAX.

9) Turning AJAX on and off in any of your event handlers in server code.

10) Very often dynamic HTTP responses are uncompressed and transferred in plain text. Compression can save you in an average up to 75% of your HTML traffic, but it also produces a higher CPU load on your web server.

11) Updating scripts may become a big issue. Even for developers that focus on pure server side ASP.NET development. In many cases you have content that is generated by 3rd party controls that you cannot directly influence. And many of these controls are using client scripts to enhance the user experience. Although if your AJAX framework supports script execution you do not have a guarantee that all of the controls that utilize scripting will run without issues after an AJAX postback.

12) Automatically transferring only changes of the HTML content between two AJAX responses can save a lot of additional traffic but also produces a significant higher CPU load on your web server for the diff-calculation.

Transfer sizes of the "Hello World" example with ASP.NET 2.0.