Introducing ASP.NET and Angular
Over the first two chapters of this book, we’ll build the basics of our ASP.NET and Angular journey by mixing theoretical coverage of their most relevant features with a practical approach. More specifically, in the first chapter, we’ll briefly review the recent history of ASP.NET/.NET Core and Angular frameworks, while in the second chapter, we’ll learn how to configure our local development environment so we can assemble, build, and test a sample web application boilerplate.
By the end of these chapters, you’ll have gained knowledge of the path taken by ASP.NET and Angular to improve web development in the last few years and learned how to properly set up an ASP.NET and Angular web application.
Here are the main topics that we are going to cover in this chapter:
- Two players, one goal. How ASP.NET and Angular can be used together to build a modern, feature-rich, and highly versatile web application
- The ASP.NET Core revolution. A brief history of ASP.NET’s most recent achievements
- What’s new in Angular. A recap of the Angular development journey, from its origins to the most recent days
These are the software packages (and relevant version numbers) used to write this book and test the source code:
- Visual Studio 2022 Community edition 17.0.0 with the optional ASP.NET and web development workload (it can be selected from the Workloads section within the Visual Studio installer app)
- Microsoft .NET 6 SDK 6.0.100
- TypeScript 4.3
- NuGet package manager 6.0
- Node.js 14.15.0 (we strongly suggest installing it using Node Version Manager, also known as nvm)
- Angular 13.0.1
We strongly suggest using the same version used within this book – or newer, but at your own risk! Jokes aside, if you prefer to use a different version, that’s perfectly fine, as long as you are aware that, in that case, you may need to make some manual changes and adjustments to the source code.
The code files for this book can be found here: https://github.com/PacktPublishing/ASP.NET-Core-6-and-Angular.
Two players, one goal
From the perspective of a fully functional web-based application, we can say that the Web API interface provided with the ASP.NET framework is a programmatic set of server-side handlers used by the server to expose a number of hooks and/or endpoints to a defined request-response message system. This is typically expressed in structured markup languages (XML), language-independent data formats (JSON), or query languages for APIs (GraphQL). As we’ve already said, this is achieved by exposing application programming interfaces (APIs) through HTTP and/or HTTPS protocols via a publicly available web server such as IIS, Node.js, Apache, or NGINX.
Similarly, Angular can be described as a modern, feature-rich, client-side framework that pushes the HTML and ECMAScript’s most advanced features, along with the modern browser’s capabilities, to their full extent by binding the input and/or output parts of an HTML web page into a flexible, reusable, and easily testable model.
Can we combine the back-end strengths of ASP.NET and the front-end capabilities of Angular in order to build a modern, feature-rich, and highly versatile web application?
The answer, in short, is yes. In the following chapters, we’ll see how we can do that by analyzing all the fundamental aspects of a well-written, properly designed, web-based product, and how the latest versions of ASP.NET and/or Angular can be used to handle each one of them. However, before doing all that, it might be very useful to backtrack a bit and spend some valuable time recollecting what’s happened in the last 8 years in the development history of the two frameworks we’re going to use. It will be very useful to understand the main reasons why we’re still giving them full credit, despite the valuable efforts of their ever-growing competitors.
The ASP.NET Core revolution
To summarize what has happened in the ASP.NET world within the last decade is not an easy task; in short, we can say that we’ve undoubtedly witnessed the most important series of changes in .NET Framework since the year it came to life. This was a revolution that changed the whole Microsoft approach to software development in almost every way. To properly understand what happened in those years, it would be useful to identify some distinctive key frames within a slow, yet constant, journey that allowed a company known (and somewhat loathed) for its proprietary software, licenses, and patents to become a driving force for open source development worldwide.
The first relevant step, at least in my humble opinion, was taken on April 3, 2014, at the annual Microsoft Build conference, which took place at the Moscone Center (West) in San Francisco. It was there, during a memorable keynote speech, that Anders Hejlsberg – father of Delphi and lead architect of C# – publicly released the first version of the .NET Compiler Platform, known as Roslyn, as an open source project.
It was also there that Scott Guthrie, executive vice president of the Microsoft Cloud and AI group, announced the official launch of the .NET Foundation, a non-profit organization aimed at improving open source software development and collaborative work within the .NET ecosystem.
From that pivotal day, the .NET development team published a constant flow of Microsoft open source projects on the GitHub platform, including Entity Framework Core (May 2014), TypeScript (October 2014), .NET Core (October 2014), CoreFX (November 2014), CoreCLR and RyuJIT (January 2015), MSBuild (March 2015), the .NET Core CLI (October 2015), Visual Studio Code (November 2015), .NET Standard (September 2016), and so on.
ASP.NET Core 1.x
The most important achievement brought by these efforts toward open source development was the public release of ASP.NET Core 1.0, which came out in Q3 2016. It was a complete reimplementation of the ASP.NET framework that we had known since January 2002 and that had evolved, without significant changes in its core architecture, up to version 4.6.2 (August 2016). The brand-new framework united all the previous web application technologies, such as MVC, Web API, and web pages, into a single programming module, formerly known as MVC6. The new framework introduced a fully featured, cross-platform component, also known as .NET Core, shipped with the whole set of open source tools mentioned previously, namely, a compiler platform (Roslyn), a cross-platform runtime (CoreCLR), and an improved x64 Just-In-Time compiler (RyuJIT).
Some of you might remember that ASP.NET Core was originally called ASP.NET 5. As a matter of fact, ASP.NET 5 was no less than the original name of ASP.NET Core until mid-2016, when the Microsoft developer team chose to rename it to emphasize the fact that it was a complete rewrite. The reasons for that, along with the Microsoft vision about the new product, are further explained in the following Scott Hanselman blog post that anticipated the changes on January 16, 2016: http://www.hanselman.com/blog/ASPNET5IsDeadIntroducingASPNETCore10AndNETCore10.aspx.
For those who don’t know, Scott Hanselman has been the outreach and community manager for .NET/ASP.NET/IIS/Azure and Visual Studio since 2007. Additional information regarding the perspective switch is also available in the following article by Jeffrey T. Fritz, program manager for Microsoft and a NuGet team leader: https://blogs.msdn.microsoft.com/webdev/2016/02/01/an-update-on-asp-net-core-and-net-core/.
As for Web API 2, it was a dedicated framework for building HTTP services that returned pure JSON or XML data instead of web pages. Initially born as an alternative to the MVC platform, it has been merged with the latter into the new, general-purpose web application framework known as MVC6, which is now shipped as a separate module of ASP.NET Core.
The 1.0 final release was shortly followed by ASP.NET Core 1.1 (Q4 2016), which brought some new features and performance enhancements, and also addressed many bugs and compatibility issues affecting the earlier release.
These new features include the ability to configure middleware as filters (by adding them to the MVC pipeline rather than the HTTP request pipeline); a built-in, host-independent URL rewrite module, made available through the dedicated
Microsoft.AspNetCore.Rewrite NuGet package; view components as tag helpers; view compilation at runtime instead of on-demand; .NET native compression and caching middleware modules; and so on.
ASP.NET Core 2.x
Another major step was taken with ASP.NET Core 2.0, which came out in Q2 2017 as a preview and then in Q3 2017 for the final release. The new version featured a wide number of significant interface improvements, mostly aimed at standardizing the shared APIs among .NET Framework, .NET Core, and .NET Standard to make them backward-compatible with .NET Framework. Thanks to these efforts, moving existing .NET Framework projects to .NET Core and/or .NET Standard became a lot easier than before, giving many traditional developers a chance to try and adapt to the new paradigm without losing their existing know-how.
Again, the major version was shortly followed by an improved and refined one: ASP.NET Core 2.1. This was officially released on May 30, 2018, and introduced a series of additional security and performance improvements, as well as a bunch of new features, including SignalR, an open source library that simplifies adding real-time web functionality to .NET Core apps; Razor class libraries; a significant improvement in the Razor SDK that allows developers to build views and pages into reusable class libraries, and/or library projects that could be shipped as NuGet packages; the Identity UI library and scaffolding, to add identity to any app and customize it to meet your needs; HTTPS support enabled by default; built-in General Data Protection Regulation (GDPR) support using privacy-oriented APIs and templates that give users control over their personal data and cookie consent; updated SPA templates for Angular and ReactJS client-side frameworks; and much more.
Wait a minute: did we just say Angular? Yeah, that’s right. As a matter of fact, since its initial release, ASP.NET Core has been specifically designed to seamlessly integrate with popular client-side frameworks such as ReactJS and Angular. It is precisely for this reason that books such as this exist. The major difference introduced in ASP.NET Core 2.1 is that the default Angular and ReactJS templates have been updated to use the standard project structures and build systems for each framework (the Angular CLI and NPX’s
create-react-app command) instead of relying on task runners such as Grunt or Gulp, module builders such as webpack, or toolchains such as Babel, which were widely used in the past, although they were quite difficult to install and configure.
Being able to eliminate the need for these tools was a major achievement, which has played a decisive role in revamping the .NET Core usage and growth rate among the developer communities since 2017. If you take a look at the two previous installments of this book – ASP.NET Core and Angular 2, published in mid-2016, and ASP.NET Core 2 and Angular 5, out in late 2017 – and compare their first chapter with this one, you will see the huge difference between having to manually use Gulp, Grunt, or webpack, and relying on the integrated framework-native tools. This is a substantial reduction in complexity that would greatly benefit any developer, especially those less accustomed to working with those tools.
Six months after the release of the 2.1 version, the .NET Foundation came out with a further improvement: ASP.NET Core 2.2 was released on December 4, 2018, with several fixes and new features, including an improved endpoint routing system for better dispatching of requests, updated templates featuring Bootstrap 4 and Angular 6 support, and a new health checks service to monitor the status of deployment environments and their underlying infrastructures, including container orchestration systems such as Kubernetes, built-in HTTP/2 support in Kestrel, and a new SignalR Java client to ease the usage of SignalR within Android apps.
ASP.NET Core 3.x
ASP.NET Core 3 was released in September 2019 and came with another bunch of performance and security improvements and new features, such as Windows desktop application support (Windows only) with advanced importing capabilities for Windows Forms and Windows Presentation Foundation (WPF) applications; C# 8 support; .NET Platform-dependent intrinsic access through a new set of built-in APIs that could bring significant performance improvements in certain scenarios; single-file executable support via the
dotnet publish command using the
<PublishSingleFile> XML element in project configuration or through the
/p:PublishSingleFile command-line parameter; new built-in JSON support featuring high performance and low allocation that’s arguably two to three times faster than the JSON.NET third-party library (which became a de facto standard in most ASP.NET web projects); TLS 1.3 and OpenSSL 1.1.1 support in Linux; some important security improvements in the
System.Security.Cryptography namespace, including AES-GCM and AES-CCM cipher support; and so on.
A lot of work has also been done to improve the performance and reliability of the framework when used in a containerized environment. The ASP.NET Core development team put a lot of effort into improving the .NET Core Docker experience on .NET Core 3.0. More specifically, this is the first release featuring substantive runtime changes to make CoreCLR more efficient, honor Docker resource limits better (such as memory and CPU) by default, and offer more configuration tweaks. Among the various improvements, we could mention improved memory and GC heap usage by default, and PowerShell Core, a cross-platform version of the famous automation and configuration tool, which is now shipped with the .NET Core SDK Docker container images.
.NET Core 3 also introduced Blazor, a free and open source web framework that enables developers to create web apps using C# and HTML.
Last but not least, it’s worth noting that the new .NET Core SDK is much smaller than the previous installments, mostly thanks to the fact that the development team removed a huge set of unnecessary artifacts included in the various NuGet packages that were used to assemble the previous SDKs (including ASP.NET Core 2.2) from the final build. The size improvements are huge for Linux and macOS versions, while less noticeable on Windows because that SDK also contains the new WPF and Windows Forms set of platform-specific libraries.
- Release notes: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0
- ASP.NET Core 3.0 releases page: https://github.com/dotnet/core/tree/master/release-notes/3.0
ASP.NET Core 3.1, which is the most recent stable version at the time of writing, was released on December 3, 2019.
The changes in the latest version are mostly focused on Windows desktop development, with the definitive removal of a number of legacy Windows Forms controls (DataGrid, ToolBar, ContextMenu, Menu, MainMenu, and MenuItem) and added support for creating C++/CLI components (on Windows only).
Most of the ASP.NET Core updates were fixes related to Blazor, such as preventing default actions for events and stopping event propagation in Blazor apps, partial class support for Razor components, and additional Tag Helper Component features; however, much like the other .1 releases, the primary goal of .NET Core 3.1 was to refine and improve the features already delivered in the previous version, with more than 150 performance and stability issues fixed.
Just when everyone thought that Microsoft had finally taken a clear path with the naming convention of its upcoming frameworks, the Microsoft developer community was shaken again on May 6, 2019, by the following post by Richard Lander, Program Manager of the .NET team, which appeared on the Microsoft Developer Blog: https://devblogs.microsoft.com/dotnet/introducing-net-5/.
The post got an immediate backup from another article that came out the same day written by Scott Hunter, Program Management Director of the .NET ecosystem: https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/.
The two posts were meant to share the same big news to the readers: .NET Framework 4.x and .NET Core 3.x would converge in the next major installment of .NET Core, which would skip a major version number to properly encapsulate both installments.
The new unified platform would be called .NET 5 and would include everything that had been released so far with uniform capabilities and behaviors: .NET Runtime, JIT, AOT, GC, BCL (Base Class Library), C#, VB.NET, F#, ASP.NET, Entity Framework, ML.NET, WinForms, WPF, and Xamarin.
Microsoft said they wanted to eventually drop the term “Core” from the framework name because .NET 5 would be the main implementation of .NET going forward, thus replacing .NET Framework and .NET Core; however, for the time being, the ASP.NET Core ecosystem is still retaining the name “Core” to avoid confusing it with ASP.NET MVC 5; Entity Framework Core will also keep the name “Core” to avoid confusing it with Entity Framework 5 and 6. For all of these reasons, in this book, we’ll keep using “ASP.NET Core” (or .NET Core) and “Entity Framework Core” (or “EF Core”) as well.
From Microsoft’s point of view, the reasons behind this bold choice were rather obvious:
- Produce a single .NET runtime and framework that can be used everywhere and that has uniform runtime behaviors and developer experiences
- Expand the capabilities of .NET by taking the best of .NET Core, .NET Framework, Xamarin, and Mono
- Build that product out of a single code base that internal (Microsoft) and external (community) developers can work on and expand together and that improves all scenarios
The new name could reasonably generate some confusion among those developers who still remember the short timeframe (early to mid-2016) in which ASP.NET Core v1 was still called ASP.NET 5 before its final release. Luckily enough, that “working title” was ditched by the Microsoft developer team and the .NET community before it could leave noticeable traces on the web.
.NET 5 was released on General Availability in November 2020, a couple of months after its first Release Candidate, thus respecting the updated .NET schedule that aims to ship a new major version of .NET once a year, every November:
Figure 1.1: .NET schedule
In addition to the new name, the .NET 5 framework brought a lot of interesting changes, such as:
- Performance improvements and measurement tools, summarized in this great analysis performed by Stephen Toub (.NET Partner Software Engineer) using the new Benchmark.NET tools: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/.
- Half Type, a binary floating point that occupies only 16 bits and that can help to save a good amount of storage space where the computed result does not need to be stored with full precision. For additional info, take a look at this post by Prashanth Govindarajan (Senior Engineering Manager at LinkedIn): https://devblogs.microsoft.com/dotnet/introducing-the-half-type/.
- Assembly trimming, a compiler-level option to trim unused assemblies as part of publishing self-contained applications when using the self-contained deployment option, as explained by Sam Spencer (.NET Core team Program Manager) in this post: https://devblogs.microsoft.com/dotnet/app-trimming-in-net-5/.
- Various improvements in the new System.Text.Json API, including the ability to ignore default values for value-type properties when serializing (for better serialization performance) and to better deal with circular references.
- C# 9 and F# 5 language support, with a bunch of new features such as Init Only Setters (that allows the creation of immutable objects), function pointers, static anonymous functions, target-typed conditional expressions, covariant return types, and module initializers.
And a lot of other new features and improvements besides.
A detailed list of the new features and improvements and a comprehensive explanation of the reasons behind the release of ASP.NET 5 are available at the following URL:
- Release notes: https://docs.microsoft.com/en-us/dotnet/core/dotnet-five
- For additional info about the C# 9.0 new features, take a look at the following URL: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-9.
.NET 6 came out on November 8, 2021, a year after .NET 5, as expected by the .NET schedule. The most notable improvement in this version is the introduction of the Multi-platform Application UI, also known as MAUI: a modern UI toolkit built on top of Xamarin, specifically created to eventually replace Xamarin and become the .NET standard for creating multi-platform applications that can run on Android, iOS, macOS, and Windows from a single code base.
The main difference between MAUI and Xamarin is that the new approach now ships as a core workload, shares the same base class library as other workloads (such as Blazor), and adopts the most recent SDK Style project system introduced with .NET 5, thus allowing a consistent tooling and coding experience for all .NET developers.
In addition to MAUI, .NET 6 brings a lot of new features and improvements, such as:
- C# 10 language support, with some new features such as null parameter checking, required properties, field keyword, file-scoped namespaces, top-level statements, async main, target-typed new expressions, and more.
- Implicit using directives, a feature that instructs the compiler to automatically import a set of
usingstatements based on the project type, without the need to explicitly include them in each file.
- New project templates, which are much cleaner and simpler since they do implement (and demonstrate) most of the language improvements brought by C# version 9 and 10 (including those we’ve just mentioned).
- Package Validation tooling, an option that allows developers to validate that their packages are consistent and well-formed during package development.
- SDK workloads, a feature that leverages the concepts of “workloads” introduced with .NET Core to allow developers to install only necessary SDK components, skipping the parts they don’t need: in other words, it’s basically a “package manager” for the SDKs.
- Inner-loop performance improvements, a family of tweaks dedicated to the performance optimization of the various tools and workflows used by developers (such as CLI, runtime, and MSBuild), thereby aiming to improve their coding and building experience. The most important of them is the Hot Reload, a feature that allows the project’s source code to be modified while the application is running, without the need to manually pause or hit a breakpoint.
For a comprehensive list of the new C# 10 features, check out the following URL: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-10.
What’s new in Angular?
The story of AngularJS started in 2009 when Miško Hevery (now senior computer scientist and Agile coach at Google) and Adam Abrons (now director of engineering at Grand Rounds) were working on their side project, an end-to-end (E2E) web development tool that would have offered an online JSON storage service and also a client-side library to build web applications depending on it. To publish their project, they took the
During that time, Hevery, who was already working at Google, was assigned to the Google Feedback project with two other developers. Together, they wrote more than 17,000 lines of code in 6 months, slowly sinking into a frustrating scenario of code bloat and testing issues. Given the situation, Hevery asked his manager to rewrite the application using GetAngular (the side project mentioned previously), betting that he could do that alone within 2 weeks. His manager accepted and Hevery lost the bet shortly thereafter, as the whole thing took him 3 weeks instead of 2; however, the new application had only 1,500 lines of code instead of 17,000. This was more than enough to get Google’s interest in the new framework, which was given the name AngularJS shortly thereafter.
To listen to the full story, take a look at the following Miško Hevery keynote speech at ng-conf 2014: https://www.youtube.com/watch?v=r1A1VR0ibIQ.
The first stable release of AngularJS (version 0.9.0, also known as dragon-breath) was released on GitHub in October 2010 under an MIT license; when AngularJS 1.0.0 (also known as temporal domination) came out in June 2012, the framework had already achieved huge popularity within the web development communities worldwide.
The reasons for such extraordinary success can hardly be summarized in a few words, but I’ll try to do that nonetheless by emphasizing some key selling points:
- Dependency injection: AngularJS was the first client-side framework to implement it. This was undeniably a huge advantage over the competitors, including DOM-manipulating libraries such as jQuery. With AngularJS, developers could write loosely coupled and easily testable components, leaving the framework with the task of creating them, resolving their dependencies, and passing them to other components when requested.
- Directives: These can be described as markers on specific DOM items such as elements, attributes, and styles: a powerful feature that could be used to specify custom and reusable HTML-like elements and attributes that define data bindings and/or other specific behaviors of presentation components.
- Two-way data binding: The automatic synchronization of data between model and view components. When data in a model changes, the view reflects the change; when data in the view changes, the model is updated as well. This happens immediately and automatically, which makes sure that the model and the view are updated at all times.
- Single-page approach: AngularJS was the first framework to completely remove the need for page reloads. This provided great benefits at both the server-side (fewer and smaller network requests) and client-side level (smoother transitions, a more responsive experience), and paved the way for the single-page application pattern that would also be adopted by React, Vue.js, and the other runner-up frameworks later on.
- Cache-friendly: All the AngularJS magic was meant to happen on the client side, without any server-side effort to generate the UI/UX parts. For this very reason, all AngularJS websites could be cached anywhere and/or made available through a CDN.
- AngularJS 1.x Changelog: https://github.com/angular/angular.js/blob/master/CHANGELOG.md
The new release of AngularJS, released on September 14, 2016, and known as Angular 2, was a complete rewrite of the previous one, entirely based upon the new ECMAScript version 6 (officially ECMAScript 2015) specifications. Just like the ASP.NET Core rewrite, the revolution brought such a number of breaking changes at the architectural level and for HTTP pipeline handling, the app life cycle, and state management that porting the old code to the new one was nearly impossible. Despite keeping its former name, the new Angular version was a brand-new framework with little or nothing in common with the previous one.
The choice to not make Angular 2 backward-compatible with AngularJS clearly demonstrated the intention of the author’s team to adopt a completely new approach, not only in the code syntax but also in their way of thinking and designing the client app. The new Angular was highly modular, component-based, and came with a new and improved dependency injection model and a whole lot of programming patterns its older cousin had never heard of.
Here’s a brief list of the most important improvements introduced with Angular 2:
- Semantic versioning: Angular 2 is the first release to use semantic versioning, also known as SemVer: a universal way of versioning the various software releases to help developers track down what’s going on without having to dig into the changelog details. SemVer is based on three numbers – X.Y.Z, where X stands for a major version, Y stands for a minor version, and Z stands for a patch release. More specifically, the X number, representing the major version, gets incremented when incompatible API changes are made to stable APIs; the Y number, representing the minor version, gets incremented when backward-compatible functionality is added; and the Z number, representing a patch release, gets incremented when a backward-compatible bug is fixed. Such improvements can be easily underestimated, yet it’s a must-have for most modern software development scenarios where Continuous Delivery (CD) is paramount and new versions are released with great frequency.
- Server-side rendering (SSR): Angular 2 comes with Angular Universal, an open source technology that allows a back-end server to run Angular applications and serve only the resulting static HTML files to the client. In a nutshell, the server will render a first pass of the page for faster delivery to the client, and then immediately refresh it with client code. SSR has its caveats, such as requiring Node.js to be installed on the host machine to execute the necessary pre-rendering steps, as well as having the whole
node_modulesfolder there, but can greatly increase the app’s response time for a typical internet browser, thus mitigating a known AngularJS performance issue.
- Angular Mobile Toolkit (AMT): A set of tools specifically designed for building high-performance mobile apps.
- Command-line interface (CLI): The new CLI introduced with Angular 2 can be used by developers to generate components, routes, services, and pipes via console/terminal commands, together with simple test shells.
- Components: These are the main building blocks of Angular 2, entirely replacing the controllers and scopes of AngularJS, and also taking on most of the tasks previously covered by the former directives. Application data, business logic, templating, and the styling of an Angular 2 app can all be done using components.
I did my best to explore most of these features in my first book, ASP.NET Core and Angular 2, which was published in October 2016, right after the final release of the two frameworks: https://www.packtpub.com/product/asp-net-core-and-angular-2/9781786465689.
On March 23, 2017, Google released Angular 4: the number 3 version was skipped entirely in order to unify all the major versions of the many Angular components that had been developed separately before that date, such as Angular Router, which already was at version 3.x at the time. Starting with Angular 4, the entire Angular framework was then unified into the same MAJOR.MINOR.PATCH SemVer pattern.
The new major version brought a limited number of breaking changes, such as a new and improved routing system, TypeScript 2.1+ support (and a requirement), and some deprecated interfaces and tags. There were also a good number of improvements, including:
For example, when the application starts, not only is the app faster since the client doesn’t have to compile anything, but it throws/breaks at build time instead of during runtime for most component errors, thus leading to more secure and stable deployments.
- Animations npm package: All the existing UI animations and effects – as well as new ones – were moved to the
@angular/animationsdedicated package instead of being part of
@angular/core. This was a smart move to give non-animated apps the chance to drop that part of code, thereby being much smaller and arguably faster.
Other notable improvements included a new form validator to check for valid email addresses, a new
paramMap interface for URL parameters in the HTTP routing module, and better internalization support.
Released on November 1, 2017, Angular 5 featured TypeScript 2.3 support, another small set of breaking changes, many performance and stability improvements, and a few new features, such as the following:
- New HTTP Client API: Starting from Angular 4.3, the
@angular/httpmodule was put aside in favor of a new
@angular/common/httppackage with better JSON support, interceptors, immutable request/response objects, and other stuff. The switch was completed in Angular 5 with the previous module being deprecated and the new one recommended for use in all apps.
- State Transfer API: A new feature that gives the developer the ability to transfer the state of the application between the server and the client.
- A new set of router events for more granular control over the HTTP life cycle:
November 2017 was also the release month of my ASP.NET Core 2 and Angular 5 book, which covers most of the aforementioned improvements: https://www.packtpub.com/product/asp-net-core-2-and-angular-5/9781788293600.
In June 2018, that book was made available as a video course: https://www.packtpub.com/product/asp-net-core-2-and-angular-5-video/9781789531442.
Released in April 2018, Angular 6 was mostly a maintenance release, more focused on improving the overall consistency of the framework and its toolchain than adding new features. Therefore, there were no major breaking changes. RxJS 6 supports a new way to register providers, the new
providedIn injectable decorator, improved Angular Material support (a component specifically made to implement material design in the Angular client-side UI), more CLI commands/updates, and so on.
Another improvement worth mentioning was the new CLI
ng add command, which uses the package manager to download new dependencies and invoke an installation script to update our project with configuration changes, add additional dependencies, and/or scaffold package-specific initialization code.
Last, but not least, the Angular team introduced Ivy, a next-generation Angular rendering engine that aims to increase the speed and decrease the size of the application.
Angular 7 came out in October 2018 and was certainly a major update, as we can easily guess by reading the words written by Stephen Fluin, developer relations lead at Google and prominent Angular spokesman, on the official Angular development blog upon the official release:
”This is a major release spanning the entire platform, including the core framework, Angular Material, and the CLI with synchronized major versions. This release contains new features for our toolchain and has enabled several major partner launches.”
- Easy upgrade: Thanks to the groundwork laid by version 6, the Angular team was able to reduce the steps that need to be done to upgrade an existing Angular app from an older version to the most recent one. The detailed procedure can be viewed by visiting https://update.angular.io, an incredibly useful Angular upgrade interactive guide that can be used to quickly recover the required steps, such as CLI commands and package updates.
- CLI update: A new command that attempts to automatically upgrade the Angular application and its dependencies by following the procedure mentioned previously.
- CLI prompts: The Angular CLI has been modified to prompt users when running common commands such as
ng add @angular/materialto help developers discover built-in features such as routing and SCSS support.
- Angular Material and CDK: Additional UI elements such as virtual scrolling; a component that loads and unloads elements from the DOM based on the visible parts of a list, making it possible to build very fast experiences for users with very large scrollable lists; CDK-native drag-and-drop support; improved drop-down list elements; and more.
- Partner launches: Improved compatibility with a number of third-party community projects such as Angular Console, a downloadable console for starting and running Angular projects on your local machine;
- Updated dependencies: Added support for TypeScript 3.1, RxJS 6.3, and Node 10, although the previous versions can still be used for backward compatibility.
The Angular Language Service is a way to get completions, errors, hints, and navigation inside Angular templates: think about it as a virtuous mix between a syntax highlighter, IntelliSense, and a real-time syntax error checker. Before Angular 7, which added the support for StackBlitz, such a feature was only available for Visual Studio Code and WebStorm.
For additional information about the Angular Language Service, take a look at the following URL: https://angular.io/guide/language-service.
Angular 7 was quickly followed by Angular 8, which was released on May 29, 2019. The new release is mostly about Ivy, the long-awaited new compiler/runtime of Angular: despite being an ongoing project since Angular 5, version 8 was the first one to officially offer a runtime switch to actually opt into using Ivy, which would become the default runtime starting from Angular 9.
To enable Ivy on Angular 8, the developers had to add an
"enableIvy": true property to the
angularCompilerOptions section within the app’s
Those who want to know more about Ivy are encouraged to have an extensive look at the following post by Cédric Exbrayat, cofounder and trainer of the Ninja Squad website and now part of the Angular developer team: https://blog.ninja-squad.com/2019/05/07/what-is-angular-ivy/.
- Bazel support: Angular 8 was the first version to support Bazel, a free software tool developed and used by Google for the automation of building and testing software. It can be very useful for developers aiming to automate their delivery pipeline as it allows incremental builds and tests, and even the possibility to configure remote builds (and caches) on a build farm.
- Routing: A new syntax was introduced to declare the lazy-loading routes using the
import()syntax from TypeScript 2.4+ instead of relying on a string literal. The old syntax was kept for backward compatibility but may be dropped soon.
- Service workers: A new registration strategy was introduced to allow developers to choose when to register their workers instead of doing it automatically at the end of the app’s start up life cycle. It’s also possible to bypass a service worker for a specific HTTP request using the new
- Workspace API: A new and more convenient way to read and modify the Angular workspace configuration instead of manually modifying the
In client-side development, a service worker is a script that the browser runs in the background to do any kind of stuff that doesn’t require either a user interface or any user interaction. If you’re new to the concept, don’t worry – we’ll extensively talk about them in Chapter 12, Progressive Web Apps, where we’ll build our very own service worker.
The new version also introduced some notable breaking changes – mostly due to Ivy – and removed some long-time deprecated packages such as
@angular/http, which was replaced by
@angular/common/http in Angular 4.3 and then officially deprecated in 5.0.
A comprehensive list of all the deprecated APIs can be found in the official Angular deprecations guide at the following URL: https://angular.io/guide/deprecations.
Angular 9 was released in February 2020 after a long streak of release candidates through 2019 Q4 and was the most recent version for only 4 months before being replaced by its successor (Angular 10).
- Ivy compiler: The new Angular build and render pipeline, shipped with Angular 8 as an opt-in preview, is now the default rendering engine.
- Selector-less bindings: A useful feature that was available to the previous rendering engine, but missing from the Angular 8 Ivy preview, is now available to Ivy as well.
- Internationalization: Another Ivy enhancement that makes use of the Angular CLI to generate most of the standard code necessary to create files for translators and to publish an Angular app in multiple languages, thanks to the new
i18n attribute is a numeronym, which is often used as an alias for internationalization. The number 18 stands for the number of letters between the first i and the last n in the word internationalization. The term seems to have been coined by the Digital Equipment Corporation (DEC) around the 1970s or 1980s, together with
l10n for localization, due to the excessive length of the two words.
The long-awaited Ivy compiler deserves a couple more words, being a very important feature for the future of Angular.
February 2020 was also the release month of my ASP.NET Core 3 and Angular 9 book, featuring a whole new set of source code snippets and project samples that can also be found in this book: https://www.packtpub.com/product/asp-net-core-3-and-angular-9-third-edition/9781789612165.
Angular 10 was released on June 24, 2020, just a few months after Angular 9. The short timeframe between Angular 9 and 10 was explained by the Angular development team as an attempt to get the framework back on its regular schedule since Angular 9 got delayed by a few weeks.
The new release was mostly focused on fixing issues: more than 700 issues were fixed and over 2,000 were touched on in the process. However, there were still quite a few important updates to be aware of:
- Upgrade to TypeScript 3.9, as well as TSLib 2.0, and TS Lint v6. It’s worth noting that earlier versions of TypeScript are no longer supported because they are not compatible with some potentially breaking changes in the
tsconfig.jsonfile structure (see below).
- Angular Material improvements, including a new date range picker.
- Additional warnings when using CommonJS imports, as they can result in both larger and slower applications.
For additional info about the improved
tsconfig.json file structure (namely, “Solution Style” tsconfig.json files), take a look at the following paragraph from the TypeScript 3.9 release notes: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-9.html#support-for-solution-style-tsconfigjson-files.
To know more about the meaning of the term “tree-shaking,” check out the following guide: https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaking.
- Component Test Harnesses, a set of classes that lets a test interact with a component via a supported API. By using the Harness API, a test insulates itself against updates to the internals of a component, such as changing its DOM structure: such an idea comes from the
PageObjectpattern, which is commonly used for integration testing.
- Updated Hot Module Replacement Support: HMR is a mechanism that allows modules to be replaced without a full browser refresh; configuring HMR in Angular 11 is a lot easier, and they also introduced a new
--hmrCLI command to enable it.
- TypeScript 4.0 Support: While TypeScript 3.9 (and lower) support has been dropped, this important upgrade allows Angular 11 apps to build much faster than previous versions.
- Webpack 5 support, although it is still experimental since the new version has only been released recently and might still not be entirely stable.
- TSLint to ESLint migration: This is one of the most important changes to this version since TSLint and Codelyzer have been officially deprecated, and they will definitely be removed in the next release. To help developers to deal with such an update, the Angular team has introduced a three-step method that can be used to seamlessly migrate from TSLint to ESLint using the CLI.
- Dropped support for Internet Explorer 9 and 10, as well as IE mobile.
Other new features included updated Language Service Preview, new automated migrations and schematics, some service worker improvements, lazy-loading support for named outlets, resolve guard generation via the Angular CLI, stricter types for built-in pipes, and ISO 8601 week-numbering year format support in the
Angular 12 came out on May 12, 2021, after numerous beta releases and release candidates. The major update to this version is the long-announced deprecation of the legacy View Engine compilation and rendering pipeline in favor of the now stable and objectively superior Ivy technology, thus granting faster Ahead-Of-Time compilation.
Other notable improvements include:
- Nullish Coalescing operator (??) in Angular templates.
- Style improvements, thanks to inline Sass support in Components (within the
stylesfield of the
- Deprecating support for IE11, which will be removed in Angular 13.
- HTTP improvements, such as human-readable
HttpStatusCodenames and some new methods for dealing with HTTP parameters and metadata more efficiently.
- Strict mode by default. The Angular strict mode is now enabled by default in the CLI: this flag will enable several source code consistency checks in the TypeScript compiler as well as in Angular. Writing code with strict mode enabled helps developers to catch bugs early, reduce bundle size, avoid allocating unnecessary memory, follow best practices and get better IDE support, thus improving the maintainability of the app.
- FormControlStatus, a new type that will seamlessly include all possible status strings for form controls.
- View Engine, which was already deprecated in Angular 12, has been removed, thus leaving the new Ivy rendering engine as the only choice. View Engine removal also means that IE11 support has been dropped as well.
- Angular Package Format (APF) has been redesigned, removing View Engine-specific metadata, matching the format of ES2020, and adding support for Node Package Exports.
- New Component API, which allows developers to create components with less boilerplate code.
- Persistent Build Cache support has been enabled by default.
- RxJS dependency version has been updated from 6.x to 7.4.
- TestBed performance improvements that lead to faster, less memory-intensive, less interdependent, and more optimized tests.
This concludes our brief review of the recent history of the ASP.NET Core and Angular ecosystems. In the next sections, we’ll summarize the most important reasons that led us to choose them in 2021-2022.
Reasons for choosing .NET and Angular
As we have seen, both frameworks have gone through many intense years of changes. This led to a whole refoundation of their core and, right after that, a constant strain to get back on top – or at least not lose ground against most modern frameworks that came out after their now-departed golden age. These frameworks are eager to dominate the development scene: Python, Go, and Rust for the server-side part, and React, Vue.js, and Ember.js for the client-side part, not to mention the Node.js and Express ecosystem, and most of the old competitors from the 1990s and 2000s, such as Java, Ruby, and PHP, which are still alive and kicking.
That said, here’s a list of good reasons for picking ASP.NET Core in 2022:
- Performance: The new .NET web stack is considerably fast, especially since .NET Core 3.1, with further improvements in .NET 5 and .NET 6.
- Integration: It supports most, if not all, modern client-side frameworks, including Angular, React, and Vue.js.
- Cross-platform approach: .NET web applications can run on Windows, macOS, and Linux in an almost seamless way.
- Hosting: .NET web applications can be hosted almost anywhere: from a Windows machine with IIS to a Linux appliance with Apache or NGINX, from Docker containers to edge-case, self-hosting scenarios using the Kestrel and WebListener HTTP servers.
- Dependency injection: The framework supports a built-in dependency injection design pattern that provides a huge number of advantages during development, such as reduced dependencies, code reusability, readability, and testing.
- Modular HTTP pipeline: ASP.NET middleware grants developers granular control over the HTTP pipeline, which can be reduced to its core (for ultra-lightweight tasks) or enriched with powerful, highly configurable features such as internationalization, third-party authentication/authorization, caching, routing, seamless integration with industry-standard APIs, interfaces, and tools such as SignalR, GraphQL, Swagger, Webhooks, and JWT.
- Open source: The whole .NET stack has been released as open source and is entirely focused on strong community support, thus being reviewed and improved by thousands of developers every day.
- Side-by-side execution: It supports the simultaneous running of multiple versions of an application or component on the same machine. This basically means that it’s possible to have multiple versions of the common language runtime, and multiple versions of applications and components that use a version of the runtime, on the same computer at the same time. This is great for most real-life development scenarios as it gives the development team more control over which versions of a component an application binds to, and more control over which version of the runtime an application uses.
Now that we have acknowledged the reasons to use these frameworks, let’s ask ourselves the best way to find out more about them: the next chapter should give us the answers we need.
Before moving on, let’s do a quick recap of what we just talked about in this chapter.
We briefly described our platforms of choice – ASP.NET and Angular – and acknowledged their combined potential in the process of building a modern web application.
We spent some valuable time recalling what’s happened in these last few years and summarizing the efforts of both development teams to reboot and improve their respective frameworks. These recaps were very useful to enumerate and understand the main reasons why we’re still using them over their ever-growing competitors.
In the next chapter, we will deal with the typical challenges of a full stack developer: define our goals, acquire the proper mindset, set up the environment, and create our first ASP.NET and Angular projects.
- ASP.NET 5 is dead – Introducing ASP.NET Core 1.0 and .NET Core 1.0: http://www.hanselman.com/blog/ASPNET5IsDeadIntroducingASPNETCore10AndNETCore10.aspx
- An Update on ASP.NET Core and .NET Core: https://blogs.msdn.microsoft.com/webdev/2016/02/01/an-update-on-asp-net-core-and-net-core/
- ASP.NET Core 1.1.0 release notes: https://github.com/aspnet/AspNetCore/releases/1.1.0
- ASP.NET Core 1.1.0 Commits list: https://github.com/dotnet/core/blob/master/release-notes/1.1/1.1-commits.md
- ASP.NET Core 2.1.0 release notes: https://docs.microsoft.com/en-US/aspnet/core/release-notes/aspnetcore-2.1
- ASP.NET Core 2.1.0 Commits list: https://github.com/dotnet/core/blob/master/release-notes/2.1/2.1.0-commit.md
- ASP.NET Core 2.2.0 release notes: https://docs.microsoft.com/en-US/aspnet/core/release-notes/aspnetcore-2.2
- ASP.NET Core 2.2.0 Commits list: https://github.com/dotnet/core/blob/master/release-notes/2.2/2.2.0/2.2.0-commits.md
- ASP.NET Core 3.0.0 release notes: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0
- ASP.NET Core 3.0 releases page: https://github.com/dotnet/core/tree/master/release-notes/3.0
- ASP.NET Core 3.1.0 release notes: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-1
- .NET Core is the future of .NET: https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/
- The Evolution from .NET Core to .NET 5: https://docs.microsoft.com/en-us/dotnet/core/dotnet-five
- Introducing .NET 5: https://devblogs.microsoft.com/dotnet/introducing-net-5/
- Performance improvements in .NET 5: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/
- Introducing the Half Type: https://devblogs.microsoft.com/dotnet/introducing-the-half-type/
- App Trimming in .NET 5: https://devblogs.microsoft.com/dotnet/app-trimming-in-net-5/
- What’s new in C# 9.0: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-9
- Miško Hevery and Brad Green – Keynote – NG-Conf 2014: https://www.youtube.com/watch?v=r1A1VR0ibIQ
- AngularJS 1.7.9 Changelog: https://github.com/angular/angular.js/blob/master/CHANGELOG.md
- ASP.NET Core and Angular 2: https://www.packtpub.com/application-development/aspnet-core-and-angular-2
- ASP.NET Core 2 and Angular 5: https://www.packtpub.com/application-development/aspnet-core-2-and-angular-5
- ASP.NET Core 2 and Angular 5 – Video Course: https://www.packtpub.com/web-development/asp-net-core-2-and-angular-5-video
- Angular Update Guide: https://update.angular.io
- Angular Language Service: https://angular.io/guide/language-service
- Angular Deprecated APIs and Features: https://angular.io/guide/deprecations
- What is Angular Ivy?: https://blog.ninja-squad.com/2019/05/07/what-is-angular-ivy/
- Solution Style tsconfig.json files: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-9.html#support-for-solution-style-tsconfigjson-files
- Tree Shaking: https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaking