Our .NET guru takes a birds-eye look at the history and the future of Web Development with Microsoft technologies - from ASP to ASP.NET and onwards to WebAPI and Blazor
Before .NET came along, Microsoft’s server-side web technology was Active Server Pages. Developers would mix HTML and Visual Basic in a single page. When the page was requested, server-side processing executed the Visual Basic to produce pure HTML which was returned to the browser.
While ASP would work with any browser, the server had to be running Microsoft’s Internet Information Services (IIS) and therefore could only use the Windows operating system.
Microsoft had their own client-side technology too, allowing VBScript to run within a browser as an alternative to JavaScript. Unfortunately, this was only supported by Internet Explorer, and since JavaScript is supported by all browsers, VBScript never really got off the ground.
From its introduction, .NET was focussed on providing tools for both desktop and web-based applications. Active Server Pages became ASP.NET and provided a gateway for backend programmers familiar with languages like C++ to take their first, small steps into web development.
The main approach was known as ASP.NET Web Forms. A web site could be designed using a drag-and-drop interface of server-side controls, which were then rendered as HTML to send to the browser when a page was requested. Structurally, this was very similar to traditional ASP, but provided much better support for large, scalable, maintainable sites. Coding could be done in Visual Basic or C# and business logic was kept entirely separated from GUI logic, rather than being interspersed with HTML.
To use Web Forms, developers required very little understanding of browser technologies such as HTML or CSS. This meant it was easy to start working with, but had the downside that the latest browser features were difficult to exploit, making sites appear clunky and old-fashioned to the user. When AJAX
began to be widely used, Web Forms introduced drag-and-drop controls that only offered a fraction of its capabilities. Something new was needed.
In 2009, ASP.NET MVC was released, an implementation of the MVC design pattern which has been around since the 1970s.
A Model is simply a class containing data that needs to be displayed or entered on a web page. A Controller is a class that reads and writes a Model to and from the database and applies business logic and validation. The key to the technology is the View, which is written in a .cshtml file (or .vbhtml, but C# is used far more commonly than Visual Basic nowadays). As the file suffix suggests, the View is a mixture of C# and HTML, and C# features such as conditionals and loops can be used to construct HTML with optional and repeating sections. The ‘Razor’ syntax allows for seamless switching between the two. Good practice dictates that this C# is purely concerned with formatting the output. Business logic – still written in C# - should go in the Controller.
Compared with WebForms, ASP.NET MVC requires much greater understanding of HTML and CSS, and even of JavaScript, but this gives the advantage that sophisticated browser features can be fully exploited. That said, ASP.NET MVC is still a server-side technology. The HTML pages are generated on the server and sent to the browser. Although JavaScript can be used, ASP.NET MVC simply delivers it to the browser without providing any real developer support.
Meanwhile, client-side technologies were progressing fast. Libraries layered on top of JavaScript make development easier and more robust. Low-level libraries like jQuery led on to full-blown APIs such as Angular and React. Compared with ASP.NET MVC, which requires a round-trip back to the server for every interaction, these technologies provide a far richer user experience. But a server-side process is still required for heavyweight processing, database access and so forth. Such a process, that provides raw data rather than HTML, is known as a web service rather than a website.
The first .NET approach to writing web services was the Windows Communication Foundation, but more recently the trend has been for RESTful web services, and the .NET implementation of this is ASP.NET WebAPI. In many ways this can be regarded as MVC without the V. The Controller manipulates Models as before, but then rather than sending HTML to the browser, it just sends the Model data. It’s up to a browser to act as the View and transform the Model data into a web page. Any browser technology such as Angular or React could be used for this, and Visual Studio provides support in several of these, allowing the client- and server-side code to be developed side-by-side, albeit in different technologies.
In 2016, .NET Core was introduced. This was a complete rewrite of .NET with the specific intent of allowing .NET to run on platforms other than Windows. This means that ASP.NET web servers can now be hosted on Linux, without IIS, which can prove more efficient and cost-effective on the cloud.
Not everything was ported to .NET Core. Web Forms were dropped, but ASP.NET MVC and WebAPI have continued to evolve, and new technologies have been added. Razor Pages are similar to MVC, but combine Views and Controllers together into a single class. Minimal APIs allow simple web services to be written with only a few lines of code, without the overhead of Controllers.
And finally, we have a true .NET client-side technology.
The introduction of the standard WebAssembly browser technology allows languages other than JavaScript to be run in the browser – C# being one of them. ASP.NET Blazor provides client-side features similar to Angular or React, but written in C#. This can be used in combination with Web API on the server-side, allowing C# to be the programming language across the entire application, with a single code base and a single set of developer skills.
Although the older technologies are still supported, the main .NET options for new development are essentially ASP.NET MVC, Razor Pages, WebAPI and Blazor. Although these do very different things, there is a good deal of commonality between them. If a developer learns ASP.NET MVC then they will be able to apply those skills to WebAPI and Blazor. MVC is still a great technology for relatively simple, static websites. For something more interactive a WebAPI backend can connect to a frontend written in Blazor (or using your JavaScript library of choice).
Once you understand the fundamentals of ASP.NET, the choice is yours.
If you found this article interesting you might be interested in the following courses:
