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!  🙂

Advertisements

7 Responses to ASP.NET MVC is the Frontier

  1. Shaun Walker was unhappy in his post.
    Microsoft did not declare nothing about that, once Web API is built over MVC infrastructure.
    I agree with you and I think that MVC and Web API have different objectives.
    Is the same old story, We must use the right tool for the right job.

  2. Max Toro says:

    The author of the post you are referring to defended WebForms because his product heavily depends on it. So, the last 4 years he wasn’t cool anymore, and it bothered him. Now he wants to update his product for a more “web services and client-side development” approach, and has chosen Web API, which makes perfect sense, and makes him cool again. End of story.

  3. Kaelin says:

    @Deivid Martins It *is* an old story, isn’t it. And now that building in-browser applications with a Web API back end is becoming the job, what does the tool(s) look like that would most empower developers? I mentioned a XAML-style editor for HTML+CSS views. And I’d like a different default folder layout – a top level folder called “Applications” where all my pages sit organized by business function rather than splitting up all the features across root-level Models, Views, and Controllers folders. What would you like?

  4. Shaun Walker says:

    I 100% agree that a lot of value came from Microsoft’s development of ASP.NET MVC. I think Phil Haack did a masterful job of leading the MVC project and incorporating open source practices and transparency into Microsoft’s development process ( it is really unfortunate that he has now moved on to GitHub ). And there was a ton of really useful functionality developed in very agile manner as part of the MVC project – including some decent support for REST services which will be ultimately be superseded by Web API. My blog post seems to have sparked some controversy but at a high level I was really just trying to emphasize the modern trends in the web development space, Microsoft’s response, and how it will affect the ASP.NET ecosystem.

  5. MVC is the cat’s ass. Pure and simple.

    Nice article

  6. mlang74 says:

    Great article. When I look at WebForms code now it reminds me of 6 years ago when I would open a VB6 project.

    On Phil Haack, I think it is great he moved on to GitHub. They made Git much more accessible to Windows developers. I believe his legacy will live on without him at Microsoft. Microsoft still has ‘The Gu’ and hanselman.

  7. AssociativeAndDeclarative says:

    I don’t see anything cutting edge about either MVC or web forms. MVC was developed at Xerox Parc in the 1970s and web forms is based on RAD tools which also first appeared in the 1970s. This thread is a tired rehash of the same arguments I’ve been hearing since I started in development 30 years ago. Web development is fragmenting into the same partisan factions that existed before the web. Don’t kid yourself that these technologies are new. There has been little progress in software development since the 1980s.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: