Understanding Angular Ivy: Increase DOM and Virtual DOM

Angular is our primary tool for writing TestMace applications. In one of the previous articles, we touched upon the topic of Ivy renderer. It's time to find out in more detail how the Ivy differs from the previous engine.

At Nrwl, we have been awaiting for some time the possibilities that Ivy will open for us and our customers. Angular Ivy is the new Angular rendering engine, which is fundamentally different from all similar technologies of popular frameworks in that it uses the Incremental DOM.

What is the Incremental DOM and how does it differ from the Virtual DOM?

Let's conduct a comparative analysis and find out why the Incremental DOM is the right solution for Angular.

How Virtual DOM Works

React is a fairly common framework in which Virtual DOM was first used. The basic idea is as follows:
Each component creates a new VDOM tree whenever it is rendered. React compares the new tree with the previous one, and then makes a set of changes to the browser's DOM to bring it into line with the new VDOM tree.

Virtual DOM has two main advantages:

• The ability to use any programming language to implement the component's rendering function and no need for compilation. React developers mostly write to JSX, but plain JavaScript is fine.
• As a result of component rendering, we get a value, which can be useful for testing, debugging, etc.

Incremental DOM

Incremental DOM is used by Google for internal needs. His main idea is:

Each component is compiled into a set of instructions that create DOM trees and directly update them when the data changes.
For example, this component:

@Component({ selector: 'todos-cmp', template: ` <div *ngFor="let t of todos|async"> {{t.description}} </div> ` }) class TodosComponent { todos: Observable<Todo[]> = this.store.pipe(select('todos')); constructor(private store: Store<AppState>) {} } 

Will be compiled into:

 var TodosComponent = /** @class */ (function () { function TodosComponent(store) { this.store = store; this.todos = this.store.pipe(select('todos')); } TodosComponent.ngComponentDef = defineComponent({ type: TodosComponent, selectors: [["todos-cmp"]], factory: function TodosComponent_Factory(t) { return new (t || TodosComponent)(directiveInject(Store)); }, consts: 2, vars: 3, template: function TodosComponent_Template(rf, ctx) { if (rf & 1) { // create dom pipe(1, "async"); template(0, TodosComponent_div_Template_0, 2, 1, null, _c0); } if (rf & 2) { // update dom elementProperty(0, "ngForOf", bind(pipeBind1(1, 1, ctx.todos))); } }, encapsulation: 2 }); return TodosComponent; }()); 

The template function contains instructions for rendering and updating the DOM. Please note that the instructions are not interpreted by the framework rendering engine. They are the rendering engine.

Benefits of Incremental DOM

Why did Google decide to opt for the Incremental DOM rather than the Virtual DOM?

The task they have set is to make applications show good performance on mobile devices. So, it was necessary to optimize the size of the bundle and the amount of memory consumed.

To solve the above tasks:

• The rendering engine should be tree-shakable
• The rendering engine should not consume a lot of memory

Incremental DOM and tree shakability

When using incremental DOM, the framework does not interpret the component; instead, the component refers to the instructions. If any instruction remains intact, then it will not be used in the future. Since this information is known at compile time, it is possible to exclude unused instructions from the bundle.

An interpreter is required for Virtual DOM to work. At the time of compilation it is not known what part of it will be needed, and which part is not, therefore it is necessary to drive it into the browser entirely.

Incremental DOM and memory consumption

Virtual DOM creates an entire tree from scratch with every re-rendering.

Incremental DOM, on the other hand, does not require memory to re-render the view, unless it makes changes to the DOM. Memory will need to be allocated only if DOM nodes are added or removed, and the amount of allocated memory will be proportional to the changes made to the DOM.

Since most render / template calls do not make any changes (or the changes they make are minor), substantial memory savings are achieved.

Incremental DOM won?

Of course, everything is not so simple. For example, the fact that the render function returns a value provides excellent opportunities, for example, in testing. On the other hand, step-by-step execution of instructions using Firefox DevTools simplifies debugging and performance profiling. The ergonomics of a particular method depends on the framework used and the preferences of the developer.

Ivy + Incremental DOM =?

Angular has always been built on the use of HTML and templates (a couple of years ago I published a post in which I outlined my thoughts in support of this solution and its effectiveness in the long term). That is why the Virtual DOM trump card will never be advantageous for Angular.

Given all this, tree shakability and low memory consumption, I consider it a reasonable choice to use the Incremental DOM as the basis of the new rendering engine.

If you need advice on Angular, information about training or support, you can read about our methods of working with clients here.