How an Angular project is built - Day 7 - 24 days of "Front-end Development with ASP.NET Core, Angular, and Bootstrap"

Yesterday I introduced the foundations of Angular and today I'm going to briefly explain how an Angular project is built and why adding an Angular component to an ASP.NET Core is not as easy as just adding a few JavaScript files in a folder.

The following is an extract of chapter 3 of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap".

How an Angular Application Is Built for the Browser Using WebPack

To understand why it is not possible to just drop a JavaScript library in an ASP.NET Core project and have everything working, you have to understand how an Angular project is built.

As you might have noticed, Angular is a very modular framework. Each different piece of the application, both your own and from the framework, is in a separate file or module and imported as needed. Styles are spread among numerous files, potentially one per component. All these files have to be bundled together to avoid sending hundreds of files to the browser. In addition to this, Angular applications are built using TypeScript, which needs to be converted into standard ES5 JavaScript to be consumed by browsers.

Discovering the dependencies and relationships between the various pieces, transpiling JavaScript to TypeScript, bundling JavaScript and CSS, and finally including the correct references in HTML files are all steps that are needed before anyone can run an Angular application. As you can imagine, it’s a pretty daunting task.

It could have been done with a generic front-end build tool like Gulp, but the Angular team decided to use a build tool focused only on module bundling, called WebPack, which takes care of everything. And the Angular CLI tools use it to run the Angular project during development and to build the artifacts needed when publishing the application.

The rest of the chapter then explains how to integrate an Angular application into an ASP.NET Core project. You have three options:

  • Do not integrate them. Keep two separate projects, one client only and one server-side only with Web applications.
  • Integrate them in one project and have the Angular CLI create files into the wwwroot folder of the ASP.NET Core project.
  • Use the new-ish JavaScriptServices and have everything managed natively into ASP.NET Core.

Every option has pro and cons, and also a lot is decided by personal preferences. But it's important to see which the options are and how they work. Tomorrow I'll briefly show how to use the third option of the JavaScriptService.

If you want to see more of what is coming, come back tomorrow for more tips.