View State improvements, pros and cons ;)

Advantage of ViewState:
There is one important place where view state is used, and that is in controls that issue server-side change events. If the user changes the value in a textbox or switches the selected element in a dropdown list, you can register an event handler and have code execute when the event is raised. These controls compare the current value of the control with its previous value, which is stored implicitly in view state if any process has subscribed to the change event. If you disable view state on a control whose change notification event you are handling, it won't fire correctly since it must always assume that the previous value was the same as the default value in the form.

View State Problems in 1.1:
As described earlier, the dropdown list and the textbox controls use view state to store the previous value to properly issue a change notification event on the server.
Similarly, the DataGrid class uses view state to issue pagination, edit, and sorting events.
Unfortunately, if you want to use features like sorting, paging, or editing in the DataGrid, you
cannot disable its view state. This all-or-nothing mentality of server-side controls with respect to view state is one of the most frustrating aspects of the server-side control model in ASP.NET 1.x for developers who are trying to build fast, efficient sites.

View State Improvements in ASP.NET 2.0

The first one is the overall size of view state when it is serialized. In ASP.NET 1.x the
serialization of two strings into the view state buffer looks like this:
<_p<_l<_string1;>;_l<_string2;>>;>; [Plz ignore _]

The serialization format used in ASP.NET 1.x for view state is a tuple format consisting of a
hierarchical collection of triplets and pairs serialized using less-than and greater-than
characters. The letter preceding the greater-than symbol indicates the type of the object stored (t=triplet, p=pair, i=integer, l=ArrayList, and so on). Each subelement within the less-than and
greater-than characters is separated with a semicolon. It's an interesting serialization format,
sort of like a compressed XML. If you're concerned with space, however, it is not the most efficient serialization format (only marginally better than XML).

ASP.NET 2.0 changes this serialization format. The serialization of the same two strings into the view state buffer in ASP.NET 2.0 is shown in the following line of code:

[][]string1[]string2

At least that's what it looks like when rendered to a browser. The square boxes are actually
nonprintable characters which, if we rewrite using Unicode character references, turn into the code shown here:
string1string2

Instead of using a collection of printable characters to delineate objects in the view state stream ('<', '>', ';', 'l', 'i', 'p' and so on), ASP.NET 2.0 uses a number of nonprintable characters to
mark the beginning of an object and to describe what type of object it is.

.net 2.0 viewstate advantages
Using nonprintable characters to delineate the objects stored in view state serves two purposes.
First, it improves the efficiency of the lexical analysis during the parsing of the view state
string since there is no longer any need to match characters or parse tokens.
Second, and more importantly, it reduces the number of characters used to encode the objects in view state. In my simple example of encoding two strings, the first encoding used 16 delineation characters versus 3 in the 2.0 format. This effect quickly compounds to make a significant impact.