The Future of ASP.NET Web Forms

by admin 17. April 2012 23:00

Web Forms - MVC ChoicesI've been working with ASP.NET Web Forms for nine years now and have acquired a comfortable familiarity with its strengths and weaknesses. We've all seen the growing popularity of ASP.NET MVC over recent years and the most common reaction is to want to play with it but when it comes time to making the switch, we often experience the "don't move my cheese" syndrome. Now that I'm finally leaning towards MVC, I'm faced with the fact that it would not be a practical option for the company I work with. I do outside work and will somehow have to find enough breathing space to move over and ramp up.

What were once the strengths of Web Forms are now clearly it's weaknesses and can not be sustained in the rich, interactive, Ajax-enabled environment we operate in today; think RAD and ViewState. This richness brings with it a level of complexity for even the most mundane of applications, and an even more compelling reason for formal testing; think more complex client-server life-cycles, asynchronous requests and you get the idea. Our stateless HTTP protocol is being dragged kicking and screaming into this error-prone battlefield and it's only going to get more complex over time. Maybe in five years, there will be a move back to the server and we'll start the whole cycle again! However, in a jungle such as this, the ViewState becomes too difficult to manage, not to mention a performance killer with an increasing payload. In addition, the page life-cycle abstraction is totally removed from the reality of a normal request/response transaction in our stateless HTTP world. Web Forms stand as proof that we can become a slave to a framework.

 

The ASP.NET Stack

 

There is no right time to make such a big paradigm switch as moving from event-driven Web Forms to the close-to-the-metal MVC architecture; the best option is often just to pick a small project and jump right in. On a personal level, it behooves me to start planning now for my learning curve and the difficulty of maintaining two different approaches to programming going forward. What is, is.

Microsoft are now talking of "One ASP.NET" where we can mix and match among the different project templates. If you wanted MVC4 scaffolding in an Web Forms site, there is nothing stop you from doing it. Scott Hanselman even alludes to it in his blog post "One ASP.NET Sneak Peek: Elegant Web Forms and Snowballs in Hell". Honestly, I think that would be the biggest architectural screw up since the Spruce Goose tried to fly. Can you imagine a novice programmer five years from now trying to get his head around a mish mash of an application like this? Some things are not good just because they're new; for example the spaghetti hell of the razor syntax. Who in their right minds would go back to mixing code with markup - lunacy, yet idiots are doing it and worse still, Microsoft are promoting it.

Microsoft are continuing to support and invest in ASP.NET Web Forms, at least that is the corporate sound bite. For years now, my take on it has been that they would make some gestural investment in it in the form of trivial new features but basically let it die it's own death. Don't get me wrong, it will be around for a long time to come and has it's place. But Microsoft does not want a repeat of the fiasco they found themselves in when they deprecated the Web Forms project template for the release of VS 2005. The outcry from developers was such that they had to endure the public embarassment of scrambling to do a 180-degree turn with the SP1 release to re-introduce it.

For me the biggest selling point for Web Forms is how productive it makes me. For the vast majority of projects I work on, it is still the best fit. Each of these approaches to Web development have their place. The trick is being honest enough with yourself when trying to make a rational decision. I see Web Forms largely out of the picture within the 3/5 year range and I am planning accordingly. They may still exist but people won't be choosing to work with them. Would you choose Cobol for your next business application? I thought so...