View State Slaughter

Killing view state is one of my favorite subjects to talk about. It is so because view state can either make you, or break you. Well, not you. Your application, that is. It's so easy to abuse it and overlook consequences—it's not even funny.

We've had a planned week or so of hunting down unnecessary view state. We use a lot of dynamically instantiated controls which makes matters much more complicated (and pages bloated), but we have to.

For me it boils down to putting every control under microscope and checking if it should have view state enabled and if not, whether it can leave with EnableViewState="false". I even tend to move control initialization into page's Init event even if I have to ping the database to fill them in. Why Init? Scott Mitchell covered this nicely.

To me it's also a question of whose responsibility it is to pay for view state. I do mean the word pay here, because bandwidth costs money. It also "costs" download time. It also "costs" responsiveness of your application.

There's one control that seriously complicates efforts of reducing view state: the DataGrid control. Yep, this good ol', helpful Swiss army-type control. I dare to say it was written so poorly that these days I prefer not to touch it because I can't get much view state reduction out of it.

For one, disabling view state on a pageable and sortable DataGrid is nearly impossible. There are articles out there, and if you illustrate it for a particular case of one sample DataGrid it's all nice and dandy, but in real life it translates into a lot of pain in the butt. All the auxiliary code that makes paging and sorting tick on this kind of a grid is not worth the effort. This leaves us with a control that:

1. Produces awful markup;
2. Bloats view state.

Having gone through a couple of rounds of view state trimming I'd like to say this:

It should become a norm for each diligent developer to move view state out of his/her pages. Where to? Database, for example. I do believe that storing view state in the database, in most cases, leads to much better response times (see my article on view state).

Why's that? Because our technical decisions should not be imposed on users. They shouldn't be suffering it.

Remembet that every little postback drags view state to your server and then back to the client. Abuse this and you'll have some very unhappy users.

Learn DOM

Another thing I learned from all this is: learn JavaScript, learn DOM. I refuse to employ Microsoft's and Nestcape's proprietary document object model tweaks, as well as IE filters and behaviors. No wonder we don't have validation controls working properly thanks to Microsoft's DOM. It just won't cut it any more. Stick to W3C DOM. Pick up a copy of Joe Marini's Document Object Model for starters.

Ancient browsers don't support DOM scripting (let's not talk about Lynx just yet, this is a subject for another post). If you happen to read this in Internet Explorer 4 or Netscape Navigator 4.7 you gotta crawl from underneath your rock and go get yourself a decent browser (Firefox, anyone?).

What's the connection between DOM and view state? If you rely more on scripting you can cut back on postbacks and shave off view state. I'd much rather have a grid I can sort on the client than on the server. Unfortunately, this is not how "stock" ASP.NET server controls are written right now.

What about unfortunate ones who disable JavaScript? I hate to say it but you're plain out of luck. You can't use ASP.NET apps without cookies (they help with session management) and JavaScript (validation, all sorts of postbacks). I mean, technically you can, but in practical terms you wouldn't.

Conclusion

Watch out for view state. Question it. Learn W3C document object model. Shave off postbacks. They suck. Big time.

I totally agree in some ways the .Net framework makes certain tasks almost too easy that developers don't realise the true cost of the task. A good example of viewState going wrong is GotDotNet - when paging the projects the viewState is MASSIVE as it contains the selected projects details but all the postbacks alter the selected projects so viewState is completle unnessarry.

I gave up on GotDotNet workspaces because they are collapsing under their own weight. Even on a cable modem connection they are too slow to sit around and wait.

I turned of viewState on my Page but it still remains in html that comes from the server (only a few bites). Milan, I noticed on your page that you don't have not a single bite of viewState in your code. How is this made???

Sorry Milan. I didn't look good enough on your page and I didn't read your previus article before. Now I did and know that some bites of viewState remain always.