Why using jQuery for AJAX calls before the Ajax Control Toolkit

Every starting developer in ASP.NET who wanted to integrate AJAX functionality in his web application first started with the Ajax Control Toolkit. It’s easy to understand, in Web Forms it’s almost not more than a drag and drop implementation.

After a while you start to notice the limitations. You want to create a functionality that’s not integrated in the toolkit. You start with extending methods, extending properties and get stuck every time again. The amount of update panels start to grow above your head and on every postback you’re have to test if the postback is a Ajax post back or not. In your UI you start to see some disadvantages, the focus is lost when a update panel is updated, you’re page jumps back to the top and so one.

One of the most disturbing issues I found was the load from and to the server. For a simple update of a textbox, the whole content of the update panel is send in the background to update your page. In the first screenshot you see a (very) simple example. The value typed into the textbox has to be added to the list underneath without submitting the page. After creating the update panel and added a script manager we implemented the async postback.

The only thing we needed back from the server is the ID of the value entered and the value itself (although that isn’t needed to make a round trip) I we check the Console or Net tab in Firbug we see the response:

1|#||4|471|updatePanel|UpdatePanel1| <span id="lblFirstName">Bart</span><br /> <span id="lblLastName">De Meyer</span><br /> <span id="Label1">Ticket</span><br /> <input name="txtTicket" type="text" id="txtTicket" /><br /> <input type="submit" name="btnSave" value="Save" id="btnSave" /><br /> <select size="4" name="lstTickets" id="lstTickets">     <option value="1">aaaa</option> </select> |148|hiddenField|__VIEWSTATE|/wEPDwUJNTU0OTM3MDUxD2QWAgIDD2QWAgI DD2QWAmYPZBYCAgsPEA8WAh4LXyFEYXRhQm91bm RnZBAVAQRhYWFhFQEBMRQrAwFn ZGRkfXCqCy7IiEyl+lHROA5vfn1oYNq3t8MhnzZlEt DTPXA=|80|hiddenField |__EVENTVALIDATION|/wEWBALF19m3BALEsPqoBgKct7iSDAKjn6ufDly+66xedWvvj /fQnBQjlOsBTWNL9UuTy1VDVvKmkOGe |15|asyncPostBackControlIDs|| btnSave,btnSave|0|postBackControlIDs|||26|updatePanelIDs||  tUpdatePanel1,UpdatePanel1|0| childUpdatePanelIDs|||25| panelsToRefreshIDs|| UpdatePanel1,UpdatePanel1|2| asyncPostBackTimeout||90|16|formAction||UpdatePanel.aspx| 

A 1024 character response, including all controls that are in the update panel.

For test, I’ve implemented the same functionality with an Ajax call with jQuery. Check the response:

{"d":{"__type":"Webform.Object.Ticket","TickedId":3,"TicketName":"aaaa"}} 

A 73 character response, only containing the values we needed: the id of the value entered and the value entered

As you can see in this (very) simple example, the difference between the implementing a async callback with the toolkit and jQuery gives us an advantage of 951 characters. You can imagine what the difference would be in a page with let’s say 50 controls on their.

For simple Ajax functionality the toolkit is an excellent choice for a beginning developer. A developer who doesn’t want to know what’s going on in the background. He updates a drop down list and the correct value appears in the textbox underneath. What triggered it and how it’s used, he (or she) doesn’t care. They still maintain and renew the toolkit as you can see on Stephen Walter’s blog.

I do care. I’m one of those guys who want to know what’s going on in the background, so I can extend functionality, create my own controls and so one. And I do care about the traffic I generate.

One thought on “Why using jQuery for AJAX calls before the Ajax Control Toolkit

Leave a Reply

Your email address will not be published. Required fields are marked *