ViewSate is page  specific, that's all I can can dream up.
If its page specific then it "probably" uses less of everything and seems somehow seems more temporary and self destroying.

Bit thats just an inner feeling I have, don't quote me !

P.S. I learned everthing I know from the PetShop app which has got it all. If anyones interested I extended it so that "components" can be added by the user from their accounts. It wasn't easy - when you start adding functionality like that you end up having to rewrite lots and lots and lots. The cart itself has to be rewritten quite a lit - to make it todays independant of everything else - so it could be imported. See http://www.aspnetcart.com - I'm going to integrate and reface it with http://cardiffwebdesign.com - maybe I can get a job after that.
Soz to blow my own trumpet but I did good (!) and noones even seen any of it yet - let alone given me a site/job/contract

ViewState is basically encrypted and incorporated as part of 1 hidden field. IT is nothing like a session variable.

The viewstate  of all controls on page  and your own viewstate gets all combined into one hidden field and packed/unpacked transparently.

Look at:
www.learnasp.com/.../pageeventmodel.aspx

Now run the page, i.e.
www.learnasp.com/.../textbox.aspx
several times and enter values and push the buttons. Notice how it always remembers the 3 textbox entries. It could remember the contents of any runat="server" controls, inside form runat="server" tags and anything you manually add to Viewstate.

View the HTML source. Notice the =>
input type="hidden" name="__VIEWSTATE" value="dDwtNDE...">
is how this moves around.

Unlike session state which lives on a server  and consumes memory ViewState is just a HTML hidden field. You could have the browser open and push that button 3 days later and that hidden field mould still do its job with no cost in server RAM.

Excellent Charles the example on www.learnasp.com where brilliant, there is a lot of stuff there...

So it is recommended that one uses viewstate  where one needs to store public variables during postback.

Are there any bugs with viewstate?

I know its a bit  late now to say that I did know that but I forgot because I have been doing a C++ shell utility for the last 3 months - but its true.
That was the knowledge I had in my mind when I was doing my cart - ages ago - I discovered ViewState properly after that. But ViewState may be client side but from what I can remember it appears, from practical point of view, to act like a page  specific session var (excluding the cache).
Well thats how I used to think of it and it seemed to work.

I'm gonna take another look at that first stuff (and some recent stuff) I was doing, I have a feeling it may solve some of my Page_Load, Page_PreRender dilemmas. i'm afraid I have been avoiding ViewState in the latest stuff I've been up to - and doing it all in Page_Load, and Pre_Render (uneccessarily I suspect - though probably a bit cleaner - keeping ViewState clear and relying purely on server  code for it's functionality has got to be a sound idea - do you reckon ????)

Here's a question .... how is it that with asp.NET when you do a postback the page seems to hold on and then deliever it all in one go.
I like it, it's cool - but why is that ? I'd have thought it would be something to do flush etc, but I don't know, is it ?