ASP.NET MVC Is My Shrieking Electric Guitar

This is your HTML markup:

This is your HTML markup on drugs ASP.NET:

[more]

Any questions?

ASP.NET offers a lot of horsepower, especially in its most recent incarnation. I give you jQuery, AJAX, Dynamic Data, control adapters, and more.

But traditional ASP.NET web pages are littered with cruft: hidden fields, obscure Javascript, and a ubiquitous <form> element even on pages which don’t look, act, or talk like forms. The ASP.NET WebForms infrastructure extracts a price. That price is the sanctity of your generated markup.

We could almost call clean markup the sacrificial lamb of ASP.NET WebForms development. It’s what you give up in order to achieve the illusion of state in the stateless medium known as the World Wide Web. If you develop in ASP.NET, then you’ve probably spent a lot of time chasing your tail as I have, ferreting out how to clean up ASP.NET-generated markup to make it palatable:

Reduce or removing VIEWSTATE and other hidden fields

Relocate Javascript functions from the top of the file to the bottom

Use control adapters to tweak generated markup of server controls

Create customized HtmlTextWriters and hook them in to your page classes

Override Page.Render and accomplish all kinds of mischief

Apply regular expression replaces to your finished page output

But the problem with these hacks techniques is that they attack the symptoms, rather than the cause.

Dense, encrusted markup is the natural result of trying to graft a desktop application development paradigm (with events and easily recallable state and so forth) onto an inherently stateless, request-response medium: the World Wide Web. This is what ASP.NET tries to do, and that it succeeds at all (and it does succeed) is a testament to the ingenuity of the ASP.NET development team.

Still: the generated markup is ugly and loaded with boilerplate. There can be no arguing with this, although for many line-of-business applications, the cleanliness of your markup may not matter (although in some worst-case scenarios, unbridled viewstate has been known to grow to a few megabytes in size).

But if you’re a stickler, a purist, or if you’re building something that needs to be lean and mean, a typical ASP.NET WebForms application just doesn’t give you the fine-grained control over your own markup that you’ll want—at least, not without a lot of extra work.

Enter ASP.NET MVC

You’ve probably heard about ASP.NET MVC by now (the official beta was released just a few days ago but the previews have been around for months) so I’ll refrain from ranting about the architectural benefits of MVC versus the tightly-coupled ASP.NET “desktop” paradigm of yore and just point out that markup generated by ASP.NET MVC is an order of magnitude cleaner than what you’ll get under classic ASP.NET:

The above is actual markup generated by an ASP.NET MVC website I threw together last weekend. It’s still ASP.NET—ASP.NET is now a superset which includes both the WebForms and the MVC paradigm within it—it’s just not ASP.NET WebForms.

And it’s clean. It’s tight. It can be applied from the ground up, or grafted into an existing ASP.NET WebForms application. It’s works with AJAX. You can still use server controls. You still have a design surface. Master pages. User controls. All that stuff still applies, if you want it. In the words of Scott Hanselman:

I like to think of ASP.NET MVC as the raw, acoustic version of the more heavily produced and multi-layered ASP.NET WebForms we use today.

To me, ASP.NET MVC is one of the best and most forward-looking technologies to come out of Redmond in years. While it’s not an out-and-out replacement for ASP.NET WebForms, If you’re building web applications on the Windows stack, going forward you may need a very good reason to prefer WebForms to MVC.