Microsoft Declares the Future of ASP.NET is Web API

Web APISitting on a plane on my way home from Tech Ed 2012 in Orlando, I thought it would be a good time to jot down some key takeaways from this year’s conference. Some of these items I have known since the Microsoft MVP Summit which occurred in Redmond in late February ( but due to NDA restrictions I could not share them with the developer community at large ) and some of them are a result of insightful conversations with a wide variety of industry insiders and Microsoft employees at the conference.

First, let’s travel back in time 4 years to the Microsoft MVP Summit in 2008. Microsoft was facing some heat from market newcomer Ruby on Rails and responded with a new web development framework of its own, ASP.NET MVC. At the Summit they estimated that MVC would only be applicable for ~10% of all new web development projects. Based on that prediction I questioned why they were investing such considerable resources for such a relative edge case, but my guess is that they felt it was an important edge case at the time as some of the more vocal .NET evangelists as well as some very high profile start-ups ( ie. Twitter ) had publicly announced their intent to use Rails.

Microsoft made a lot of noise about MVC. In fact, they focused so much of their messaging and marketing hype around MVC that it appeared that WebForms was essentially dead. Yes, it may have been true that Microsoft continued to invest in WebForms, but from an outside perspective it really appeared that MVC was the only framework getting any real attention. As a result, MVC started to gain market share. An inside source at Microsoft told me that MVC usage has grown at a rate of about 5% per year and now sits at ~30%. Essentially by focusing so much marketing effort on MVC, Microsoft actually created a larger market demand for it.  This is because in the Microsoft ecosystem there is somewhat of a bandwagon mentality amongst developers. If Microsoft spends a lot of time talking about a specific technology, developers get the perception that it must be really important. So rather than choosing the right tool for the job, they often choose the tool with the most marketing hype and then try to sell it to the customer.

In 2010, I blogged about the fact that MVC did not make any business sense for the DotNetNuke platform. This was because our ecosystem relied on third party extensions which were dependent on the WebForms model. If we migrated the core to MVC it would mean that all of the third party extensions would no longer be compatible, which would be an irresponsible business decision for us to make at the expense of our users and customers. However, this did not stop the debate from continuing to occur in our ecosystem. Clearly some developers had drunk Microsoft’s Kool-Aid about MVC and were of the mindset, to paraphrase an old Scottish saying, “If its not MVC, it’s crap”. Now, this is a rather ignorant position to take as most of the benefits of MVC can be achieved in WebForms with solid architecture and responsible coding practices. 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.

So over the past few years some horror stories have begun to bubble to the surface of software development projects focused on ground-up rewrites of web applications for the sole purpose of migrating from WebForms to MVC. These large scale rewrites were typically initiated by engineering teams with only a single argument driving the business decision, that Microsoft was promoting MVC as “the future”. These ill-fated rewrites offered no benefit to end users or customers and in fact resulted in a less stable, less scalable and more complicated systems – basically taking one step forward and two full steps back. A case in point is the announcement earlier this week that a popular open source .NET CMS provider has decided to pull the plug on their new MVC product which has been under active development for more than 18 months and revert back to WebForms.

The availability of multiple server-side development models has deeply fragmented the Microsoft developer community. Some folks like to compare it to the age-old VB vs. C# language debate. However, the VB vs. C# language debate was ultimately more of a religious war because at least the two dominant programming languages were compatible with one another and could be used interchangeably. The issue with WebForms vs. MVC is much more challenging. This is because the messaging from Microsoft has positioned the two solutions as being incompatible with one another and as a result web developers feel like they are forced to choose one path or another. Yes, it is true that it has always been technically possible to use WebForms and MVC in the same project, but the tooling support has always made this feel “dirty”. The fragmentation has also made it difficult to attract newcomers as the perceived barrier to entry for learning ASP.NET has become higher. As a result many new software developers entering the market are gravitating to environments where the development model seems more simple and intuitive ( ie. PHP or Ruby ).

Sharepoint 2010At the same time that the Web Platform team was busy promoting ASP.NET MVC, the Microsoft Office team has been promoting Sharepoint as a platform for building internal enterprise web applications. Sharepoint has great penetration in the enterprise and over time has been enhanced with improved extensibility capabilities for software developers. But, like many other mature enterprise ASP.NET web applications, it is built on the WebForms development model. Similar to DotNetNuke, Sharepoint leverages a rich third party ecosystem for both generic web controls and more specialized WebParts – both of which rely on WebForms. So basically this resulted in a situation where the Web Platform group had headed off in one direction and the Office team had gone in another direction, and the end customer was stuck in the middle trying to figure out what to do with their existing investments in Microsoft technology. It really emphasized the perception that the left hand was not speaking to the right hand, as strategically speaking there did not seem to be any high level plan from Microsoft to ensure consistency and continuity across the different product lines.

With the introduction of ASP.NET MVC, it also made some of the third party control vendors scratch their heads, and wonder what the heck Microsoft was thinking. The original value proposition of ASP.NET over Classic ASP was the ability for web developers to emulate the highly productive desktop development model by using abstract components for creating rich, interactive web interfaces. Web control vendors like Telerik, Infragistics, DevExpress, and ComponentArt had all built sizable businesses offering powerful user interface components to WebForms developers. And even after MVC was introduced these vendors continued to improve their products, offering greater productivity and a superior user experience via AJAX to what was possible in MVC. And since many developers were comfortable and satisfied with these third party solutions, the demand remained strong and the third party web control market continued to prosper despite the availability of MVC.

Web ServicesWhile all of this was going on in the Microsoft ecosystem, there has also been a fundamental shift in the general software development industry. Driven by the explosion of Internet-enabled devices, the focus has now centered on service-oriented architecture (SOA). Service-oriented architecture is all about defining a public API for your product that any client can consume; whether it’s a native application running on a smart phone or tablet, a web browser taking advantage of HTML5 and Javascript, or a rich desktop application running on a PC. 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. SOA also has the benefit of producing a cross-platform API, as every major technology stack is able to interact with standard REST-based web services. And for web applications, more and more developers are turning to robust Javascript libraries like JQuery and Knockout for browser-based client-side development techniques for calling web services and rendering content to end users. In fact, traditional server-side page rendering has largely fallen out of favor, resulting in decreased demand for server-side frameworks like Ruby on Rails, WebForms, and (gasp) MVC.

ASP.NET vNextIn response to these new industry trends, Microsoft did what it always does – it immediately poured some resources into developing a solution which will ensure they remain relevant and competitive in the web space. This work culminated in a new framework which was branded as Web API. It is convention-based and designed to embrace native HTTP standards without copious layers of abstraction. This framework is designed to be the ultimate replacement for both the REST aspects of WCF and ASP.NET MVC Web Services. And since it was developed out of band with a dependency only on ASP.NET 4.0, it means that it can be used immediately in a variety of production scenarios.

So at Tech Ed 2012 it was made abundantly clear in numerous sessions that Microsoft views Web API as the “Future of ASP.NET”. In fact, one Microsoft PM even went as far as to say that if we look 3-4 years into the future, that all ASP.NET web applications will be developed using the Web API approach. This is a fairly bold prediction and clearly telegraphs where Microsoft plans to allocate its resources going forward. Currently Web API is being delivered as part of the MVC4 package, but this is only temporary for the sake of convenience. It also sounds like there are still internal discussions going on in terms of how to brand the various aspects of ASP.NET going forward – perhaps the moniker of “ASP.NET Web Stack” coined a couple years ago by Scott Hanselman and utilized as part of the open source release of ASP.NET bits on Codeplex a few months back will eventually stick.

One Ring To Bind Them AllWeb API is being positioned as the unification of ASP.NET – the glue that is able to pull this fragmented mess back together again. The  “One ASP.NET” strategy will promote the use of all frameworks - WebForms, MVC, and Web API, even within the same web project. Basically the message is utilize the appropriate aspects of each framework to solve your business problems. Instead of navigating developers to a fork in the road, the plan is to educate them that “hybrid” applications are a great strategy for delivering solutions to customers. In addition, the service-oriented approach coupled with client-side development promoted by Web API can effectively be used in both WebForms and MVC applications. So this means it is also relevant to application platforms like DotNetNuke and Sharepoint, which means that it starts to create a unified development strategy across all ASP.NET product lines once again.

And so what about MVC? There have actually been rumors floated that MVC has reached a stage of maturity where, similar to WebForms, it will be treated more as a maintenance product line going forward ( MVC4 may in fact be the last significant iteration of this framework ). This may sound alarming to some folks who have recently adopted MVC but it really shouldn’t, as both WebForms and MVC will continue to play a vital role in delivering solutions to customers. They will just not be the primary area where Microsoft is spending the majority of its R&D resources. That distinction will obviously go to Web API. And when the question comes up of why not enhance MVC to make it work with Web API, you must take a step back and look at this from the higher level to see that it really makes no sense. MVC is a server-side page compositing framework; whereas, Web API promotes client-side page compositing with a heavy focus on web services. In order to make MVC work well with Web API, would require a complete rewrite of MVC and at the end of the day, there would be no upgrade path for existing MVC applications. So it really does not make much business sense.

So what does this have to do with DotNetNuke?

DotNetNukeWell, around 8-12 months ago we recognized the software industry trends towards web services and client-side development. We decided to utilize a “hybrid” model which would provide compatibility for existing modules while at the same time provide a bridge for developers who wanted to utilize more modern web techniques. Customers who like the productivity and familiarity of WebForms can continue to build custom modules using the traditional approach. However, in DotNetNuke 6.2 we also introduced a new Service Framework which is actually built on top of MVC2 ( we chose to leverage MVC because it had the most intuitive, light-weight REST implementation in the .NET stack ). The Services Framework allowed us to build some rich interactive features in DotNetNuke 6.2, including the Messaging and Notification Center and Activity Feed. But based on where we know Microsoft is heading, it makes sense for the next major version of DotNetNuke ( which is expected to be released in Q4 2012 ) to migrate from MVC2 to Web API. This will likely result in some breaking changes in the Services Framework but we feel it is the best approach for ensuring the platform remains highly modern and relevant. The fact that our development strategy is perfectly aligned with the “One ASP.NET” strategy from Microsoft means that our customers and developer community can be confident in their current and future investments in the DotNetNuke platform.


  • Microsoft making a lot of noise about Web API!

  • Your take on the situation is pretty different from what I'm seeing. I thought that Web API is to take an equal part in ASP.NET compared with MVC, Webforms, and Webpages. The future of ASP.NET is being able to build things pulling from all parts of ASP.NET as you want to use them. At least that's what some from the ASP.NET group have been talking about.

  • My take from TechEd was that WCF would take more of a hit from Web API adoption...

  • has been a roller coaster ride from the beginning - wap, websites, back to wap, mvc, etc. Time to move to backbonejs for web apps, and wordpress for web marketing pages. Minimize any use of web api or whatever its called.

  • Your post is more anti-MVC than it is pro-WebApi. Until these two are merged as I have predicted (not one going away), MVC is the de-facto framework for providing "rendered views" to the client.

    MVC is not a Kool-Aid, it is a powerful framework to build sites. WebApi is focused on full implementation of HTTP spec and is not meant to replace MVC.

  • I agree with aliostad, this post really is more anti-MVC than it is pro-WebApi. WebForms and MVC target two very different demographics, there's no need to hate one over the other.

  • This post is completely misleading and none of them make sense to me. ASP.NET MVC, ASP.NET Web Forms and ASP.NET Web API (you can now add SignalR to this list) are whole different frameworks. They are the tools in your toolbox. You just need to pick the one that suits your job at the time when you need it.

    The most important of all, they are all actively developed and supported frameworks by Microsoft. I addition to that, the mass majority of them are open source.

    IMO, all people who read this post must watch this talk of Scott Hanselman:

    Many problems, many solutions: One ASP.NET

    This is the real idea and the future of ASP.NET Web Stack, not only one framework on top of ASP.NET.

  • really?

    (a couple of years ago): wahh! the world is changing and my product can't support it! wahh!! it's crazy! we don't need it. this is for a tiny subset of developers, but MS is shoving it down our throats! why why why???

    (now): wahh! people love that new stuff! wahh! they don't really love it, but MS is making them love it! they are stupid follower people - lemmings all of them! wahh! and now, gasp, the world is STILL changing! wth? I can't take it! and guess what? that new stuff was cool enough that we used it for some small things, and... we'll use the new stuff too, but.. wahh!

  • Web API is only the future of... making web APIs in .NET.

    In case anyone is not familiar (it doesn't seem like the author is), a web API is simply a rest-ful URL (i.e.: that can be accessed through a variety of methods (GET,POST,PUT,DELETE) and return a variety of responses.

    The responses are typically JSON, XML, or some other type of data format which can be read programmatically (i.e.: not by humans).

    In contrast MVC and Web Forms provide alternate frameworks for producing user-facing web sites.

    I hope this clears up some of the FUD in this article. If you need to write an API, consider Web API. If you need to write a website, choose either MVC or Web Forms.

    If you want a framework closer to the way that the actual web functions, choose MVC. If you want to be abstracted and leave the dirty-work of HTML/Javascript to someone else consider Web Forms. If you want a CMS consider Umbraco or Orchard before looking at DotNetNuke.

    Also, Umbraco is not abandoning the MVC approach, only their initial attempt at implementing it, along with a number of other changes to their system that didn't work out.

    They made no mention to abandoning their next version because of their decision to use MVC, and in fact developers would be quite upset if they chose not to continue down the MVC path versus the current XSL model.

    What does the next Umbraco release have to do with MVC? The same thing that Web API has to do with MVC: nothing.

  • This is clearly nothing but spin to make the turd that is DNN look better (but failing miserably, as all the comments show).

    The author abuses the Umbraco problem, which had nothing to do with it's use of MVC. In fact, getting to MVC is still a design goal of Umbraco.

  • I was making a point about WebForms to MVC project migrations and I purposely avoided mentioning Umbraco in this blog post because I personally have a ton of respect for Niels Hartvig and Paul Sterling and the tough decision they ( and the rest of HQ ) made recently about V5 ( and even emailed Niels privately with my thoughts ). It is unfortunate that others feel the need to call out Unbraco by name, and then resort to public mud-slinging. We are all in the ASP.NET ecosystem together and we all win or lose based on whether Microsoft is able to formulate a unified development strategy for the future ( which I believe they have ).

  • My blog was not intended to come across as negative towards MVC from a technical perspective - in fact we opted to use MVC2 as the basis of our Services Framework in DotNetNuke 6.2 because we thought it was the best solution for building REST-based services. My blog was intended to point out how the introduction of MVC created a lot of confusion and fragmentation in the Microsoft developer ecosystem and that there is now the potential for a unified ASP.NET strategy in the form of Web API, which can be leveraged with both WebForms and MVC.

  • @sbwalker

    For the love of God, please look at the picture you put on your post if you don't want to read it from the begging. This is completely wrong from a lot of perspectives. How can you put Web API and MVC at the same category? They both serve for different needs. How can you indicate that MVC created a lot of confusion? Web Forms and MVC is not the same and will never be. In general, you made it sound like an obligation to migrate from MVC to Web Forms which is totally wrong!

    I am sorry, I don't wanna be offensive here but by looking at what you described here, I can see that you have no idea what the team is targeting at the moment. Because you are an ASP.NET MVP, I'd accept from you to have more stable knowledge than the one described in this post.

  • Correction to above comment:

    "In general, you made it sound like an obligation to migrate from Web Forms to MVC which is totally wrong!"

  • Hmm, I don't completely disagree with what the author is saying..

    It seems to me that a few years from now MVC might just be used as a simple page renderer, that most of the code will be on the client, and that the client will do most of its communication through Web API.

  • @Nemesis116 That's the direction I'm personally interested in, though having options is inherently valuable. Where I see the need for tooling, then, is in creating those rich client apps - perhaps something similar to the WPF/XAML composer except for HTML+CSS with code in JavaScript (client) instead of .Net (server). Getting the display logic off the server is an important step.

  • @tugberk_ugurlu - I am definitely not advocating migrations from WebForms to MVC, or MVC to WebForms, unless there is a compelling business reason to do so - changing from one framework to another is a significant undertaking with plenty of risk to application integrity and should be driven by clear business objectives. I totally agree that Web API is not in the same category as MVC - they solve completely different problems. The point I was trying to make was that Web API has value to both WebForms and MVC implementations, and as the industry shifts to more client-side development techniques the server-side framework becomes less relevant, as you are no longer using it as a view engine for rendering content. Instead you are using it to publish raw JSON which any client can consume.

  • @tugberk_ugurlu - I will admit that the picture was more for dramatic effect to get people's attention ;)

  • Very nice and good article

  • Im not sure what everyone is complaining about. This is a very dead on future thinking article about client vs server side. The trend is towards client side technologies which have exploded in recent years (think jquery, KO, backbone, etc).

    I will still be using MVC as my base, but much of data is going to move from controllers pulling data from EF to jquery ajax calls to Web API.

  • Huh? From the illustration on - it seems like the article had an agenda and tried to bend the facts to fit it. Are you using Web API to defend DNN using WebForms?

  • My coder is trying to persuade me to move to .
    net from PHP. I have always disliked the idea because of
    the costs. But he's tryiong none the less. I've been using
    WordPress on several websites for about a year and am worried about switching to another platform.

    I have heard excellent things about blogengine.

    net. Is there a way I can import all my wordpress content into
    it? Any kind of help would be greatly appreciated!

  • Everything is very open with a clear clarification of the challenges.
    It was definitely informative. Your site is very helpful.
    Thanks for sharing!

  • A colleague linked me to your website. Thanks for
    the information.

  • "In order to make MVC work well with Web API, would require a complete rewrite of MVC and at the end of the day, there would be no upgrade path for existing MVC applications"

    Sorry but this is nonsense. Web API and MVC are a natural fit. In fact Web API is pretty much MVC without the "V". It still makes sense to render views with MVC that consume WebAPI services just as it can be done with client-heavy frameworks like Sencha (touch and extjs). MVC in those scenarios would certainly take a lesser role, but an important one nonetheless. Your article displays a clear bias against MVC and frankly a lack of understanding of the benefits it provides. Webforms, MVC and WebAPI will continue to coexist, but I see much development future with pure MVC and MVC/WebAPI hybrids.

  • psrylr I really enjoy the article.Thanks Again. Awesome.

  • This one is really an awesome & outstanding site. I went through it many times and like its theme. Its quite simple and fascinating. The stuff in the Blog is very genuine and could be seen on very rare places. Keep it on buddy!!!

  • Why visitors still use to read news papers when in this technological world
    the whole thing is presented on web?

  • WOW just what I was looking for. Came here by searching for what is a business case

  • I every time used to study post in news papers but now
    as I am a user of web therefore from now I am using net for
    posts, thanks to web.

  • This is a very dead on future thinking article about client vs server side. The trend is towards client side technologies which have exploded in recent years

  • Icup3t I think this is a real great article. Fantastic.

  • Im obliged for the article.Thanks Again. Awesome.

  • Thanks again for the blog post.Much thanks again. Great.

  • maidenpopinjaybe partial topurloinimportantfurnish

  • Great update on the trend at Microsoft. Client side MVC frameworks like AngularJS are gaining popularity. Even knockout.js is impressive but it is not a framework. It looks like AngularJS in combination with node.js gives a very powerful competition to Microsoft stack of solutions(MVC4/knockout.js/upshot.js(beta)).
    In my view clarity is the key, with Microsoft technologies most things happen under the hood and they try to hide it on purpose. Due to this a lot of experienced people do not even understand how ViewState works.

  • This website is great 4c1281b927f4996d6240cbe0757904e8

  • This post seems to be the most eloquent voice of reason. Eversince ASP.NET MVC came to life, Web Forms developers have been under the gun. WHY? ASP.NET MVC still feels like a half-baked solution to me. What's more important, my urge to try the lastest technology and greatest or the ability to deliver more apps in a timely fashion?

  • Great site,, is it on WordPress?

  • Yep, I knew it; years ago when MVC came out I busted my veteran coding mind on getting to understand just how and why the f!#$#k one has to jump through hoops and connect a thousand dots to get simple straight forward things done with MVC. half-baked! I agree with Reinaldo. Good riddance MVC!!! You will surely NOT be missed. Pity Microsoft is treating it's demise with such kid gloves, it should be shoved in the ground as hard and fast as it was shoved in our faces when it first came out.

Comments have been disabled for this content.