Programming Microsoft ASP.NET 4 - Dino Esposito [5]
The View State
The view state is a dictionary that ASP.NET pages use to persist the state of their child controls across postbacks. The view state plays an essential role in the implementation of the postback model. No statefulness would be possible in ASP.NET without the view state.
Before ASP.NET, in classic, VBScript-based ASP, developers frequently used hidden fields to track critical values across two successive requests. This approach was necessary when multiple HTML forms were used in the page. Posting from one would, in fact, reset any values in the fields within the other. To make up for this behavior, the values to track were stored in a hidden field and employed to programmatically initialize fields during the rendering of the page.
The view state is just an engineered and extended version of this common trick. The view state is a unique (and encoded) hidden field that stores a dictionary of values for all controls in the (unique) form of an ASP.NET page.
By default, each page control saves its entire state—all of its property values—to the view state. In an average-sized page, the view state takes up a few dozen KBs of extra data. This data is downloaded to the client and uploaded to the server with every request for the page. However, it is never used (and should not be used) on the client. The size of the view state has been significantly reduced over the years, but today the view state is still perceived as something that has a heavy impact on bandwidth.
It is definitely possible to write pages that minimize the use of the view state for a shorter download, but the view state remains a fundamental piece of the ASP.NET Web Forms architecture. To eliminate the view state from ASP.NET, a significant redesign of the platform would be required.
ASP.NET 4 introduces new features that deliver to developers more control over the size of the view state without compromising any page functionality.
Server Controls
Server controls are central to the ASP.NET Web Forms model. The output of an ASP.NET page is defined using a mix of HTML literals and markup for ASP.NET server controls. A server control is a component with a public interface that can be configured using markup tags, child tags, and attributes. Each server control is characterized by a unique ID and is fully identified by that.
In the ASP.NET page markup, the difference between a server control and a plain HTML literal string is the presence of the runat attribute. Anything in the source devoid of the runat attribute is treated as literal HTML and is emitted to the output response stream as is. Anything flagged with the runat attribute is identified as a server control.
Server controls shield developers from the actual generation of HTML and JavaScript code. Programming a server control is as easy as setting properties on a reusable component. When processed, though, the server control emits HTML. In the end, programming server controls is a way of writing HTML markup without knowing much about its unique syntax and feature set.
Server controls consume view state information and implement postback events. In addition, server controls are responsible for producing markup and do that without strictly requiring strong HTML skills on your end.
Today’s Perceived Weaknesses
In the beginning of ASP.NET Web Forms, requiring very limited exposure to HTML and JavaScript was definitely a plus. However, the bold advent of AJAX in the middle of the past decade modified the perspective of Web applications and, more importantly, significantly changed user expectations of them. As a result, much more interaction and responsiveness are required.
To increase the degree of responsiveness of Web applications, you can increase the amount of script