DEV Community

Daniel Marin for This Dot

Posted on • Originally published at labs.thisdot.co on

This is why you should go Angular 9 today

I followed almost all of the events around the Angular 9 release. After reading the Angular 9 cheatsheet, reading the Angular next docs, and watching the official release party, I chose to write this article about why you should start using v9 today.

This isn't just a new release, the Angular Team did way more than that. We finally have Ivy, and from now on, it's the recommended option for view rendering. This was a big challenge for them, having so many changes and improvements could make Angular apps feel different, making it harder for developers to adapt. One of the top priorities was making sure the number of breaking changes were the least possible.

Before diving into Ivy and why it is so cool, we are gonna talk about how easy it is to update your Angular to v9.

Update has never been this easy

The Angular Team did their best to reduce the manual changes you have to do. There were new schematics created for ng update to automate the migrations for you.

In some cases, it's as simple as running ng update @angular/core @angular/cli, and you're done. If you want a more in depth, step by step guide, I recommend you to visit the Update Angular Site or you could also check out this Angular Update Guide by Brian Love.

If you came from AngularJS, you know how hard updates have been until now. I personally got stuck in AngularJS until Angular 5, just because I thought there were too many breaking changes. But now, it feels more approachable.

You'll need Typescript version 3.7.

What's up with Ivy?

Ivy is the new view rendering engine. If you are like me, you may be thinking, Wait, what?

I won't dive into it, but we can probably rephrase the claim above, for clarity, by saying Ivy is a new way to manage the templates and projections. I know that isn't much simpler. Luckily, you don't have to care.

Now, you may be scratching your head. As I said, the Angular Team focused on respecting the way Angular works now. They wanted to do this huge change without us noticing it.

The change is under the hood, and we have the same API. This means that there are no changes for you!

What I can tell you is why they did this incredible number of changes

  • Smaller bundle.
  • Better runtime performance.
  • Template type checking.

Having a smaller bundle is one incredibly valuable to users. We get an improved UX by responding quicker, but not only that, we also get an SEO boost by being able to serve users faster. By this, I don't mean that Ivy comes with something specific to boost your SEO, but smaller bundle helps with that. If you want to take your SEO score to the next level, you'll need to explore other options like SSG with Scully or SSR with Angular Universal.

Even though Ivy changes the way templates are rendered, your old DOM selection queries in your e2e tests won't be affected.

The improved runtime performance is just perfect because now it's possible to have AOT enabled even in dev mode. According to members of the Angular Team, this is one of the best things about this new update. I don't know how many times I've forgotten to build the application with AOT enabled before pushing my code, leading to errors down the pipeline that could've been captured.

In order to enhance runtime performance, a lot of things had to change. All querying decorators like ViewChild, ViewChildren, and so on, had several changes to make them more predictable. The team is currently discussing better ways to query, but again, without us noticing it.

Template Type-checking is a game changer. Now, Angular can help you make the templates type safe. This is a major improvement, because now you can have fewer tests, and rely more on the platform. If you want to enforce this in your project, do this in the tsconfig.json file:

{
  // your options,
  "angularCompilerOptions": {
    // your angular compiler options,
    "fullTemplateTypeCheck": true,
    "strictTemplates": true
  }
}
Enter fullscreen mode Exit fullscreen mode

This way, Angular will tell you if you're breaking any typing inside a template at compilation time. But let's see it in action. If you have a component like this:

import { Component, Input } from "@angular/core";

@Component({
  selector: "app-sample",
  templateUrl: "./sample.component.html",
  styleUrls: ["./sample.component.scss"]
})
export class SampleComponent {
  @Input() number: number;
}
Enter fullscreen mode Exit fullscreen mode

And you use it like this:

<app-sample [number]="'text'"></app-sample>
Enter fullscreen mode Exit fullscreen mode

You'll get this error when compiling the application:

TS2322: Type 'string' is not assignable to type 'number'.

Very cool, right?

Working without NgModules is possible, even when compiling a single component, leading to faster unit tests. The Angular Team didn't remove the NgModules to avoid changing the way Angular currently works. They have no plans of stopping their support of NgModules any time soon, but there’s a chance that components and core building blocks will be preferred over modules.

This even makes it possible to access lazy loaded components in a simpler way. If you want to learn more about this, you definitely have to check out Angular 9: Lazy Loading Components by John Papa.

ViewChild now, by default, has { static: false }. Remember that you use static true if you want to access the ElementRef before change detection occurs (ngOnInit).

There’s a new version of TestBed, with the new compiler, that improved the entire pipeline. Time of execution can be reduced up to 40%. In a future release, we’ll be able to use AOT compiled components for unit testing. If you have already updated, feel free to share your statistics.

A few things were removed. Now you can't use Renderer, and you have to start using Renderer2. Thankfully, the ng update schematic takes care of this. The ngForm element selector has been removed, and now can only be called by using ng-form.

Thinking ahead of time

If you are making heavy use of entryComponents, you won't need to do it anymore thanks to Ivy. In v9, its deprecation was announced. Also, we can forget about TestBed.get, and start using TestBed.inject, which has the same behavior, but is type safe.

Ivy unlocks the possibility of making internationalization way better and easier to do, but it isn't there yet. We'll need to keep waiting for a more robust i18n integration into the Angular platform.

We should be moving from ts-lint to es-lint. Sadly, for the case of very large apps, it tends to be slower. Nevertheless, there are people currently working to make it better and faster.

I heard people saying that zone.js was about to die, but that's simply not true. Though it's not included as a part of the browser standard, we still need zone.js for the change detection.

What can you do to help?

  • Update today!
  • Create issues with reproduction
  • If you can help solve an issue, go ahead and join the discussion

References

Conclusion

The Angular Team put a lot of effort into this update, by not only including Ivy, but by also making the ng update schematic even better and easier to use. Now, it's our chance to help them. Let's start using Angular v9 today! Let's all create issues with reproducible repositories that can dramatically help speed up things.

Top comments (8)

Collapse
 
layzee profile image
Lars Gyrup Brink Nielsen

I've seen quite a few errors when upgrading. Like you mention in the article, we should always remember to use ng update when upgrading as well as following the migration guide.

If you experience any non-trivial errors, get in touch with me.

Collapse
 
danmt profile image
Daniel Marin • Edited

If you take a look at the video "Angular 9: Getting Ready To Update to Angular 9" from the references, they talk about everything that changed, I would recommend it as a good point of start. Anyway, as you just said, it can be hard in some projects even using ng update and following the migration guide.

Collapse
 
alvarofelipe12 profile image
Alvaro Felipe García Méndez

It's can be much complicated than that. If you use a bunch of libraries on your project you need to test (at least read how the library goes with Angular 9) in order to take that decision. But if not you can do it based on what you show in this article :P

Collapse
 
danmt profile image
Daniel Marin

The Angular Team did their best to make it easier for us. Sadly there's no way to ensure that ALL projects will be equally easy. I've updated 1 project from Angular 8 to 9 successfully with no issues.

Nevertheless, I have friends struggling for their upgrade and that's why I said "In some cases, it's as simple as running ng update @angular/core @angular/cli" instead of "It's always as simple as running ng update @angular/core @angular/cli" (:

Collapse
 
alvarofelipe12 profile image
Alvaro Felipe García Méndez

Yup, but anyway it's a good idea encouraging people to use the new version and I want to thank you for that, cause in the end any thing done could improve the actual version.

Collapse
 
noorsyyad profile image
noor

what made angular team move from ts-lint to es-lint

Collapse
 
danmt profile image
Daniel Marin • Edited

Going back to that statement I noticed I wasn't clear enough.

The Typescript team has in their roadmap improving compatibility with es-lint, once done, is very likely that ts-lint will disappear.

Given that es-lint is currently very slow in big Typescript apps, which is the common use case for Angular, the Angular Team decided to keep using ts-lint for now. I think it's a good idea to have in mind.

Collapse
 
noorsyyad profile image
noor

ok, thank you