June 19, 2012 6 Comments
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.
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!