What’s Wrong with ASP.NET Web Forms?

Traditional ASP.NET Web Forms was a fine idea, and a thrilling prospect at first, but of course reality turned out to be more complicated. Over the years, real-world use of Web Forms uncovered a range of weaknesses:

• ViewState weight:
The actual mechanism of maintaining state across requests(ViewState) often results in giant blocks of data being transferred between client and server. It can reach hundreds of kilobytes in many real-world applications, and it goes back and forth with every request, frustrating site visitors with a long wait each time they click a button or try to move to the next page on a grid.
ASP.NET AJAX suffers this just as badly,1 even though bandwidth-heavy page updating is one of the main problems that Ajax is supposed to solve.

• Page life cycle:

The mechanism of 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 ViewState 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 codebehind class. This has been widely applauded for separating logic and presentation, but in reality developers are encouraged to mix presentation code
(e.g., manipulating the server-side control tree) with their application logic (e.g., manipulating database data) in these same monstrous code-behind classes. Without better separation of concerns, the end result is often fragile and unintelligible.

• Limited control over HTML:

Server controls render themselves as HTML, but not necessarily the HTML you want. Prior to version 4, their HTML output usually failed to comply with web standards or make good use of 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.

• Leaky abstraction:

Web Forms tries to hide away HTML and HTTP wherever possible. While trying to implement custom behaviors, you’ll frequently fall out of the abstraction, forcing you to reverse-engineer the postback event mechanism or perform perverse acts to make it generate the desired HTML. Plus, all this abstraction can act as a frustrating barrier for competent web developers. For
example, rich client-side interactivity is made excessively difficult because all client-side state can be blown away at any moment by a postback.

• Difficulty applying automated tests:

When ASP.NET’s designers first set out their platform, they could not have anticipated that automated testing would become the mainstream part of software development that it is today. Not surprisingly, the tightly coupled architecture they designed is totally unsuitable for unit testing. Integration testing can be a challenge too, as I’ll explain in within next few days.