Microsoft Declares the Future of ASP.NET is Web API
Sitting 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 ).
At 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.
While 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.
In 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.
Web 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?
Well, 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.