Preface: Modern Angular Development

Over the past couple of years, Angular has changed a lot.

Angular has been around for a long time, and has always been updated quite frequently (typically on a 6-month schedule for major releases). But, these changes have typically been small/incremental or behind the scenes sort of things that didn’t have a big impact on the way most developers build with Angular.

In moves to help modernise the framework, Angular has been updated with concepts like standalone components, signals, new control flow syntax, and more. If those words don’t mean anything to you now don’t worry — we will get to these things later. The point is that there has been a lot of changes.

But, one of Angular’s key philosophies in changes that are made to the framework are that they are backwards compatible or that there is some migration path provided. There are many thousands of huge applications built with Angular, thousands within Google itself, and its reputation is built upon being a solid and stable framework for everything up to large enterprises.

This is generally a good thing: you know that if you build something with Angular you aren’t suddenly going to be forced to do a massive rewrite due to some change in the framework.

But, it does also create an awkward situation for those learning the framework. In effect, there are kind of two different supported ways to build with Angular: the old way or the new way. It really isn’t even that simple, because you could use any mixture of old and new features.

Should you learn the “new” way or the “old” way?

So, what is a new Angular developer to do? The seemingly easier and more forward looking approach is just to learn the new way. This is where Angular applications will generally move to over time.

But it’s also not quite that easy. There is still a lot of existing content and applications out there that use the older methods.

You could probably safely ignore the older Angular methods if you are building applications for yourself/your clients, or if you happen to find yourself working on updated Angular applications.

But, you might also find yourself working on an older Angular codebase. All these changes are still quite new, so chances are if you were to get a job for a company that is building/maintaining a large Angular application it would still be using older techniques in Angular.

What will we do?

This course will primarily have a focus on modern Angular development, and so we will focus to a much larger degree on the new way.

However, there will still be context provided for the old way of doing things. There will be lessons dedicated to discussing particular concepts and techniques that still exist, but that we will not be using. Wherever a concept is introduced that is new, we will also briefly discuss the old way of doing the same thing.

The general idea will be to give you enough information to provide some context, so that if you ever do find yourself in a situation where some older technique is being used you will not feel completely lost (you might just need to do some additional research).

What is the “new” stuff?

We will work our way up to the various concepts used in Angular; I don’t want to just dump everything all at once. But, I also don’t want to be completely mysterious about these old and new ways of doing things.

To give you at least a little context, at least so that you might recognise it when you first come across it in this course, some of the new concepts we will be using are:

• Standalone components
• @-syntax for control flow
• Signals
• toSignal for consuming observables
• The inject function
• Signal based APIs for input, output, resource, viewChild etc.

Whilst some of the old concepts we will discuss but not use are:

• NgModules
• Structural directives for control flow
• OnPush change detection for components
• | async pipe for consuming observables
• Constructor based dependency injection

It is not important if all of these points make no sense at all to your right now — we will get to these things later.

NOTE: There is still some benefit to using OnPush change detection for applications even with signals. However, once the signals migration is completed by the Angular team, OnPush will likely not be required for applications that are using signals based change detection. We will discuss this in more detail later, but if you are designing your application around signals, likely there will soon be no need for OnPush.

It’s also important to note that many of the old things we will discuss are not necessarily obsolete or wrong. I think it is fair to say that the Angular team and the community at large will be moving to the new approaches generally, but the old approaches are not inherently wrong or to be migrated away from as soon as possible.