LeeDumond.com

With ASP.NET MVC being the new hotness, some just can't resist the urge to proclaim that, all of a sudden, Webforms Suck. Well, some of us have been making a living on Webforms for years, and despite proclamations to the contrary, Webforms are still useful and are here to stay.

---

With the dizzying array of new technologies being embraced by Microsoft lately, we're seeing it a lot more frequently. Hello LINQ to SQL, ADO.NET sucks! Hello Entity Framework, LINQ to SQL sucks! Hello jQuery, AJAX sucks! And now, hello ASP.NET MVC, Webforms suck!

You've seen it before. It's the classic "boy-meets-new-girl, boy-dumps-old-girl, boy-disses-old-girl-all-over-town" story. If this was 1985, John Hughes would probably be making a movie about it.

Make no mistake, there are lots of reasons to love MVC. Lean, mean HTML. Clear separation of concerns. Support for multiple view engines. RESTful UI. Cute URLs. Unit testing. But does all this MVC goodness mean that Webforms Now Suck? Not by a longshot, pal. With apologies to my friend JD Conley, here are 10 reasons that Webforms should and will remain relevant for a long time to come.

Webforms are a mature technology. There's a lot to be said for this. The Webforms paradigm has been around since 2002 - a generation in Web years. Webforms are tested, tried, and true. Millions of applications have been built on Webforms, and along with that, a vast human knowledge base has developed. This is an invaluable resource that you can tap into whenever you need it. There's no problem in Webforms that hasn't been solved countless times in countless ways before. You just have to know how to look, where to look, and whom to ask. Trust me, the answer is out there.

Webforms are great for RAD development. When you need to develop a quick prototype or proof-of-concept for a client, Webforms are tough to beat. Can you name another technology that actually lets you see your data on the page in under 30 seconds? Or that lets you flesh out a complete, working, data-driven web application in under 30 minutes? More productivity in less time means I get paid. And I really like getting paid.

Tons of third-party controls. With Webforms, there is almost never a reason to reinvent the wheel. There are thousands of third party controls and UI libraries developed by Microsoft and others. Many of them are free. Others are available at very reasonable cost.

WYSIWYG support in Visual Studio. I understand that once you surpass the intermediate level as a developer, you'll probably be working in Source View most of the time; but for RAD development (see above) or for those new to development, the ease-of-use of Visual Studio's Design View cannot be overestimated.

Support for Dynamic Data. Webforms support Dynamic data, MVC doesn't. Dynamic Data is way, way cool. If you don't believe me, check out this recent Scott Hanselman post.

Support for App_Theme. If you are into working with ASP.NET Themes, swapping out Master pages on the fly, and doing a lot of other server-side dynamic UI stuff, Webforms offers better support. This is one reason I don't hear mentioned very often.

Webforms are Newbie-Friendly. MVC, by it's nature, lets you design "closer to the metal," exerting fine-grained control over HTML rendering. This is one of the things that I really dig about MVC. But lets face it - unless you have a thorough understanding of XHTML, CSS, JavaScript, the DOM, and are equipped to tackle issues like web standards, accessibility, and cross-browser rendering, you aren't going to get very far with MVC.

Webforms, on the other hand, give you the option of abstracting HTML rendering to the ASP.NET runtime. Heck, it even takes care of cross-browser and downlevel browser issues behind the scenes. This is a boon to developers new to the Web, who might not have a strong grasp of HTML. It's like ASP.NET is one big party, and everyone's invited. This is web development for the masses - noobs included - and I say, the more developers who adopt ASP.NET technology, the better for everyone.

Webforms provide options. Note that I said above that Webforms give you the option. No one is forcing you to use instead of or instead of if you don't want to. No one is forcing you to use CSS classes instead of ID selectors if you don't want to. No one is forcing you to use the AJAX framework instead of writing your own callbacks if you don't want to. Webforms still allow you to retain a good deal of control over your page in cases where you need it, and hand off to server controls when that's more convenient.

The ViewState/Postback model. This is one aspect of Webforms that MVC fanboys slam particularly hard; but the fact is Webforms just plain makes it easier to preserve state, period. Of course, whether you consider the Webforms state model and form postbacks as a "weakness" or a "strength" probably depends on your background. As a heavily OOP-oriented guy, the event-driven model feels natural to me. And personally, I like the idea of letting the runtime handle the state of my server controls automagically.

It is true that ViewState can get out of hand pretty easily if you either a) aren't paying attention, or b) don't understand the purpose of ViewState or how to control it. If you don't need to post the form, turn your ViewState off! (For that matter, if you don't need to post the form, why are you using a form?) If you are cross-posting the form to another page, turn ViewState off! If you are posting the form back to itself but don't need to retain page or server control values, turn ViewState off! Of course, you can always compress the ViewState that remains. And if you really hate ViewState, modify your code so that it works without it - for example, rebind data-bound controls manually. Remember, ViewState can be disabled for a single control, a whole page, or even for an entire application.

Webforms will continue to evolve. Microsoft is still committed to Webforms, and a lot of new and exciting things are being planned for the next version of the ASP.NET framework. Among those already announced are the ability to control ClientIDs for nested server controls, support for URL routing, much-improved ViewState management, and many improvements to existing server controls, including standards-compliant, CSS-friendly HTML out of the box (finally, goodbye and good riddance to those dreaded CSS Friendly control adapters).

---

Look, it's one thing to get jazzed by a new technology like ASP.NET MVC. I certainly am. I feel it's pretty safe to say that I will be doing a lot less in Webforms a year from now than I'm doing today, and if you're reading this, that probably holds true for you as well. But to proclaim that everything that came before now "sucks" is just plain ridiculous. Each model has important strengths that make more sense for solving certain problems. For some developers, in certain scenarios, MVC will be the better choice. For others, Webforms will be the better choice. And in some cases, many will find combining the two makes the most sense (you can still use Webforms with MVC, you know).

I, for one, plan to keep Webforms securely stowed in my back pocket. Webforms still have a lot of good things going for them, and that's why they're not going anywhere.

Sure, everyone wants to dance with the New Girl at the party. But sometimes, it's better to go home with the one that brung ya.

Subscribe to this blog for more cool content like this!

Bookmark / Share