A Brief History of the Microsoft Web Stack

ASP.NET Core is very different from anything that came before it. In order to understand why ASP.NET Core came to be, it's important to see what came before, and how the web development world has changed during the last 20 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 websites 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 web server. The framework also provided other services to implement basic state management, caching, and other lower-level concerns.

The second group comprised a large number of WinForms application developers who were forced by changes in the market to approach 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 integrated development environment (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 the 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 with a feature-rich, 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, with Ajax, and with the introduction of mobile devices. But it was difficult for Web Forms to evolve for several reasons:

• It was a huge, monolithic framework that 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 the full framework, so years passed between updates.
• 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, Microsoft released a new web framework called ASP.NET MVC in 2009. 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 completely on the IDE for the design of the UI, it was possible to easily update it, keeping it more in line with the fast-paced world of web development.

Although ASP.NET MVC solved the problem of the slow release cycle and removing the HTML markup abstraction, it still suffered from a dependency on the .NET Framework and System.Web, which kept 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 webpages that fetched data via Ajax from the server and rendered the UI directly on the client via JavaScript. Microsoft needed to implement a lighter, web-aware version of the library it already had for remote communication, Windows Communication Foundation (WCF), so it 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 under different web servers.

OWIN and Katana

With all these modular frameworks spreading around, there was the risk that developers would have 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. OWIN defines the components of a modern web application and how those components interact.

Microsoft released an OWIN-compliant web server in 2013, 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 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 led 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:

• You couldn't run .NET applications on a non-Windows system.
• The dependency on the full framework made .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 quickly.
• The complexity of the .NET project system prevented the development of .NET apps outside of Visual Studio.

It became clear that the best 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 the same principles.

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

The future of .NET

With the release of the first pre-releases of .NET Core 3 and .NET Framework 4.8 in 2018, Microsoft announced that the future of the .NET platform will be only in .NET Core. This means that version 4.8 is going to be the last major version of the .NET Framework, and after that, it will only receive security and compatibility updates.

That’s why .NET Core 3.x also includes all the libraries for developing modern, desktop-based applications with WPF and Windows Form.

After 3.1, the next version of .NET Core will be called simply .NET 5 (skipping version 4 to avoid any confusion with the .NET Framework).