What’s new in Angular 4

So what’s new in Angular 4? Do not worry, your existing application code is not useless, and you don’t need to learn a new framework all over again.
The good news is that Angular 4 is almost exactly the same as Angular 2, from a development point of view. Most of the changes are “in” the framework. Upgrading is as simple as installing the new dependencies. But more on that later…

Angular 4 is going to be faster, much faster, and according to the Angular team up to 60% smaller applications.

That’s massive!

Before we talk about how all this works, let’s answer the question you have…

What happened to Angular 3?

Adopting Semantic Versioning

Starting with the 2.0.0 release of Angular, we?ve adopted the following development processes:
1. We use semantic versioning for signaling the content of Angular releases.
2. We have moved to time-based release cycles so that you can plan ahead.
3. We have a deprecation policy so that you know how to get notified of API changes ahead of time.
4. We have clarified the distinction between stable and experimental APIs.
5. We have clarified the scope of our Public API surface.

This was a move towards making the Angular framework and releases more manageable. The framework needs to be stable for its ecosystem to depend on it. At the same time, the Angular team needs to continue making changes (minor and major) for the framework to keep improving.

Here’s what you can expect from the Angular team –

Patch version released every week.

Minor version released every month.

Major version released every 6 months.

Yes, that’s right… There’s going to be an Angular 5 in the next 6 months. And Angular 7 in 2018.

Quick Note on Semantic Versioning

Semantic versioning is a way of tagging/labeling releases. Every time a new version of an application released, we can refer to it using a “version number”.

Patch Release

These are number bumps at the end of the version number – 2.2.0 to 2.2.1.

A patch release includes no new features and no breaking changes. These releases are to make backward compatible bug fixes.

Minor Release

You know it’s a minor release when it goes from 2.2.1 to 2.3.0 (change in the middle number).

Minor releases add new features without introducing any breaking changes. That means you can upgrade your application to the latest version without refactoring any code.

Major Release

You know it’s a major release when the first digit in the version number changes – 2.3.0 to 3.0.0.

A major release includes new features with potential breaking changes. Some of the changes could be minor ones, requiring a little bit of refactoring, or serious, for example deprecate or discard old syntax.

What Happened to Angular 3?

The truth may shock you…! There is no version 3. 😮

Most of the Google application code lives in one large mono repo. As crazy as that sounds, it works! Google project that use Angular use the code at the head of the master branch of the Angular repo.

Every time a new release of Angular is out on the master branch, a CI (continuous integration) orchestra that is triggered. The CI runs tests and builds for all Google applications that rely on Angular.

So what does this have to do with Angular going from version 2 to 4?

All Angular packages (core, common, etc.) live in one massive repository and are distributed separately via npm.

Before this release, most of Angular’s packages were on version 2.x.x but @angular/router was on version 3.x.x. Because of this internal versioning conflict, the Angular team decided to skip Angular 3 and move to Angular 4.

This helps the team and everyone else keep unnecessary confusion at bay.

Just Call it Angular

In his keynote, Igor Minar (who works on Angular) requests developers to stop calling it AngularJS, Angular2, and Angular4.

Everything after Angular 1 (which will be referred to as AngularJS) is simply “Angular“. The versions only denote Angular’s growth over time.

Now that we’ve got a better understanding of why Angular is on version 4, let’s talk about some of the major improvements in the newer version.

Reduced Size and Improved Performance

During our release candidate period, we heard from many developers that migrating to 4 reduced their production bundles by hundreds of kilobytes.

All the Angular documentation and most of the demo apps you’ll find online use JIT. This means that the application compiles in your user’s browsers.

What it really means is that your application isn’t as fast as it can be. The weight of the application is higher than it needs to be because –

The download includes the compilation library which accounts for about 50% of the weight of the framework.

The templates are not pre-compiled, which means the browser has to do a lot of work before it can show the user something.

AOT compilation, on the other hand, compiles your code before the user gets it. That means that the code –

takes lesser time to download (because the compilation library is not included).

is executed faster due to reduced complie time in the browser.

If you want to learn more about how you can add AOT in your application, check out Angular’s docs on AOT.

Separate Animation Package

The animation package is no longer a part of the @angular/core package. This means that if your application does not use the animations package, it will be lighter.

If you do use the angular animations package, you can –

add animations yourself to your main NgModule by importing BrowserAnimationsModule from @angular/platform-browser/animations

New Features in Angular 4

Not all the changes are under the hood. Here are some changes that make your life as a developer easier.

*ngIf and else?

Until this point, you were most likely writing conditionals like this

Welcome {{user.name}}

With the new syntax, you can provide an else clause. This is a more convenient way to express a conditional.

Welcome {{user.name}}

Loading…

Here, we wrap our else clause in a ng-template component – a new component introduced in Angular 4.

Renderer 2

The Renderer class from Angular 2 got deprecated. It’s new replacement is Renderer 2. This is a part of the serious under the hood changes that Angular has made.

If you aren’t familiar with the Renderer service, think about this…

One of the reasons we all love Angular so much is it’s DOM abstraction capabilities. We don’t need to document.querySelector('#id') anymore. So why should we have to get access to the DOM element when we need to manipulate the UI.

That’s why we use the Renderer service. It’s an abstraction for UI rendering manipulations.

Coming back to the deprecation…

The old Renderer will still work, but will be removed at some point in the future. It’s recommended that you switch to the new Renderer 2.

Making the switch is as simple as updating the name of the injected component and updating the names of methods. For Example renaming Renderer to Renderer2 and changing method names, if necessary.

You can have a look at the link above to access the class docs.

Angular Universal – All Caught Up

The Angular Universal project allows you to render your Angular app server side. If you aren’t familiar with this library you can check out the git repo or this really nice video by Nir Kaufman.

The community driven project picked up by the Angular team and is now up to date with Angular v4.

Better Developer Feedback

Other new features such as TypeScript (2.1 and 2.2) compatibility and the @angular/language-service package move Angular towards being more IDE friendly.

The language-service package, in particular, is one that the Angular team has been working on since version 2. It’s meant for other companies to add Angular language support to their applications.

With the addition of source maps, you can also see errors in your templates in the original context of the template.

Note: No Support for TypeScript’s strictNullChecks

Without this flag, null and undefined types can be assigned to another type. However, with this flag these types are only assignable to themselves (i.e. null can only be assigned to a Null type variable and undefined can only be assigned to an Undefined type variable).

Adding strictNullChecks was on the Angular 4 roadmap, but it needed more work. Due to backward compatibility the Angular team decided to add this in later (expected in v4.1).

We discovered during the RC period that there is more work to be done for this to function properly in all use cases, so we intentionally made 4.0 incompatible with the strictNullChecks setting in order to avoid breaking apps that would otherwise eagerly adopt this TypeScript mode when the proper support lands in 4.1 (tracking issue is #15432).

Upgrading to Angular 4

Alright. So you’ve decided that you want the potential 60% size reduction in your application and you want to blow your users away with even better load times.

Importing the new BrowserAnimationsModule from the @angular/platform-browser/animations package into your root ngModule, if you rely on animations.

Running ng serve or whatever start command you use.

Jaw drop! That easy.

Igor (from the Angular team) did mention that they planned to make the upgrade process a breeze. That’s why they call this release the invisible makeover.

Between choosing better performance or easier migration, the Angular team chose easier migration. So we can expect a lot of performance improvements in the upcoming major releases of Angular. These will be at the cost of some breaking changes.

Conclusion

Even though version 4 doesn’t bring any breaking changes, future versions might. It’s best to keep your users as happy as you can by making your app run as fast as possible.

The Angular team is working hard to keep the framework stable and predictable. As a developer, you should stay active in the community and try to keep your code at Angular’s master branch.