Traditional ASP.NET Web Forms was a great idea, and opened a whole new world to classic ASP developers. However, real-world use of Web Forms has revealed a variety of weaknesses:
- Limited control over HTML: Server controls render themselves as HTML, but not ideally. Prior to version 4 of the .NET framework, the output of server controls often failed to comply with web standards. They also did not make good use of CSS. Finally, they generated unpredictable and complex ID values which are hard to access using JavaScript.
- Weight of ViewState: Web Forms rely heavily on ViewState to maintain state across requests, which often results in giant blocks of data being transferred over the line. In many real-world applications, the ViewState can reach hundreds of kilobytes, which goes back and forth with every request. Even ASP.NET AJAX, you suffer the same problem because the ViewState data still has to be sent back and forth with each asynchronous request.
- False sense of separation of concerns: ASP.NET's code-behind model allows developers to take application code out of its HTML markup and place it into a code-behind class. In reality, this encourages developers to mix presentation code (e.g., manipulation of the server-side control tree) with their application logic (e.g., manipulation of database data). This would all be included in these code-behind classes which ended up being enormous in size. Without a better separation of concerns, the result was often incomprehensible and brittle.
- Page life cycle: Many developers get ViewState errors or find that some event handlers fail to execute when attempting to manipulate the control hierarchy at runtime. This is due to the complicated and delicate page life cycle, which connects client-side events with server-side event handler code.
...