If you're doing AJAX callbacks to the server with POST data from ASP.NET pages you might be inclined to do something like this:

var post = $("#form1").serialize();
$.post("MethodCallback.aspx?Callback=ListPanel",
        post, 
        function(result) { alert(result) });

This works fine, but it will pick up all of your ViewState and EventValidation making the post back to the server a heck of a lot bigger than it should be especially if you have a page where ViewState is heavily used. Now I tend to turn off ViewState on most of my pages but you still get at least some ViewState and EventValidation content on the page and in most Ajax scenarios sending that to the server is just wasted bandwidth.

Fortunately it's quite easy to exclude ViewState et al. with code like this:

var res = $("#form1")
                .find("input,textarea,select,hidden")
                .not("#__VIEWSTATE,#__EVENTVALIDATION")
                .serialize();


$.post("MethodCallback.aspx?Callback=ListPanel",
       res, 
       function(result) { alert(result) });

This is a little more verbose, but necessary in order to be able to individually reference each of the child input elements. The #Form1 selector is optional - if you only have a single form or if you don't care about posting all form vars regardless of belonging form, you can just request all input,select,textarea,select and hidden elements.

The .not() function basically filters the result set of input elements and so doesn't send up ViewState and Event validation. If you do this a lot a small generic plug-in might be useful:

$.fn.serializeNoViewState = function()
{
    return this.find("input,textarea,select,hidden")
               .not("[type=hidden][name^=__]")
               .serialize();    
}

which then allows you to do:

var res = $("#form1").serializeNoViewState();

or even the following to select data from all forms:

var res = $().serializeNoViewState();

Reducing ViewState and avoiding it from being sent back and forth between client and server can drastically improve AJAX performance so it's a good idea to be conscious of what goes over the wire on those presumably 'small' AJAX requests. Removing it from the client POST is one quick way to reduce bandwidth.

Note that if you plan on having the page actually go through a normal 'Postback' like stage and you want to capture events during an AJAX callback you can also post back ViewState et al and this can in many cases work, giving you access to POST data on form fields (ie. referencing like this.txtName.Text rather than explicitly calling Request.Form[]). But it's best not to rely on this mechanism as there are lots of little quirks and gotchas. Ajax callbacks are best handled as independently as possible - preferably not back to the same page or a service to avoid any conflicts with ViewState and EventValidation. Otherwise turning ViewState and EventValidation off will help prevent page errors on callbacks or a full Postback following many AJAX updates. This is no trivial matter so you have to understand what's being updated on the client and what will actually make it back to the server (other than form fields). This is why it's best to minimize reliance on Viewstate so that Viewstate corruption and EventValidation won't be a problem.

Encoding POST data via Object Maps

Since we're talking about jQuery POST data encoding - note that you can also use the $.params() function to turn any flat object map into POST data. So you can easily create POST data like this:

var post = { name: "Rick",
    company: "West Wind",
    lastOn: new Date(),
    count: 30
};

$.post("MethodCallback.aspx?CallbackHandle=ListUpdate",
        post,
        function(result) { alert(result) });

which in turn turns all the map values - name, company, lastOn, count - into POST variables that are sent to the server URL encoded. Most places where a 'data' parameter is expected with POST data in jQuery you can either pass a string (as in the first examples above) or an object map as shown here. This is a nice and easy way to create POST data without having to manually worry about POST encoding it.

Behind the scenes jQuery uses the static $.param(data) function which also provides this functionality to your code and lets you turn any object map into a POST string explicitly.

var post = { name: "Rick", email: "rick@morecowbell.com" };

var poststring = $.param(post);

Very useful if you're interacting with REST based applications that work purely on POST data rather than JSON encoded content.

Lots of flexibilty there and it's easy to integrate with ASP.NET.