ASP.NET MVC is the Frontier

A coworker emailed me a link to an “interesting article,” as he put it. Shaun Walker, creator of DotNetNuke, posted Microsoft Declares the Future of ASP.NET is Web API wherein he reports on Microsoft’s full backing behind Web API and how it’s here to replace ASP.NET MVC. He takes the opportunity to bluntly discredit the growth of ASP.NET MVC and generally devalues it. If I didn’t know better (and I guess I really don’t) I’d think he’s harboring some kind of animosity toward MVC. The post sounds like he believes ASP.NET MVC has been little more than a popular fad, that creating MVC was basically throwing a bone to the ROR camp (as if they’re unimportant), and that Microsoft over-hyped it which caused all the interest and growth in ASP.NET MVC. “Essentially by focusing so much marketing effort on MVC, Microsoft actually created a larger market demand for it.” Have I misunderstood? If not, I respectfully and completely disagree.

The movement for MVC-ish web frameworks began, as Shaun acknowledges, apart from Microsoft. That was the beginning of what’s become a rapid feedback loop: 1. the developer community demanded an MVC-ish offering; 2. Microsoft built it. Wash, rinse, repeat for MVC 2 and 3. Microsoft didn’t manufacture some fad; it provided better tooling to developers whose practices were evolving toward better engineered software. In short, developers were advancing with or without Microsoft, and Microsoft decided it’d prefer “with.” So just to be clear, I’m saying that MVC was better than WebForms.

Having started a career in web development over 11 years ago, I have to say that WebForms was a complete wrong turn for the industry. The progression *should* have been (classic) ASP -> ASP.NET MVC -> Web API (and SPA). Hindsight is, of course, 20/20. WebForms should never have been in the sequence. It was a clear effort to give VB6 developers an on-ramp to the web. Unfortunately, it was also an effort to change ASP developers into VB6-in-the-browser developers. VB6 was a huge success (and I enjoyed it), so the idea of copying it was not without it’s merit, but it was executed with a fundamental flaw: it tried to hide the web. Putting html element events into server code is craziness. I trust we’ve all seen the absolutely ridiculous urls generated by WebForms. Forcing statefullness was a mistake. And what critique of WebForms would be complete without at least referring to the addling Page Life Cycle and the PostBack pit of dispair. The effort to weld together and paint over the seams inherent and good in the client-server architecture of the web gave birth to a mess. It would have been good if it had never been born.

ASP.NET MVC was a return to and embracing of the real web. And all the real progress in the .Net web frameworks has been coming from MVC– regaining control of the html, extension-less urls, RESTful urls, separated routing, inversion of control, test-driven development, etc. No, ASP.NET MVC was no fad, no accident caused by marketing. ASP.NET MVC has been the next evolutionary step. And MVC development continues to be the area of inovation, even when it’s not about using M-V-C. What I’m continually excited about is the separation and “librarying” of web server responsibilities. In contrast to the WebForms Titanic, everything is becoming far more modularized, interfaced, testable and replaceable. IDependencyResolver? That’s ASP.NET MVC, and that’s improved software engineering– better craftsmanship.

But ASP.NET MVC isn’t the end solution to web development. It’s the frontier of web development. MVC is really about the community and it’s warp speed trek toward improvement; it’s continued mission to seek out new and better solutions, “to boldly go where no one has gone before.” And when “M-V-C” gets replaced by API or SPA or XYZ, it will be the MVC community that takes it there. The MVC community is, in some sense, the R&D folks of web development…except that at the same time we’re quickly shipping lots of production code.

Interestingly, some of the valuable work within the MVC crowd has been recognized and pulled backwards into WebForms (e.g., routing). But I still don’t want to develop there. Shaun mentioned, “Clean separation of concerns, unit testing, and direct control over page output are all possible in the WebForms model – it just requires diligence and discipline.” But it’s an afterthought and it’s an inverse to the pit of success. It’s a peak of success where getting there requires much more effort and diligence, like climbing the icy slopes of Everest. Don’t misunderstand. I’m a firm believer in due diligence and discipline, but we should be making best practices easier.

And thanks to the MVC goodness engine (which is that rapid feedback loop), best practices are easier and even better tooling is coming. The frontier is smarter and varied clients. Web API and SPA are responses to this. 10 years ago, we couldn’t put all the processing on the client. The browser of 2002 just couldn’t handle the demands we place on it today (gmail, google docs, etc.). A historical tradition of generating HTML on the server combined with limited browser performance encouraged us to put all the display logic on the server. From an SOA perspective, this is completely backwards. A VB6 programmer would have thought it certifiably insane to dynamically build out a form with imbedded data at runtime on the server and then deliver that app to the client. But on the web that’s what we did. And it’s largely what we still do today, encouraged by tradition, the current tooling, and demos (don’t even get me started on the demos). But the sheer looseness and flexibility of MVC, the very quality that I believe is really responsible for its popularity, also enables and empowers developers to do things very differently, very easily. The idea, which is not new, not even close, is to build client applications out of HTML and JavaScript that run in the browsers and consume services offered by the server. This model kills the page life cycle completely. It even kills posting a form. Well designed apps are binding form data into view models on the client, and then transferring DTO representations of that back and forth to the services. You know what that is exactly like? Client-server WinForms (i.e., modern VB6)! The bonus is the effortless deployment of the web.

So WebForms was a good idea, but completely misemployed. Instead of welding it all together, WebForms should have pulled it all apart and taken the responsibility for creating HTML and CSS with client JavaScript “code behind” files instead of server files. The server code is best handled by Web API and SPA. Get the display logic off the server. My current dream tooling for web development would be something similar to WPF forms editor, except for HTML and CSS instead of XAML. No more dynamic HTML rendering. If we want data on the client, the client app gets it from a service– very SPA. Maybe WebForms will become just that.

I also have begun seeing the value in the REST movement to support this new world of client-agnostic services. (Again, from within the MVC camp and backported to WebForms.) Shaun agrees and states, “REST-based services which utilize the less verbose characteristics of JSON as a transport mechanism, have become the preferred approach over older, more bloated SOAP-based techniques.” And we know what he means, that REST is newly popular, and that’s correct. Comedically, however, REST is not new at all. In this context it’s as old as the web itself. SOAP is not older; it was built on top of HTTP. That we’re returning to the fundamentals of HTTP established some two decades ago is hilarious. Maybe it was the not-invented-here syndrome. Maybe we just never took the time to really learn HTTP because what little of it we used just worked. We certainly didn’t have the tooling because we didn’t realize we should be demanding it. Eventually we did demand it, and it’s finally upon us and will surely be quickly refined in the next few years, again by that MVC kick-started feedback loop. Tooling for REST on the Microsoft stack is again taking the next step with Web API that it finally began with MVC 1.

What’s funny to me is that Shaun freely admits that they built a version of DotNetNuke on MVC2, “because it had the most intuitive, light-weight REST implementation in the .NET stack.” Yes. Yes it does. In any case, Shaun is right to look with positive anticipation toward Web API and his work toward creating smart clients for DNN, but it’s coming largely because of the MVC community, not in spite of it. And is there going to be a reconciliation of web development on the .Net stack? One ring, as Shaun alludes to? I doubt it. If anything, web development is more capable than it ever was and I’m highly doubtful one technique is the best for all the situations. I think we’ll continue to see multiple technologies in tandem to choose from to meet the many and various needs. Still, to all WebForms developers, I give this always open invitation: abandon that Titanic and climb aboard with the MVC community and it’s spirit of innovation and rapid improvement!  🙂