Ken Egozi reminded me that my issue is not with ASP.Net itself, but rather with the WebForms implementation. As someone who had done quite a bit of work with the internals of ASP.Net, I have nothing but respect to the way it is architected and impelmented, This is truly a really great platform. (Except the entire System.Web.Cache API, which is completely internal, and therefor very bad in my eyes).

Update: I forgot to mention another point about Ken's post/comment. He suggested a view engine in C# / VB.Net. Unfortantely, this is not easily possible. To be a little more correct, it is not possible without a lot of really hard work. Neither language is extensible in any meaningful way, which would lead to building a view engine that it mainly parsing strings to create the object model. Possible, certainly. This is what aspx pages are, after all, but not fun to do at all.

Ben Scheirman commented on my post with some interesting observations.

About encouraging postbacks:

I have issues with technologies where I have the easy-way and the real-world-way approaches. I don't want to benefit from friendly URL and have to do something to enable the back-button. Both of them are core parts of the web. It should be painful to not use them, not the other way around.

About view state bloat, complexity, MIA, etc:

The problem here is that the ViewState model encourages its use (and its bloat), an ASP.Net page may be composed from several hundreds of controls, and each of them has at least several properties in the ViewState, mostly those are completely not needed. "Page State" is not what the name of the columns in the grid was, but that get saved as well, for example.

ViewState itself is a very good idea, actually. I can certainly see a generic way of persisting data as a valuable assest, the problem with this is what I define as data, and worse, that the moment you start using it you are limited to the postback model, see the point above for details.

Actually, I have been known to say more than once that I would just as soon do it in ASP classic, since it would be so much simpler to understand what is going on and the #%@# page wouldn't decide to make to move the data from one control to another randomaly. ASP Classic had a lot of issues with the way it is implemented, yes, but as far as the model that you are working with in the real one. ( I am assuming that you kept the COM for BAL and ASP for UI, of course, which no one did. )

I commented on making simple things complex and on the MCP exam today. Well, here is the (correct) answer on how to get the data from a text box inside a grid: