Skip to content

John Bennett's blog

From ASP to WebForms to ASP.NET MVC

Sunday, December 9, 2007

A long, long time ago I was one of many web developers working with classic ASP.  While anyone who worked (or still works, heaven help you) with ASP will tell you how quickly a site could become unmaintainable, there was one thing I rather liked abou it:  it did not abstract away much of the underlying web technology.  HTTP was always there, and the only HTML that was rendered was what you wrote yourself.  Nothing happened that you didn’t do yourself.

When ASP.NET and WebForms came along, I was always doing “View source” to see exactly what those magical server controls were doing.  Once I understood how it worked, I began to trust it.  Over time, I spent less and less time worrying about the exact HTML that was rendered.  The productivity benefits of WebForms and server controls were the main focus.  I learned to trust the automagic-ness.  You can create some amazing things very quickly.

There are certainly drawbacks to WebForms:  only one server form (with runat=”server”) per page, out-of-control viewstate if you weren’t careful, postbacks always going to the same page, etc.  But over time, the community developed techniques to mitigate those drawbacks and make them workable.  I still believe the WebForms model is a very good thing.

As web development has become a major part of the development effort in most organzations, the roles have become more specialized.  Unlike the old days, a single person is not typically creating images in Photoshop, writing HTML (and now CSS), writing JavaScript, writing WebForms and writing business and data access classes.  In my company, we have designers who create page mock ups in Photoshop; interface developers who turn those into HTML, CSS and JavaScript; and server-side developers who write server-side code.  (Let’s leave aside the issue of whether that’s the “right” way to organize a team.  The fact is that many companies, including mine, do it that way.)

There is an impedence mismatch between these roles and the way WebForms work.  Say your interface engineer turns the Photoshop page comps into a bunch of HTML files.  Your server-side developers — looking at those HTML files in the context of the entire site — break them up into master pages, pages, and controls in some logical way that optimizes the development of the server-side code.  Then the inevitable changes come.  Do you have the interface developers rewrite the HTML, and the server-side developers try to figure out how to apply the changes in the server-side structure?  Or do you have the interface developers start working in your .ascx and .aspx files directly?  If they don’t have Visual Studio or a full dev environment set up, how can they effectively do the edit-refresh cycle to do their work?  The same types of issues crop up when you talk about a global.js JavaScript file vs. RegisterClientScript(), and with CSS files vs. ASP.NET themes.

Those challenges help explain why I’m so excited about the new ASP.NET MVC framework.  Everything I’ve seen so far looks like a combination of the power and productivity of WebForms, the total control of the rendered HTML of classic ASP, and a very nice alignment with the division of labor found in many web development shops.

I’m writing this post in Graffiti beta 1, which also uses an MVC model and NVelocity as the view engine.  The views are really clean and simple, and it’s simple to write powerful server-side helpers to produce modern CSS-styled HTML.  I can’t wait to have that structure baked into ASP.NET.