Discover Iterative DOM, the magic behind Angular Ivy
Tags: angular, javascript, performance, webdev
Published: 2019-09-29 18:23:17

On the 18th and 19th of September I attended the AngularConnect conference in London. 

![AC](https://thepracticaldev.s3.amazonaws.com/i/62nhtrojr4rz29hzb4mg.png)

It was a great experience, not only for the very interesting sessions, but also for the possibility of talking personally with the Angular team.

This year, the two main topics were **performance improvements** and of course **Ivy**, the new Angular compilation and rendering pipeline.
While the View Engine, called `Renderer2`, was released unnoticed at the same time of Angular 4, Ivy stirred an higher interest. The changes that got more attention are the increase in rendering performance and the reduction of the generated bundle size. 

![ivy](https://thepracticaldev.s3.amazonaws.com/i/pfsg6df412yl4518z6hn.png)

To achieve these significant improvements drastic changes in the whole compilation process were necessary.

The Angular team postponed Ivy final release in order to avoid any disruptive effect on existing applications. At the moment Ivy is compatible with 85% of the most popular libraries and the team is constantly working to increase this number.

**From Angular v9 any project will have Ivy enabled by default.** <br>(The release is planned for late November).

However, if we discover any conflicts in our application we still have the possibility to *opt out*, that is, disable Ivy by changing the following property in our `tsconfig.json` file:

```json
{
  "compilerOptions": { ... },
  "angularCompilerOptions": {
    "enableIvy": false
  }
}
```

> AOT compilation with Ivy is faster than with View Engine, and can be used for development. If you opt out of Ivy, AOT compilation will be slower, and should not be used for development in large projects.
When Ivy is disabled for a large project, make sure that the aot build option in that project configuration is set to false and it's only set to true in the production configuration.


During the conference, the audience was invited to switch as soon as possible to Ivy for their projects (of course not the ones in production :smile:) in order to be able to increase the tested scenarios.

If you want to create a new project with Ivy enabled (using Angular < v9), you can run the following command:

```shell
ng new my-ivy-app --enable-ivy
```

Or in case of an existing project:

```shell
ng update @angular/core@next
```

Note:
> To preview Ivy, use @angular/core@next version of Angular, rather than @angular/core@latest, as it contains all the latest bug fixes and improvements.

&nbsp;
## Team's goal

The goal is to produce Angular applications with good performance, specifically on mobile devices. Therefore, the generated projects must have a small bundle size and low memory footprint.

To achieve this, Ivy uses the **Iterative DOM**.
We already know about Virtual DOM, become famous from the React world. Iterative DOM pushes the limits even further.
&nbsp;


## Virtual DOM vs Iterative DOM

In React, a component is rendered as a DOM tree. Every time its model is updated, a new virtual DOM tree is generated in memory. The new changes are applied to the in-memory version and then this is compared to the *real* DOM. 

![virtual-DOM](https://thepracticaldev.s3.amazonaws.com/i/70cgu7jn5udbtl88twyq.png)

The advantage is that only the differences are applied to the real DOM, resulting in less node updates.

**Iterative DOM** has a different approach. The components are compiled into functions (also called instructions):

![iterative-dom](https://thepracticaldev.s3.amazonaws.com/i/zp0gw9irjlr3cpw84euw.png)

For each kind of binding, there is a specific set of instructions generated:

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/nuh5s5nr3c15ze7r29xn.png)

By adding new bindings to our template, new instructions will be created accordingly:
&nbsp;
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/7yc44c920700ctx17zke.png)

The interesting aspect is that only the instructions that we will use are going to end up in the final bundle, all the rest is *tree-shaked* away. 

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/hzpru89q7sqoxrqjew3s.png)

This is the revolutionary aspect: being able to make the rendering engine itself tree shakable. If a component does not reference an instruction, it will not be used and hence excluded from the bundle.

Iterative DOM has also the advantage of allocating less memory. Differently from the virtual DOM, memory is used only when we add or remove DOM nodes. 
&nbsp;
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/69582qbjp406tx5v3umv.png)

For value changes, the updates are done in-place in the tree structure. 

&nbsp;
![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/s9ql2n5rdw0nst3mrdw0.png)

As we typically don't add/remove many elements in our application templates (at least in the majority of spa cases), this translates into a  remarkable memory saving, especially for large projects.

![performance](https://thepracticaldev.s3.amazonaws.com/i/zd0egt3qdv9ixuas2xlp.png)

Currently, for mid-size applications, the usage of Ivy does not bring improvements but instead increases the overall size even if only by a small amount. Igor Minar confirmed the result and added that the Angular team is currently investigating these values. Hopefully they will be able to find a solution soon.

Aren't you excited to pass to Ivy?
I am planning to test it this weekend for my personal Angular projects. If you find any exceptions while using Ivy, please add a new (well documented :smile:) issue in the Angular Github repository, this will greatly help in improving it even further. 

See it as a way to thank the Angular team! :heart: