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.
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.