I am not a huge fan of ASP.NET Web Forms.
I learned to use Web Forms at the same time that I was learning how to write web applications. As a result, I had trouble untangling the differences between the traditional aspects of developing a web application on any platform and the peculiarities specific to the world of ASP.NET Web Forms. As far as I could tell, the Page Lifecycle was a part of every page in every web application. Dragging and dropping Web Server Controls was how the web was constructed. Skins and themes were the way the web was styled.
I was trying to gather an understanding of web development using an abstraction of web development as my guide.
So I did stupid things. Once, when I needed to bring the user from one page to another, I ended up with this:
<asp:LinkButton runat="server" PostBackUrl="~/About.aspx" Text="About Us" />
Which generates this mess:
Of course, if I had just realized that ASP.NET Web Forms sits in the same exact realm as the basic HTML websites I cobbled together in high school, I would have remembered this neat trick for bringing the user to another page:
<a href="About.aspx">About Us</a>
Over time, I started to learn more about web development, exploring principles like separation of concerns and progressive enhancement. Little by little, the landscape of web development shifted into focus and I saw what Web Forms really was: an abstraction on top of the web to make developing a web application feel like developing a stateful desktop application.
I felt like ASP.NET Web Forms had been lying to me.
So I rebelled, throwing away all of the Web Server Controls except the ones that I felt I could control. Instead of embracing the ASP.NET Web Forms approach to things, I actively fought against it:
<asp:Literal runat="server" ID="userTable"></asp:Literal>
userTable.Text = "<table>" + "<thead>" + "<tr>" + "<th>" + // ...and so on
But what I didn’t understand were the negative side effects of my cowboy coding: forging ahead with my own enterprising approach to doing things meant that I couldn’t build on top of the hard work that had already been done. I ended up with a code base that no one else could easily pick up and understand. A stack of reinvented wheels.
Nowadays, I mostly work with ASP.NET MVC applications. I am much happier. But, we still have older Web Forms applications that need love and care and new features. Instead of struggling against Web Forms, I have learned to embrace the platform for what it does well: there is a freedom in not worrying about state, there is a familiarity in treating the complexity of the web as a set of simple Web Controls, there is a power in the data-binding features of those Controls. Of course, ASP.NET Web Forms has its drawbacks: left unchecked, applications built with Web Forms can easily spiral into slow, bloated heaps of sprawling View States and erratic page refreshes.
There is a balance here: embrace the strong characteristics of ASP.NET Web Forms and control the weaker ones. Over the next few posts, I’ll discuss how I find this balance.