A Brief History of the Microsoft Web Stack

ASP.NET Core is very different from anything that came before. In order to understand why .NET Core came to be, it's important to see what it was before and how the web development world has changed during the last 15 years.

ASP.NET Web Forms

Web Forms was released with the first version of the .NET Framework back in 2002. It was meant to appeal to two different kinds of developers.

The first group included web developers coming from Classic ASP, also called Active Server Pages, who were already building web sites and web applications with a mix of static HTML and dynamic server-side scripting (usually VBScript), which were used by the framework to hide the complexity of interacting with the underlying HTTP connection and with the web server. The framework also provided other services to implement some kind of state management, caching, and other lower-level concerns.

The second group was comprised of a large number of WinForms application developers who were forced by changes in the market to start approaching the world of web development. Those developers didn't know how to write HTML. They were used to developing the UI of their applications by dragging elements onto the designer surface of an IDE.

Web Forms was engineered by combining elements from both technologies. It turned out to be a framework where everything was abstracted: the elements of the HTTP connection (request and response), the HTML markup of UI elements, and the stateless nature of web—this last one was via the infamous ViewState.

This mix was very successful, as it allowed a lot of new developers to build web apps thanks to the feature-rich and approachable event-based programming model.

Over the years, many things changed. These new developers became more skilled and wanted to have more control over the HTML markup produced. And the web programming model changed as well, with the more extensive usage of JavaScript libraries, Ajax, and with the introduction of mobile devices. But it was difficult for Web Forms to evolve:

• It was a huge monolithic framework, which was heavily coupled with the main abstraction layer System.Web.
• Given its programming model, which relied on Visual Studio, the release cycle of Web Forms was tied to its IDE and of the full framework, so years passed between updates.
• The last limiting factor was the fact that Web Forms was coupled with Internet Information Services (IIS), which was even more difficult to upgrade because it was part of the operating system itself.

ASP.NET MVC

To try and solve the aforementioned issues, in 2009 Microsoft released a new web framework called ASP.NET MVC. It was based on the Model-View-Controller (MVC) pattern to keep a clear separation between business logic and presentation logic, allowing complete control over the HTML markup. In addition to this, it was released as a separate library, one not included in the framework. Thanks to this release model, and not relying 100% on the IDE for the design of the UI, it was possible to easily update it and keeping it more in line with the fast-paced world of web development.

But ASP.NET MVC, although solving the problem of the slow release cycle and removing the HTML markup abstraction, still suffered from a dependency on the .NET Framework and System.Web, which still made it strictly coupled with IIS and Windows.

ASP.NET Web API

Over time a new web programming model appeared: instead of processing data server-side and sending the fully rendered page to the browser, this new paradigm, later called Single-Page Applications (SPA), used mostly static web pages that fetched data via Ajax from the server and rendered the UI directly on the client via JavaScript. Microsoft needed to implement a lighter and web-aware version of the library they already had for remote communication, Windows Communication Foundation (WCF), so they released ASP.NET Web API.

This library was even more modular than the other libraries, and, probably because it was originally developed by the WCF team and not the ASP.NET team, it didn't rely on System.Web and IIS. This made Web API completely independent from the rest of ASP.NET and IIS, opening possibilities such as running it inside a custom host or potentially under different web servers.

OWIN and Katana

Now, with all these modular frameworks spreading around, there was the concrete risk that developers had to manage separate hosts for different aspects of modern applications. To avoid this becoming a real problem, a group of developers from the .NET community created a new standard, called OWIN, which stands for Open Web Interface for .NET, that defines the components of a modern web application and how those components interact between them.

Microsoft released an OWIN-compliant web server, called Katana, and made sure its web frameworks worked inside it. Some problems still remained, however.

ASP.NET MVC, being tied to System.Web, couldn't run inside Katana. Also, all these frameworks, being developed by different teams and at different times, had different programming models. For example, both ASP.NET MVC and Web API supported dependency injection, but in different ways. If developers wanted to combine MVC and Web API inside the same application, they had to implement them twice.

What It Brought to .NET Core

With the latest iteration of libraries, it was clear that the maximum potential of the full .NET framework had been reached. Still, many issues remained open:

• One couldn't run .NET applications on a non-Windows system.
• The dependency on the full framework made the .NET apps less suitable for high-density scenarios, like the cloud, where hundreds of applications run on a single machine and must scale up very fast.
• The complexity of the .NET project system prevented the development of .NET apps outside of Visual Studio.

It became clear that the only possible solution was to start from scratch, redesigning the ASP.NET framework to be fully modular with clearly implemented, generic foundations. It also needed to be cross-platform and based on an underlying .NET framework adhering to same principles.

For these reasons, Microsoft completely rebuilt ASP.NET Core based on a new cross-platform .NET runtime, which later became .NET Core.