The WebForms stalwarts

One sentence I’d never thought I’d see describing WebForms is:

It was perfect, and it’s acceptance was meteoric !

That’s from the VisiCalc-WebForms comparison of Joe Stagner.  Obviously no framework is perfect, but I wouldn’t attribute its acceptance because of its quality.

When I moved from ASP classic to WebForms, the whole postback business was just completely baffling.  At the time, I assumed WebForms was architected that way because the MS team knew something about web development that I didn’t.  Instead, I think that WebForms was designed the way it was to convert the VB 6 masses to a familiar paradigm of controls and events.  Now that was successful.

WebForms did well what it set out to do – create a WinForms-like development experience on the web.  Unfortunately, we wound up with ViewState and the bastardization of the Web to get there.  I don’t believe WebForms were a mistake, but it’s a solution to a much smaller problem space than originally touted.  If I’m building a SharePoint-like application, sure, connecting WebParts might make sense.  But HTTP just isn’t that hard to do.  Given routing, it might take you a week (or less) to come up with a functioning MVC framework.

But in the end, I could really care less about the WebForms stalwarts.  I’ll never work with it again by choice.  Other frameworks have found ways to make web development fun, but did so by embracing SOLID design principles and the fundamental architecture of the Web.  As much as I enjoy revisionist history as the next guy, developer needs did not “evolve” into needing MVC.  It’s that the WebForms architecture wasn’t really needed in the first place.  But hey, if you’re the type of guy that enjoys getting poked in the eye with a sharp stick, you can have your ViewState.

How to hinder reflection-based scenarios