No popular framework can reach the end of its life without at least some critics lined up at the finish line. ASP.NET Web Forms is no exception. As the word spread that the timeworn technology was about to be sidelined, there was no shortage of developers cheering.
It wasn’t always this way. When Microsoft released the first version of the .NET Framework, ASP.NET wasn’t an embarrassment — it was a cornerstone technology and a runaway hit. So one has to ask: Were we all trapped in a mass developer hallucination? Is the death of ASP.NET Web Forms an example of changing development practices or just changing fashion? And why couldn’t Web Forms be salvaged?
The world before Web Forms
To understand why developers used (and often loved) ASP.NET Web Forms, you need to understand the state of web development when ASP.NET was first released, nearly two decades ago.
At the time, the state of the art of web development was using embedded scripts — bits of code injected in the page that the web server would intercept and execute. Here’s an example of a classic ASP 3.0 (not ASP.NET) web page that wouldn’t have raised an eyebrow:
This example creates a basic table filled with records queried from a database. What stands out is the spaghetti-like tangle of hard-coded HTML strings and VB code. It’s like the HTML is trapped — locked into a rigid, often opaque structure of conditions and loops. In a halfway complex page, it becomes impossible to check that every code path generates a consistent, error-free HTML document. And woe betide the programmer who needs to make changes.
What Web Forms offered
If you wanted to put text on a page with Web Forms, you didn’t needs tags or rendering commands. You could behave like a civilized OOP programmer, and simply set the property of a
Label control (named to match its Windows Forms counterpart). Here’s how natural that looked:
lbl.Text = "Hello browser!";
Similarly, if you wanted to put info in a table, there was no need to understand HTML elements like
<td>. You could deal with proper objects for rows and cells:
table.Columns.Add("Quantity", typeof(string));row = table.NewRow();
row["ProductNumber"] = "12-101";
row["Product_Name"] = "Blank CD-R Media";
row["OrderDate"] = "12/06/2002";
row["Quantity"] = "50";table.Rows.Add(row);
Web controls even went so far as to expose a higher-level model that wrapped CSS. That meant that you could configure the appearance of any control using a pile of different properties:
lbl.ForeColor = Color.Crimson;
lbl.Font.Name = "Verdana";
lbl.Font.Bold = "True";
lbl.Font.Size = FontUnit.Point(14);
The CSS integration extended to a Visual Studio feature called grid layout — basically, a way for ASP.NET developers to drag and drop their way to a fixed web page layout, much like they might assemble a window in a desktop application. The drawbacks of this feature quickly became obvious. Fixed layouts broke accessibility and scaling, and made sure pages couldn’t reflow to fit different amounts of content, different window sizes, and different devices. Microsoft quietly hid the feature in the next version of Visual Studio.
It’s easy to think that Web Forms succeeded because it covered the complexities of web development with a hand-holding abstraction that mimicked Windows development. And that’s partly true. But the real advantage of Web Forms was that it introduced a model that could deal with the web problems of the time, particularly browser compatibility. It even gave developers a road to what they thought would be the future. Flip a switch, and ASP.NET’s web controls would move from ordinary HTML to perfectly valid XHTML.
The cost of the Web Forms abstraction
Every abstraction makes a trade. It simplifies the details that are in front of the developer while complicating the plumbing that works behind the scenes. The success of an abstraction depends on how well this plumbing works, how much of a tax there is to pay in performance, and whether developers will be forced out of the abstraction. If developers need to look behind the curtain and start messing around with plumbing to get what they want, the abstraction has failed. And Web Forms had plenty of failures.
The core bit of plumbing that made Web Forms work was the HTML
<form> element, stretched way beyond its intended purpose. In a Web Forms page, every web control lived inside the
<form> element, and all dynamic content was rendered there. In practice, that meant that every ASP.NET web page was consumed by one gigantic hidden form (hence the name, Web Forms).
One of the form’s most important jobs was to make sure web controls kept their state. In other words, web developers needed to be able to set a value in their server-side code at one point, and still have it in effect later, after a roundtrip to the client’s browser. After all, that was the way ordinary desktop applications worked, so that was the standard of development circa 2002. Web Forms accomplished this trick with a feature called view state, which tucked information into a hidden
<input> element in the
<form> (with a hash value to prevent tampering). That way the data could be sent to the server and then back to the browser with every single request, like an extra pack slapped on the back of mule.
The view state tax didn’t seem enormous at first, but when mobile development took off the cost of serializing and sending any extra information felt excessive. And in some cases, the size of view state could snowball . For example, developers could get into trouble if they stuffed their own objects inside (which they were encouraged to do). Or, they could bloat their pages with an editable data control, which was the “Hello World” of ASP.NET data access. Despite their popularity in slideshow decks and demos, the data controls were too depressingly slow for most real-world applications.
At first glance, the sequence of events in the page lifecycle seems logical enough. But even seasoned ASP.NET developers could get confused about the order of actions a page needed to perform — reading the markup, rehydrating web controls from view state, running initialization code, performing data binding, capturing new values that were posted in the form, loading up user controls, and so on. If a web control needed to do something during one of these stages, what could it assume about the other controls on the page? Problems were difficult to pin down, and automated tests were off the table. Once again the Web Forms abstraction had a stiff cost, but now it wasn’t performance, but complexity.
Developers could work around most of these issues, and arguably none was an outright deal breaker. Developers can — often did — turn off view state for controls that didn’t need it. They could avoid bloatware like the
GridView control and poorly conceived features like the web control skinning system. But technologies are not judged by their best use, but by their most typical use. In the end, Web Forms made it far too easy for unsuspecting web developers to shoot themselves in the foot.
The rise of Ajax
XMLHttpRequest object to become more responsive.
At first, ASP.NET met the challenge. It included a particularly handy
UpdatePanel control that allowed Web Forms pages to switch from old-fashioned postbacks to silent
Is Web Forms really dead?
Here’s the problem. Declaring that a technology is officially deprecated has consequences. It affects support contracts, bug fixes, and compatibility guarantees. Because Web Forms underpins a generation of web applications, Microsoft is reluctant to officially start the end-of-life timer.
In fact, as part of the final version of the .NET Framework (4.8), ASP.NET Web Forms is considered an official Windows system component, which means its support life is tied to the life of Windows 10. This guarantees Microsoft support for Web Forms to at least 2025 — and probably far beyond that.
But Microsoft’s support policy doesn’t tell the whole story. That’s because even though ASP.NET remains a part of the .NET Framework, Microsoft is the midst of replacing the .NET Framework with .NET Core, a project that will conclude with the release of .NET 5 later this year. This modern replacement to .NET doesn’t include ASP.NET Web Forms at all. It no longer matters if Web Forms still works. New tools development won’t support it. New programmers won’t study it. And new features, fixes, and performance enhancements won’t reach it.
So here’s the bottom line: ASP.NET Web Forms is no longer an option for new development. It’s shunned but not dead — supported as a legacy product, but finally exiled from the future of .NET. Perhaps the biggest surprise isn’t that Web Forms eventually faltered. It’s that Microsoft managed to support it while creating a replacement that will keep ASP.NET alive for decades to come.
For a once-a-month email with our best tech stories, subscribe to the Young Coder newsletter.