ASP.NET Ajax passes the viewstate to the server and back during things like UpdatePanel updates. This is done to insure that the viewstate is always up to date, even if the page information changes during the Ajax call. Many Ajax calls, however, don’t require any changes to viewstate. Unfortunately, when the viewstate comes back, I’ve found many unpredictable results – things like page titles changing and breaks in back-button functionality in some scenarios. More importantly, these bugs are hard to track down and understand, in my experience. On top of this, viewstate is usually pretty large, which slows down ASP.NET Ajax requests and transfers more data across the wire, increasing bandwidth costs.

What have I chosen to do instead? Through Encosia, I’ve found that it’s fairly trivial to make jQuery Ajax calls into the codebehind, or even to local web services via JSON. These calls are small (they don’t send viewstate), transparent (they don’t change page information on return unless you explicitly ask to), cross-browser compatible, and rock-solid (like everything in jQuery).

Surely there are quite a few circumstances where ASP.NET Ajax beats out jQuery Ajax (for things like datagrid population, for example). From now on, though, I’ve decided that my default stance will be to write my Ajax calls in jQuery unless I can create a compelling case to do so in another technology.