What’s Wrong with ASP.NET Web Forms?

What a great description of all the deficiencies of ASP.NET Web Forms! The following is an excerpt from Pro ASP.NET MVC 3 Framework by Adam Freeman and Steven Sanderson (Apress).

What’s Wrong with ASP.NET Web Forms?
Traditional ASP.NET Web Forms development was a great idea, but reality proved more complicated.
Over time, the use of Web Forms in real-world projects highlighted some shortcomings:
•  View State weight: The actual mechanism for maintaining state across requests
(known as View State) results in large blocks of data being transferred between the
client and server. This data can reach hundreds of kilobytes in even modest web
applications, and it goes back and forth with every request, frustrating site visitors
with slower response times and increasing the bandwidth demands of the server.
•  Page life cycle: The mechanism for connecting client-side events with server-side
event handler code, part of the page life cycle, can be extraordinarily complicated
and delicate. Few developers have success manipulating the control hierarchy at
runtime without getting View State errors or finding that some event handlers
mysteriously fail to execute.
•  False sense of separation of concerns: ASP.NET’s code-behind model provides a
means to take application code out of its HTML markup and into a separate code-
behind class. This has been widely applauded for separating logic and
presentation, but in reality, developers are encouraged to mix presentation code
(for example, manipulating the server-side control tree) with their application
logic (for example, manipulating database data) in these same monstrous code-
behind classes. The end result can be fragile and unintelligible.
•  Limited control over HTML: Server controls render themselves as HTML, but not
necessarily the HTML you want. Prior to ASP.NET 4, the HTML output usually
failed to comply with web standards or make good use of Cascading Style Sheets
(CSS), and server controls generated unpredictable and complex ID values that are
hard to access using JavaScript. These problems are reduced in ASP.NET 4, but it
can still be tricky to get the HTML you expect.
•  Leaky abstraction: Web Forms tries to hide away HTML and HTTP wherever
possible. As you try to implement custom behaviors, you frequently fall out of the
abstraction, which forces you to reverse-engineer the postback event mechanism
or perform obtuse acts to make it generate the desired HTML. Plus, all this
abstraction can act as a frustrating barrier for competent web developers. 
•  Low testability: The designers of ASP.NET could not have anticipated that
automated testing would become an essential component of software
development. Not surprisingly, the tightly coupled architecture they designed is
unsuitable for unit testing. Integration testing can be a challenge, too.
ASP.NET has kept moving. Version 2.0 added a set of standard application components that can
reduce the amount of code you need to write yourself. The AJAX release in 2007 was Microsoft’s
response to the Web 2.0/AJAX frenzy of the day, supporting rich client-side interactivity while keeping
developers’ lives simple. The most recent release, ASP.NET 4, produces more predictable and standards-
compliant HTML markup, but many of the intrinsic limitations remain.