I was waiting for the MVC versus WebForms smack downs to begin :)

Who wins my personal choice has been validated more by the people I serve than by my own opinions. I am intimately familiar with the Page Lifecycle and the nuances you have to be considering when working with WebForms, especially since I turn ViewState OFF....that alone gets you swimming in the quicksand of events and you better be able to figure why your data isn't appearing or your event didn't fire after an xChanged event.

I was okay with dealing with workarounds for WebForms until my project became extremely AJAX-ified in requirements. This new layer of complexity exponentially increased the amount of time I was spending on view-related problems...not business problems like I should be.

The feedback loop between me and the people relying on me grew too much and in some cases broke entirely as I wrapped my head around UpdatePanel voodoo and wondered by the PHP and Ruby guys were doing things so simply. To me, this warranted an experiment with Monorail, an MVC implementation, to see if perhaps I could close that feedback loop.

The first iteration allowed me to demo with my SME and as he brainstormed I was able to real-time make even complex changes in UI behaviors. The simplicity of Monorail allowed me to serve my customer without having me scratch my head and wonder why my unordered list doesn't have any data in it then telling him I have to go and recompile a ton of code to make it happen. Instead, he got excited about how rapidly I could custom fit the app to his desires.

I haven't even had time to look at MS MVC and really I am not sure I need to for the foreseeable future. Monorail has let me alter significant chunks of how it does it's work and let's me isolate stories into code that is meaningful and maintainable. Through the use of IoC-able DynamicActions I have been able to create more maintainable action hierarchies when I need to, leaving my controllers with virtually nothing in them. On a closed source product I am not sure how well I could alter such behavior.

It took time to grok Brail and how MR does its magic so that I could extend it on my whim, but mostly I discovered that what I was learning was web development. When something wasn't working I usually found out that it was because of something I need to know that nothing to do with the framework. The time spent learning about how http works and so on is transferable, whereas I found little use for <asp:BadHtml runat='server'> outside of the ASP.NET community. A side benefit has been spending time in the code bases of Monorail, RhinoCommons,etc. and looking at code and design by developers better than me. When I was learning to play drums, my teacher told me to always play with musicians better than you...that's the only way you grow. I feel the same way about development.

WebForms guys will comment and say 'you don't understand WebForms'.  Neither do my customers, but they do understand that I am delivering product faster to their machines and that is what I choose to use as the driver of my decision-making. If WebForms were to somehow change dramatically and become the simpler model that let me do what I want to do without getting in my way, then I would easily hop back to that model. But I don't see that happening anytime soon.