By software engineering standards, ASP.NET Web Forms can be considered old school. Perhaps I’m aging myself with that statement, but its true. From a software perspective, even 10 years begins to show its age. I started to use Web Forms the year after they were introduced by Microsoft in 2003.
Most of my college years were spent in Web Forms and around 80% of my professional career has revolved around them as well. Needless to say, I have a history. And I enjoy it for the most part. That’s not something that I typically say about frameworks. I have also used ASP.NET MVC 5 heavily, but I can’t quite say that I enjoy doing so. I’ve used React as well, and it gets the job done, but again, I wouldn’t say that I enjoy working with it. Web Forms are different though.
It’s like how someone driving an electric car today, can still appreciate the sound of a 1969 Shelby engine. It’s because it’s well built, pretty powerful and it brings a certain level of nostalgia to software development. But there’s alot more to like as well.
5. Server Controls
For those unaware, server controls are pre-built web components with a ton of out of the box functionality that compiled down to compliant and modern day HTML. Think buttons, links and images, except they can be handled by the server directly without any extra work. These controls can have server-side event handlers attached to them, such as button clicks or change events. Visual Studio handles much of this event binding for you typically with just a tap of a key.
In the age of everything AJAX though, server controls might start to show their age. Mainly because full-page postbacks are getting harder to come by these days. So binding a server side ‘change’ event to a drop-down menu isn’t something that you are probably going to do in 2021.
Luckily, Microsoft thought of that as well and introduced the UpdatePanel control, which allows content to be rendered without having to perform a full-page postback event. Essentially, it’s a control that creates the appropriate AJAX request functionality for server controls. And once again, you make it all work by simply dragging the controls to the panel.
It’s the simplicity of the whole thing that I really like.
4. User Controls
User controls are essentially server controls (mentioned above) except that they are custom. You could define your own reusable components with whatever functionality and properties that you see fit.
This allows you to very easily include these components onto any web form and to configure them individually through their respective properties. The real benefit here though, comes when you begin to leverage 3rd party custom user controls that other organizations have developed throughout the years.
I’ve seen everything from fully responsive diagram editors to complex word processors developed as custom user controls. You could also develop generic controls that are capable of running in any ASP.NET web application as well. Which, for someone like me, is a giant boon as I have a fair amount of Web Form projects currently either published or soon to be published.
If you are familiar with React, then the closest thing to User Controls would be the Component system. Essentially, standalone modules that can share data with either its parent or with other controls as well.
3. Page Life Cycle
The ASP.NET Page Life Cycle is embedded into my subconscious mind like the alphabet. And that’s because during the mid 2000’s, it was one of the most popular interview questions that I received time and time again.
Because it’s important. At least, if you are working with Web Forms it can be important. Without getting into too much technical detail the page-life-cycle is the series of steps that every page goes through in order to render.
For reference, those include, start, initialize, load, render and unload. And best of all, you have access to each of those event handlers. Which means that if there is something that you need to configure or setup before the page loads or even after the page has loaded, then you can freely do so.
I haven’t worked with any other framework that has given me that fine granular level of control over the page render sequence. And while not the most used feature, there have been times when preprocessing controls or modules is a must.
2. Code-Behind
The standout feature for me personally when working with Web Forms is the clear separation of client-side logic versus server-side logic. ASP.NET tackles this by splitting each web page into two separate files respectively. One strictly for client-side code (including server controls), and the other to house the sever-side event handlers, such as button clicks or page load events.
Both pages can communicate with each other in many ways. Server pages can modify the DOM and server controls and the client pages can include server-side tags that are rendered before the page loads.
And lastly on this part, you have the option of compiling down the project in a way so that updates to the client-side page do not require a recompilation of the entire project. Only updates to the code-behind server would require this. And that is huge if you are in a front-end heavy development position where small changes are constant.
To me personally, this client-server separation of code is clear and concise. Every developer on a project knows where the button click event handler is located. They don’t have to search through custom project or directory structures in order to find where certain logic is hidden, which I tend to find often when working with other frameworks.
1. Loyalty
Ask any .NET developer that has worked with Web Forms if they would switch, and I’d wager that the vast majority would scoff mightily. At least, a .NET developer that knows Web Forms well. The ones that have gone deep and found the most obscure of bugs, only to tap into some grander collective developer conscience and find an even more obscure solution.
I’ve found myself in that situation time and time again. Staring at the belly of the best uncertain if what I am doing is even possible. And when hope is all but destroyed, the compiler spits out a success message and things are good. It’s a great feeling.
And that’s why I am loyal to the framework. It’s done really well by me and so far there is nothing that I have found to be impossible. My hope is that Microsoft (reads this article) acknowledges the thousands of developers that have spent a career learning to navigate this environment, by continuing to support it.
However, from the looks of it, Microsoft does state in various parts of their website that developers should consider using Razor Web Pages in lieu of Web Forms moving forward. And without plans to port it over to .NET Core, it does beg the question of just how much longer the technology will be able to live on.
Until the day comes when it is no longer supported though, I will gladly continue to use it and to promote it to whoever is willing to listen to a guy rant about ASP.NET Web Forms almost 2 decades after its release.