Beware of Client Callbacks in ASP.NET

The built-in AJAX feature of ASP.NET 2.0, also known as Client Callback, is simple to utilize but a beauty in disguise. I’m not talking about the “Atlas” toolkit for ASP.NET but the ICallbackEventHandler interface that allows you to make asynchronous requests to server-side methods. It starts out being efficient and easy to use, but in the end of the website project, it will be slow and inflexible.

HTTP requests

If you trace the HTTP traffic of a Client Callback request, you will find that it sends way more than you need. I have a form that sends an asynchronous request whenever you check or uncheck a checkbox control. I would expect it to send the ID of the control and the value I give it, but actually it sends much, much more than that. To begin with, it sends the entire ViewState which could be huge. It also sends the value of many more controls than just the one I need. For the checkbox control that amounts to 10k.

POST vs. GET

It’s not a problem that it sends all the data, but it is impossible to turn it off and that’s a problem. Not only that, but the Client Callback feature only uses HTTP POST and that is slower than GET. There is no real practical reason to send POST requests – not for the developer’s side anyway – and it adds to the overhead.

All this simplicity (read overhead) is not worth it when you think of the alternatives. You could use Atlas instead or doing it manually with JavaScript and an HttpHandler. I prefer to do it manually or by a JavaScript framework like Prototype. In the case of the JavaScript framework, you still need the HttpHandler but the flexibility and performance is significantly better.

ActiveX vs. native

Another thing about the asynchronous request is that it does check for the ActiveX component before the native XmlHttpReqests object of the browser. That makes it slower in any other browser than IE6. If you do it manually, you can do it the other way around and gain performance that way as well. At the end of the day, there is not much fact talking in the favor the the Client Callback feature other than simplicity.

My experiences with the ICallbackEventHandler interface have made me turn to the alternatives. Even though ASP.NET is so easy in a lot of ways it is still important to know when things get too easy like in the case of Client Callbacks.