Scott Hanselman

ASP.NET ViewState: Pox on mankind? Or clever like a fox?

February 24, 2004 Comment on this post [3] Posted in ASP.NET | Javascript | ViewState | HttpModule
Sponsored By

A good friend of mine (who may or may not reveal himself by trackbacking this post) emailed me recently, with reference to my post on ASP.NET ViewState. 

He had some interesting opinions, so here are some choice snippets reprinted with this permission, with my commentary interlaced:

IMHO viewstate is the second worst piece of the .NET Framework. The worst being "javascript:do_postback" instead of providing clean, lean and mean URLs. Oh wait, they are related -- the latter is the necesary workaround for the former.

I think it's actually damned clever, and quite possibly neccesary.  The HTTP/HTML combination needed an eventing subsystem built on top of it.  DoPostback() does just that with support for Event Targets and Event Arguments.  It's simple, supported, and clean.  POSTing data (rather than GETting) is needed, nay, required to move stuff from place to place on browser-based web.  I certainly can't be putting on this crap in my URLs, can I?  Believe me, I'm all about REST, and I believe the REAL answer lies in both POSTs, and well designed URI/Ls.

Viewstate is bad because I can't set a bookmark to it. Instead of using viewstate, developers who want to create great webapps should pass a querystring parameter for read-only operations. The whole concept of doPostback should be abandoned altogether and developers should instead look up the original HTTP specification which details the ramification of GET vs. POST.

Phooey! :)  Viewstate was needed to allow things like listboxes to POST not just their currently selected item, but also ALL the other items.  Otherwise, how do I reconsitute my listbox on the next go-around?  Better I pay a few BASE64'ed bytes on the roundtrip than head back to the database.

ViewState was just a state bag, and as Brad notes in the comments of the previous post, it can be "normalized" away with a key (I wonder if they are hearing this and will hook it up to ASP.NET Session State in Whidbey?)

Whenever a certain resource is only addressed (and not changed in any way, i.e. whenever the underlying operation is safe), GET should be used so that you allow the user to have a uniform resource locator for this very thing. Just imagine, google.com would use viewstate and such ... you wouldn't be able to address the query for "Scott Hanselman" as http://www.google.com/search?q=%22scott%20hanselman%22. Or the second page on this query as http://www.google.com/search?q=%22scott+hanselman%22&num=100&hl=en&lr=&ie=UTF-8&start=100&sa=N. Now, that would be bad.

Now this I totally agree with.  GETs and "hackable URLs" are totally appropriate for an operation like this.  But for a form that includes my credit card info and full address, not so.  Then add in dropdowns and database-backed grids, then maybe a few buttons...aren't you wishing you had an eventing subsystem and a way to reconstitute your controls? ;)

Second reason for why this whole thing (especially javascript:dopostback) is bad: It doesn't allow me to "Open in new window". I use a tabbed browser and regularily open links in new windows. I find more and more sites which just use ASP.NET and don't handcode their URLs anymore leading to "forced-single-window-navigation."

True, I hate that also.  But, to be clear, my mom, and most folks on the web, don't care.

 But let's get back to the topic: the creation of viewstate and the associated necessity for doPostback instead of <a href=""> have created a bunch of non-standard, non-userfriendly web applications.

Unfriendly is up for debate, but non-standard?  I don't think so.  Last time I checked I had ASP.NET sites up running on 15 different browser variants using doPostback happily and transparently.  If there's a better way that will still give me:

  • Server-side Events (onclick, onchange, etc)
  • Reconstitutes the state of my controls without requiring a call back to the datastore.

Then I'll be the first to code the HttpModules or whatever's required to make it happen.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook bluesky subscribe
About   Newsletter
Hosting By
Hosted on Linux using .NET in an Azure App Service
February 24, 2004 21:32
I must respectfully disagree, and in my sleep-deprived state I couldn't refine my comments to fit here :(. Full comments at:

http://www.tallent.us/CommentView.aspx?guid=b0f05e47-0b41-4ef2-8c5f-41ccc1f4cb86
February 24, 2004 22:36
During the development of some web aps during the last couple of years I've found that it's often more efficient to do that dreadful "go back to the data store" ("oh nooo" can be heard from the ones that have not yet performance tested the options, nor tested scalability), than to poke around with the ViewState. It seems as the web server has to do a lot of intense processor work to handle to ViewState and the approach of getting several tables (the ones needed by the "filler DataSet") back from the datastore using one sp often gives me better throughput. So even though ViewState is really useful; storing some data that the user has provided during a wizard; sure, but the ability to "ask" a dropdown of its data is, in my opinion, not the way to go.

"Better I pay a few BASE64'ed bytes on the roundtrip than head back to the database."

Remember you're not just paying for the bytes sent – that's the least you have to worry about.

BTW, I enjoy your blog!
February 24, 2004 23:01
I think the arguement boils down to practical pragmatism and the context of the use of viewstate. For business focused developers who are writing relatively small simple applications to provide some extension to the functionality of existing applications - in organizations like mine where at least half the users probably don't know that they CAN right-click to open a browser in a new tab/window - viewstate and the whole eventing system adds a lot of value for letting us quickly develop apps with a lot of functionality. ASP.NET handles all the wiring behind the scenes very well.

On the comment about performance, I know that Daniel is correct. But I also know that for most applications that most developers write, scalability is NOT an issue. Not that people shouldn't understand and know the facts, but very often it is not worth the time and effort to get every millisecond out of an app - so the price of viewstate vs. the price of database access is irrelevant. Most developers, as long as they write reasonable code, don't have to worry about this. (Remember, this is a general comment that applies to 90% of the applications written, and assumes that people are being truely stupid - there is clearly a need to be concerned about these things sometimes.)

Anyway, I am really glad that ASP.NET has the whole eventing model of viewstate and do_postpack(). Clearly there are times to avoid it, but it is a productivity boon for most developers for most applications in most situations.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.