By Rick Strahl

Rick Strahl is the Big Kahuna and janitor at West Wind Technologies located on the beautiful island of Maui, Hawaii. Between windsurf sessions and spikey haired adventures, Rick has been a software developer for over 25 years, developing business and Web applications since the very early days of the Web when you needed a hand crank (or a pair of wire splicers) to get online. Today Rick builds client centric Web applications and services for customers with HTML5, JavaScript and mobile Web technologies, using AngularJS on the front end, and the ASP.NET stack on the back end. Rick’s company West Wind Technologies also produces a number of developer related tools including West Wind WebSurge, Web Monitor and Html Help Builder. He also maintains a host of open source libraries at http://github.com/RickStrahl and you can find Rick’s blog at weblog.west-wind.com or contact him directly at rstrahl@west-wind.com

By now, you've probably heard that Microsoft is hard at work building a new version of ASP.NET, currently dubbed ASP.NET vNext. It's the first version of ASP.NET that marks a radical departure from the original platform that was conceived in the early days of the creation of the .NET platform nearly 15 years ago. A lot has changed since then regarding how we build Web applications, and ASP.NET vNext reimagines the core framework from the ground up with a more modern stack that provides better performance, lower resource consumption, and an async model for improved performance, scalability, and economy in cloud-based hosting scenarios.

In this article, I describe some of the motivations behind this radical change, why it's needed, and how it's going to affect planning going forward with ASP.NET. In the follow-up article, “A First Look at ASP.NET vNext” elsewhere in this issue, I'll dive into creating some code and running a few simple ASP.NET vNext examples to give you feel for how the process works.

Web Application Development has Changed

The types of applications we build today are very different from the ones we built at the time ASP.NET was originally conceived. Today's Web applications are more dynamic and rely much less on server-generated HTML, Instead, they use rich client functionality that relies on services to gather information. Backend applications today are often distributed and delegate tasks to application servers to offload direct processing from the Web server itself. Even single-server HTML applications tend to be much more modular and pull resources from many diverse sources rather than building a single monolithic Web page in one shot, which results in more “chatty” Web application. Web Pages today also tend to be simpler in order to support mobile devices that have to load quickly and fit onto small screens. Today's Web applications tend to be much chattier, and deal with more, but smaller, requests.

Services are also more important than ever. Software development has moved away from traditional-style services using SOAP and WS* protocols that never really provided the promised interoperability because of the inherent complexities in the interpretation of these protocols. Instead, simpler HTTP- or REST-based interfaces that use HTTP and simple and direct data formats (like JSON, ODATA, and XML) to communicate are becoming the norm for services. Rather using than complex protocols, HTTP services tend to rely on HTTP semantics to provide infrastructure and intent and use plain non-wrapped data that can be dynamically interpreted by clients. Gone are complex service contracts and secret handshakes that vary between different platform implementations. These new HTTP-based services are based on Web technologies and can easily use ASP.NET. Today, we can use ASP.NET WebAPI (along with a host of third-party solutions like Nancy or ServiceStack) to provide these REST-based backends; vNext also provides tools to provide even more efficient solutions.

Finally, no discussion of modern trends would be complete without mentioning that we're at the beginning of the age of cloud-hosted shared computing like Azure, Amazon E2, and Google Hosting, where applications run from hosted platforms rather than from dedicated servers sitting in your server closet somewhere. While not everybody is building applications that need to scale, hosted solutions really bring out performance and resource bottlenecks that cut directly to your bottom line costs for these services. Shared hardware is great for offloading server maintenance as well as being much better for the environment, compared to standard hosting. But it does come at a high price; reducing resource usage is a very important aspect for any and all applications that are cloud-hosted.

ASP.NET vNext provides a more modular, extensible, and lean framework for building Web applications.

Re-Architecting ASP.NET

ASP.NET vNext aims to address the above scenarios by providing a more modular, extensible, asynchronous, and much leaner framework to build every kind of Web application on the Microsoft stack. ASP.NET vNext is a radical departure from the ASP.NET of yore by completely rebuilding the ASP.NET stack from scratch in a modular fashion. It's designed to address the rapidly changing Web development landscape, and performance and scalability requirements for cloud computing. And Microsoft is doing it all in the open with the ASP.NET vNext stack developed as open source with community contribution from start to finish on GitHub.

Rewrite from the Ground up

ASP.NET vNext is a from-the-ground-up rewrite of the ASP.NET stack and the hosting and .NET bootstrapping infrastructure. This might seem pretty extreme, given the long history of how ASP.NET has worked and the compatibility that we've come to expect of this stack. ASP.NET vNext is going to bring breaking changes that make it fairly impractical to move existing code forward to the new stack, while at the same time keeping most of the existing concepts of the high-level frameworks, like MVC, SignalR, and WebAPI intact. So while vNext has no direct backward compatibility, it's not making existing skills obsolete.

More specifically, the underpinnings of ASP.NET have changed (and are likely to break existing apps), while high level frameworks continue to look and feel almost the same as today's high-level frameworks. Writing MVC or Web API code in vNext looks very similar to the way you're writing MVC and Web API code today. But low-level code and HTTP semantics, like accessing HttpContext and IIS-intrinsic items or writing functionality like an HttpHandler or HttpModule, are going to look very different. ASP.NET vNext will continue to provide familiar concepts and programming models so that it's not like learning a completely new environment even though the underpinnings have changed.

I think there's a real need for this upheaval: ASP.NET is 15 years old and a lot has changed since it was originally conceived. The platform was originally designed as a one-size-fits-all that was entirely coupled to the innards of IIS. Our current ASP.NET's System.Web-based architecture closely mirrors the way that IIS processes requests and today, decoupling ASP.NET from IIS is nearly impossible. System.Web also intertwines many features in a giant monolithic module that has very little separation of concerns, which makes it very difficult to modularize functionality and change system-level behavior of ASP.NET. It's an all-or-nothing situation. To wit, ASP.NET Web API and SignalR started the path of completely abandoning the System.Web stack and worked with a new OWIN/Katana-based platform that ran separately in order to be able to host outside of the IIS environment and provide lower-level modularity. But even then, when running on IIS, the same System.Web stack needed to be pulled in again to support the IIS hosting scenario, resulting in two stacks running at the same time, which in turn resulted in bloat and overhead. There's a reason why today's MVC and WebAPI applications feel sluggish to start up, and performance is starting to show signs of actually diminishing as both System.Web and OWIN stacks mix and run at the same time. Using the existing stack, it's difficult for Microsoft and third parties to push the stack much further in terms of performance and extensibility.

With vNext, Microsoft is building a much more modular base runtime that's pluggable and that makes it much easier to host ASP.NET on any kind of hosting platform. Because it's modular, you can pick and choose the features and frameworks you need to run your application, resulting in much leaner applications. It'll also be much easier for third parties to plug into the runtime pipeline, providing new middleware or alternate hosting platforms. The ASP.NET team can also use this same modularity to provide new functionality much more easily in a modular fashion without having to update gigantic .NET assemblies; they plan to do so out of band without having to wait for major .NET version updates. The entire stack is also built from the bottom up on an asynchronous, task-based architecture, so performance - and especially scalability - should improve drastically as well as reducing resource usage for applications. This should give many of the same benefits that have made NodeJs so attractive, but still provide the richness of the .NET platform and high-level features like async/await that simplify writing asynchronous code.

What's Not There

ASP.NET vNext brings forward many of the technologies we use today on the ASP.NET stack, but it also leaves some behind: WebForms, ASMX Web Services, ASP.NET AJAX, WCF REST, even things like the HTTP Pipeline, HttpModules, and HttpHandlers don't exist in ASP.NET vNext. These technologies will continue to run with existing versions of ASP.NET just as they have in the past, but they won't be able to use or even co-exist in the same application as a vNext application. You can't mix classic ASP.NET with ASP.NET vNext in the same application context on IIS.

ASP.NET vNext also says goodbye to ASP.NET Web API. In vNext, the features of ASP.NET Web API are merged with ASP.NET MVC framework, providing a more integrated single framework that combines the best features of both. Web API and MVC previously were developed separately and had many overlapping feature sets that were similar, but subtly different. There were different processing pipelines, different extension points that used similar terminology but actually used completely different implementations under the hood. MVC and Web API in vNext are merged to produce a single integrated framework that shares the same configuration, routing, filtering, and execution pipeline, so you can write filters and behaviors once rather than separately. In short, you get the best of both worlds in a single integrated environment. Existing Web API applications can continue to be used in existing Web sites, but like System.Web-based applications, they cannot co-exist directly in the vNext application context on IIS.

ASP.NET vNext lets you choose between two runtime modes: Full CLR and the light weight Core CLR.

A Tale of Two Runtimes

Probably the most radical feature of vNext is that it introduces two pluggable application hosts to boot up vNext applications. First, there's Full CLR runtime hosting that starts up the full .NET 4.5 Framework runtime and can take advantage of all the features in the full desktop framework. But vNext also introduces a new Core CLR that uses a custom runtime loader that brings up a lightweight version of the Core CLR runtime. The new application host runtime loaders are responsible for bootstrapping the appropriate KRE runtime either from a command-line host executable or from within IIS with a loader that bootstraps from the within IIS pipeline.