Understanding Angular Ivy: Incremental DOM and Virtual DOM

Here at Nrwl, we’ve been sharing a lot of insights about Angular Ivy, as there is anticipation about what it will enable us and our clients to do. Angular Ivy is a new Angular renderer, which is radically different from anything we have seen in mainstream frameworks, because it uses incremental DOM.

What is incremental DOM? How is it different from virtual DOM?

Let’s compare them and see why incremental DOM is the right answer for Angular.

How Virtual DOM Works

React was the first mainstream framework to use virtual DOM, which is defined by this key idea:

Every component creates a new virtual DOM tree every time it gets rerendered. React compares the new virtual DOM tree with the old one and then applies a series of transformations to the browser DOM to match the new virtual DOM tree.

Virtual DOM has two main advantages:

• We can use any programming language to implement the component’s render function, so we don’t need to compile anything. React developers mainly uses JSX, but we can use plain JavaScript as well.
• We get a value as a result of rendering component. It can be used for testing, debugging, etc..

Incremental DOM

Incremental DOM is used internally at Google, and it is defined by this key idea:

Every component gets compiled into a series of instructions. These instructions create DOM trees and update them in-place when the data changes.

For instance, the following component:

Will be compiled into:

The template function contains the instructions rendering and updating the DOM. Note that the instructions aren’t interpreted by the framework’s rendering engine. They are the rendering engine.

Why Incremental DOM

Why did the Google team go with incremental DOM instead of virtual DOM?

They have one goal in mind: applications have to perform well on mobile devices. This mainly meant optimizing two things: the bundle size and the memory footprint.

To achieve the two goals:

• The rendering engine itself has to be tree shakable
• The rendering engine has to have low memory footprint

Why Incremental DOM is Tree Shakable?

When using incremental DOM, the framework does not interpret the component. Instead, the component references instructions. If it doesn’t reference a particular instruction, it will never be used. And since we know this at compile time, we can omit the unused instruction from the bundle.

Virtual DOM requires an interpreter. What part of that interpreter is needed and what part is not isn’t known at compile time, so we have to ship the whole thing to the browser.

Why Incremental DOM Has Low Memory Footprint?

Virtual DOM creates a whole tree from scratch every time you rerender.

Incremental DOM, on the other hand, doesn’t need any memory to rerender the view if it doesn’t change the DOM. We only have to allocate the memory when the DOM nodes are added or removed. And the size of the allocation is proportional to the size of the DOM change.

Since most of render/template calls don’t change anything (or change very little), this can result in huge memory savings.

It’s More Nuanced

Of course, it’s more nuanced. For example, having render return a value provides good affordances, say, for testing. On the other hand, being able to step through instructions using Firefox DevTools makes debugging and perf profiling easier. What ends being more ergonomic depends on the framework and the developer’s preferences.

Ivy and Incremental DOM?

Angular has always been about using html and templates (a few years ago I wrote a post outlining why I think this is the right choice in the long run). That is why, the main advantage of virtual DOM could never apply to Angular.

Given this, plus the tree shakability and memory footprint of incremental DOM, I think it was the right choice to use incremental DOM as the foundation of the new rendering engine.

As always, if you’re looking for Angular consulting, training and support, you can find out more about how we work with our clients here.

Victor Savkin is a co-founder of Nrwl. We help companies develop like Google, Facebook, and Microsoft since 2016. We provide consulting, engineering and tools.

If you liked this, click the 👏 below so other people will see this here on Medium. Follow @victorsavkin to read more about monorepos, Nx, Angular, and React.