Addisu Hailegiorgis Desta

ASP.NET is already a traditional technology March 17, 2011

I have spent nearly a decade fascinated by ASP.NET technology, Server Controls, View state and so on. At the beginning, I used to think it is entirely a pure MVC technology. I remember back in 2003, geeks excited with View State and hacking view states. But in between, I was working on J2EE Web application and there I noticed Microsoft is still chasing the rest. I used to undermine PHP but a lot of high performance Web 2.0 sites such as Facebook are developed using PHP.

These are few of the wrongs about ASP.NET that I read recently:

• ViewState: The actual mechanism of maintaining state across requests (ViewState) often results in giant blocks of data being transferred between client and server. I have faced with an issue when the Site uses SSL for the page that uses ViewState heavily since the whole page is encrypted. 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, 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; Page_Init, Page_PreInit, Page_Load and son. Few developers have success manipulating the control hierarchy at runtime without getting ViewState errors or finding that some event handlers mysteriously fail to execute.
• Limited control over HTML: Server controls render themselves as HTML, but not necessarily the HTML you want. Moreover, the new HTML5 input types are not accessible with the attribute “runat=server”. In addition to that, not only does their HTML often fail to comply with web standards or make good use of CSS, but the system of server controls generates unpredictable and complex ID values, which are hard to access using JavaScript. We have in house JavaScript functions to strip out the complex pre-fix names added by the server.
• 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. At the beginning, these might encourage separation of concerns by writing the C “Control” part in the code behind. Even though it 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.
• Untestable: When ASP.NET’s designers first set out their platform, they could not have anticipated that automated testing would become such a mainstream part of software development as it is today. Not surprisingly, the architecture they designed is totally unsuitable for automated testing.