My Portal Project

With our application go-live scheduled for this Monday, I am entering a retrospective mood on everything that we have accomplished, and the hurdles that hurt us. Although scope-creep is always the most painful hurdle, I would place the implementation model of Microsoft’s AJAX.NET as a solid second place pain in my butt.

With AJAX technologies in general, the motivations were speed, usability, and bandwidth, so when MS implemented their AJAX model, what did they focus on? Ease of use for the developer. They made their technology easy for the developer to implement but completely ignored the core motivations behind the AJAX movement.

At the very core of AJAX.NET problem is this simple fact: There is little fundamental difference between a complete ASP.NET page postback, and an AJAX UpdatePanel “partial” page postback. When you trigger an AJAX UpdatePanel, the entire ViewState of the page is sent to the server, then the Page_Init event fires, then the Page_Load event fires, and then the method that is attached to the panel is fired, and then the entire ViewState is passed back to the client, along with the necessary javascript to update the page. Even worse, if the UpdatePanel is in a Webpart within a Master Page, the entire Master Page event chain fires.

What happened to the idea of sending/receiving only what you need to/from the server? If you have any database calls in the page_init/page_load (i.e. authentication information) then the overhead of the DB call is suffered for every “partial” page postback. Although there are definitely ways to differentiate between a postback and an asynchronous postback, in the scenario where you may be building server controls on the fly (in the page_init, or page_load events), this code MUST execute everytime there is a postback.

One issue that plagued me for a week was when I was attempting to perform a partial page postback using a hidden field value-change event as a trigger for the AJAX UpdatePanel. I was getting the generic “Value does not fall within specified range” error before any of my code was even being executed. It was only by the grace of Firebug that I was able to realize that the error was being generated by a MS javascript file that was relying on a hidden field value that did not exist. What was supposed to generate this hidden field? I gave up trying to find out, and did things a different way. There is simply too much hidden voodoo for my taste.

So I have come full circle on the MS Ajax technology. In my next project, I will go back to the open-source Javascript Library approach to partial page rendering. The Benefit application we rolled out in November used the YAHOO library for all its AJAX needs, and I was therefore able to place all of my AJAX endpoints into one ASPX page that had no UI elements; just POST strings and XML/JSON output. The result was full control and customization of the communication and rendering at every level of the process.

Some additional reading on the topic:

UpdatePanel Tips and Tricks by Jeff Prosise
Perspectives on ASP.NET AJAX By Dino Esposito

This entry was posted on Friday, June 22nd, 2007 at 8:28 am and is filed under Microsoft, ASP.NET, LinkedIn. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.