Forem: Eugenio Lentini

An introduction to Angular 9 Ivy Compiler

Eugenio Lentini — Sat, 14 Mar 2020 16:09:43 +0000

Lingo
Quick overview
Angular Ivy compiler model
- Compiler enables decoupling
Simple project setup
- Let's compile
- JiT vs. AoT
Compilation models
- TypeScript compilation model
- Angular compilation model
TypeScript transpiler architecture
- Extension points
Compilation steps
Compiler features
- Module compilation scope
- Export compilation scope
- Partial evaluation
- Template type checking
Conclusions
References

Disclaimer
The post contains the thoughts of a preliminary investigation on how Angular works reading some parts of the source code, debugging a simple application and reading how the compiler works. Some terms or definitions could be wrong.

Why does Angular have a compiler at all?
Main job of the compiler is to turn the template you write into the code that runs the Angular runtime.

Alex Rickabaugh - Angular Connect 2019

In Angular, the developer write templates declaratively that is what to render, the binding, etc. but not how it happens at runtime, there is not description about how the change detection mechanism works. The Angular runtime does not understand the declarative template syntax so it has to be translated into something the runtime can run into a browser.

The compiler takes the declarative Angular syntax and turns it into imperative code.

Why, again, a compiler is required? not possible to do by hand?

Lot of boilerplate code, better to focus on the business logic than how things work under the hood.
Angular team can optimise and improve by release w.r.t. browser evolution the imperative code.

A more detailed introduction about Angular Ivy can be found at

Angular Ivy: a detailed introduction

Eugenio Lentini ・ Dec 10 '19 ・ 14 min read

#angular #javascript #webdev #typescript

Lingo

Angular Compiler: part of the Angular rendering architecture that transforms templates and decorators into something that the Angular runtime can understand.
Angular Runtime: part of the Angular rendering architecture that runs an Angular application.
Angular template declarative syntax: describes what the view has to look like, what the view has to display, but not how.
Angular application imperative code: describes how the view has to be rendered via a sequence of JavaScript instructions/commands.
Metadata: set of data enclosed into a decorator that describes the entity represented by the decorator itself. For instance a component has the selector, the template, etc. Metadata are then reused by the compiler and put into the definition files .d.ts, the component API. Basically the metadata help to preserve the information removed from .js files.

Quick overview

The work done on the new Angular compiler can be divided in three categories as stated in the implementation status:

@angular/compiler-cli: TypeScript transformer pipeline which includes two CLI tools
- ngtsc: the Angular TypeScript compiler which looks for the Angular decorators like @Component and substitute them with their specific Angular Runtime instructions/counterparts like ɵɵdefineComponent.
- ngcc: the Angular Compatibility Compiler which converts pre-ivy modules into ivy-module, can be even run as part of a code loader like Webpack to have packages from node_modules transpiled on-the-fly.
@angular/compiler: Ivy Compiler which converts decorators into Ivy.
@angular/core: decorators which can be converted by the @angular/compiler.

Angular Ivy compiler model

The Ivy model foresees to compile the Angular decorators like @Injectable, @Component, etc into static properties.

All the decorators do not need global knowledge of the application, except @Component which requires information coming from @NgModule. In the module other selectors used by the component template are declared and so the transitive closure of the exports of that module imports.

Without those information the component def (ɵcmp) cannot be correctly generated.

Consider the Welcome to Angular! application:

@Component({
  selector: 'app-root',
  template: `
    <div style="text-align:center">
      <h1>
        Welcome to {{ title }}!
      </h1>
    </div>
  `,
  styleUrls: []
})
export class AppComponent {
  @Input() title = 'Angular';
}

The previous code is characterised by decorators like @Component and @Input, part of the Angular template declarative syntax that provides developers with an easy template grammar to both

write control flow statements, like the for loop and if conditional statement,
and make data binding between the variables declared in the controller and used in the templates.

Tip
For most of the developers the binding is just the use of the same variable name between the template and the controller, but there is a mechanism that manages the change detection at runtime. This is a great thing and the Angular compiler automatically adds this mechanism. Less boilerplate code, templates are mode readable and less error prone.

The Angular runtime is a collection of JavaScript instructions/functions able to render a component template into the DOM and to answer to change detection when something in the model has changed (MVC). Everything must be in JavaScript, ready to be run, so the Angular declarative syntax is translated into these instructions.

To make it more clear try to develop a standard Web Component: when the developer has to deal with the template he must deal with the DOM API to create an element and attach it to the DOM, write some code to detect changes in the model and update the view. In the Angular code there is not trace of these operations since a template is translated into JavaScript imperative code, a series of JavaScript instructions, part of the Angular runtime, that, when invoked, creates the component in the browser.

Most of the tedious and repetitive job is done by the Angular compiler in conjunction with the Angular runtime.

Compiler enables decoupling

The developer just writes the Angular modules and components, that is the what, via the Angular declarative syntax but it does not know/care about the how, that is how things are executed at runtime: compiler enables to decouple the what from the how.

This approach has multiple advantages:

minimize or eliminate side effects making the developer life simpler;
if the Angular rendering architecture evolves, small or null changes are required to use the latest version;
browsers change more and more often as the EcmaScript hence the how the templates are rendered can change accordingly optimising web performance for instance;
templates and decorators can be compiled differently w.r.t. the platform where the code is run such ES5 or ES6 with module support.

Simple project setup

Angular 9 has been recently released, generate a simple project with Angular 9 running:

npm install -g @angular/cli     // to install the Angular CLI
ng new angular-nine-ivy         // or the name you want

In case you already have a workspace with some changes you have to commit or stash them, otherwise add the flag --allow-dirty.

If you already have the old Angular CLI, it seems the better way is to uninstall the old one and the install the new globally.

Let's compile

There are two compiler entry points in the @angular/compiler-cli: ngtsc and ngcc.

`ngtsc`

It is the TypeScript to JavaScript transpiler that reifies the Angular decorators into static properties. ngc works like the ngtsc when Ivy is enabled.

`ngcc`

It is the Angular Compatibility Compiler that process the NPM library code from the node_modules folder producing equivalent library code Ivy compatible. ngcc can also be run by a code loader like Webpack to get packages transpiled on demand instead of written in the node_module package folder.

`ngc`

Open the package.json and add the ngc script:

"scripts": {
    "ng": "ng",
    ...
    "ngc": "ngc"
}

In the tsconfig.json set "declaration": true, in order to have the .d.ts files as well, then run:

$ npm run ngc

The result of the component compilation is located at dist\out-tsc\src. The Welcome to Angular! component is translated into:

import { Component, Input } from '@angular/core';
import * as i0 from "@angular/core";
export class AppComponent {
    constructor() {
        this.title = 'Angular';
    }
}
AppComponent.ɵfac = function AppComponent_Factory(t) { return new (t || AppComponent)(); };
AppComponent.ɵcmp = i0.ɵɵdefineComponent({ type: AppComponent, selectors: [["app-root"]], inputs: { title: "title" }, decls: 3, vars: 1, consts: [[2, "text-align", "center"]], template: function AppComponent_Template(rf, ctx) { if (rf & 1) {
        i0.ɵɵelementStart(0, "div", 0);
        i0.ɵɵelementStart(1, "h1");
        i0.ɵɵtext(2);
        i0.ɵɵelementEnd();
        i0.ɵɵelementEnd();
    } if (rf & 2) {
        i0.ɵɵadvance(2);
        i0.ɵɵtextInterpolate1(" Welcome to ", ctx.title, " ");
    } }, styles: [""] });
/*@__PURE__*/ (function () { i0.ɵsetClassMetadata(AppComponent, [{
        type: Component,
        args: [{
                selector: 'app-root',
                template: `
    <div style="text-align:center">
      <h1>
        Welcome to {{ title }}
      </h1>
    </div>
  `,
                styleUrls: ['./app.component.css']
            }]
    }], null, { title: [{
            type: Input
        }] }); })();

and then the app.component.d.ts definition file:

import * as i0 from "@angular/core";
export declare class AppComponent {
    title: string;
    static ɵfac: i0.ɵɵFactoryDef<AppComponent>;
    static ɵcmp: i0.ɵɵComponentDefWithMeta<AppComponent, "app-root", never, { "title": "title"; }, {}, never>;
}

Attention
By default Ivy is enabled, if you disable it you will get a different compilation output.

JIT vs. AoT

Compiler can work in JiT (Just in Time) mode, it is delivered along with the application and compiles at runtime. AoT (Ahead of Time) compilation instead compiles everything at build time making the application faster and it does not required to ship the compiler with the application.

With Angular 9, thanks to Ivy, the compilation is faster and by default "aot": true.

Compilation models

Both TypeScript and Angular Compiler preserve important metadata that cannot be part of the emitted .js files. Angular enhances the .d.ts files with framework specific metadata to be reused for better component type checking.

TypeScript compilation model

JavaScript code has no type information, it is just ready to be executed in the browser. The TypeScript compiler has transformed all the .ts source files but typing information are not totally lost, the definition files help to preserve the interface for future use.

For instance the file library.ts is compiled into library.js and library.d.ts is produced, it describes the interface{: .italic-red-text } or public API{: .italic-red-text } of the library.

The definition file brings type information{: .italic-red-text } to help TypeScript to static type check the usage of the library. Fo example, when an application declare a npm dependency library can then import functionality:

import {AwesomeLib} from 'awesome-lib';
// use the lib

TypeScript will static type check the use of the library in the app.js exploiting the library.d.ts definition file:

declare class AwesomeLib {
    awesomeMethod(): string;
}

Angular Ivy compilation model

An Angular component has some useful information declared in the decorator like the selector. These information are really important to use the component elsewhere and static type check the code.

The Angular Ivy compiler has been improved to not waste this information and to enrich the definition file public interface. For instance, the following Angular component:

@Component({
    selector: 'awesome-comp'
})
export class AwesomeComponent {
    @Input() value: string;
}

will be compiled into JavaScript and the metadata will enrich the definition file as following:

export declare class AwesomeComponent() {
    value: string;
    static ngComponentDef: ng.ComponentDef<
        AwesomeComponent,
        `awesome-comp`,
        {value: 'value'}
    >;
}

The definition file became the component public API{: .italic-red-text }. The compiler can exploit it in order to type check the code that will use it:

<awesome-comp [value]="a value">
    just a component
</awesome-comp>

TypeScript transpiler architecture

The following diagram, thanks to Angular team, shows the normal tsc flow and the steps to transpile a .ts file into the .js one.

                                                                |------------|
                           |----------------------------------> | TypeScript |
                           |                                    |   .d.ts    |
                           |                                    |------------|
                           |
|------------|          |-----|               |-----|           |------------|
| TypeScript | -parse-> | AST | ->transform-> | AST | ->print-> | JavaScript |
|   source   |    |     |-----|       |       |-----|           |   source   |
|------------|    |        |          |                         |------------|
                  |    type-check     |
                  |        |          |
                  |        v          |
                  |    |--------|     |
                  |--> | errors | <---|
                       |--------|

parse: recursive descent parser that produces the abstract syntax tree (AST);
type check: perform type analysis on every file, report found error. Not modified by the ngtsc;
AST to AST: remove type declarations, convert class into ES5, async methods, etc.

Extension points

TypeScript tsc provides some extension points to alter its output:

CompilerHost.getSourceFile to modify the source;
CustomTransformers to alter the list of transforms;
WriteFileCallback to intercept the output before it is written.

Compilation steps

The ngtsc is a wrapper around the tsc, the TypeScript compiler, that extends and modify the normal compilation flow.

Tip
The TypeScript transpiler cannot compile the Angular templates and decorators, so the Angular compiler kicks in to reify Angular decorators into static properties. Once finished the TypeScript compiler can go on producing JavaScript code. In other words the Angular compiler allows the code written in Angular declarative syntax to participate to the TypeScript compilation process.

1. Program creation

Starting from the tsconfig.json file, the TypeScript process discover the application source files via the import statements.

2. Analysis

The Angular compiler takes all the .ts files collected and, class by class, looks for Angular declarative syntax code, basically Angular things. The compiler gathers isolation information about components for instance, but not about modules. Remember, for the @Component the compiler requires a global knowledge about the module due transitive closure resolution of the exports of the component module template imports used in the component template.

3. Resolve

The Angular compiler looks again at the whole application but this time in a larger picture including modules as well. All the code now is understandable and parsable by the next step of the TypeScript compiler. Optimizations will take place at this step.

4. Type checking

TypeScript checks error in the application, templates included, that now are a series of imperative instructions.

5. Emit

The most expensive operation in the compilation process, the TypeScript code is transformed into JavaScript ready to be run by the browser. Angular component classes have now only imperative code to describe what a template looks like.

Compiler features

Angular compiler has many interesting features, some of them have been enhanced and improved with the new Angular Ivy architecture. Let's see some of them.

Module compilation scope

The module scope allows the compiler to resolve uniquely the Angular components used by the application. Consider the following application module:

@NgModule({
    declarations: [
        AppComponent,
        HelloComponent
    ]
})
export class AppModule {}

The module decorator property declarations is the module compilation scope, it holds an array of Angular components used in the application templates. The HelloComponent is a component coming from a library with its own definition file enriched with metadata as seen before.

The developer declares the willingness to use the component in the array, then can use the component adding the corresponding selector in one of the application templates.

The compiler can than uniquely match the component, verify the use of the selectors along with its attributes.

Export compilation scope

A module can be used to export Angular components as a method to make visible the external world some implemented components.

Tip
The module pattern is quite frequently used in computer languages as a way to separate a complex application in small chunks that can be reused elsewhere. Just think about ESM or CommonJS etc. Angular provides a way to create a modular application via the module concept as well. A module is used also to hide implementation details and to select what should be public. The exports property is the way chosen to make Angular component public so re-usable by the rest of the world.

In the following example the HelloModule both declares and exports the HelloWorld component. The module library just implements one component and exports it to all the applications that want to use it:

@NgModule({
    declaration: [HelloComponent],
    exports: [HelloComponent]
})
export class HelloModule {}

When an application wants to use the HelloWorld component has just to declare it:

@NgModule({
    declarations: [
        AppComponent,
        HelloComponent
    ]
})
export class AppModule {}

The compiler then can:

uniquely find the component definition;
figure out from the template which components are used;
generate the code and reference it accordingly;
help the tree-shaker to remove things that are not referenced.

Partial evaluation

Compiler actually attempt to almost run TypeScript code in decorators

Alex Rickabaugh - Angular Connect 2019

Angular compiler contains almost a complete TypeScript interpreter. In the following example:

import {SOME_MODULES} from './some_module';

@NgModule({
    declarations: [HelloComponent, ByeComponent],
    exports: [HelloComponent, ByeComponent],
    imports: [...SOME_MODULES]
})
export class AnotherModuel {...}

the compiler can follow and evaluate the import references. Some evaluation are just partial since there are not enough information at compiler time.

For instance:

import {SOME_MODULES} from './some_module';

@NgModule({
    imports: [SOME_MODULES.modules]
})

export const SOME_MODULES = {
    modules: [HelloModule, ByeModule],

    // not available at compile time
    viewportSize: {
        x: document.body.scrollWidth,
        y: document.body.scrollHeight
    }
}

only at runtime some values will available. This value are dynamic expressions. The compiler sees the previous object more or less like this:

SOME_MODULES: {
    "modules": [
        Reference(HelloModule),
        Reference(ByeModule)
    ],
    "viewportSize": {
        x: DynamicValue(document.body.scrollWidth),
        y: DynamicValue(document.body.scrollHeight)
    }
}

where:

SOME_MODULES is an object with two properties;
DynamicValue is an indicator to say "cannot get past".

The compilation does not stop, it goes on since a situation like this could be quite common.

import {SOME_MODULES} from './some_module'
@Component({
    styles: [`
        :host {
            width: $SOME_MODULES.viewportSize.x
        }
    `]
})

While the compilation goes on for modules properties, it cannot for viewportSize since the value cannot be figured out. An explicative error message is produced about styles.

Template type checking

A template and expressions

<account-view
    [account]="getAccount(user.id, 'primary') | async">
</account-view

they are compiled into TypeScript code becoming type check blocks. So blocks are sent to TypeScript compiler and possible errors are then return in the context of the template.

function typeCheckBlock(ctx: AppComponent) {
    let cmp!: AccountViewCmp;
    let pipe!: ng.AsyncPipe;

    cmp.account /*273,356*/ = (pipe.transform(
        ctx.getAccount((ctx.user /*311,315*/).id /*311,318*/,
        "primary" /*320,329*/)
        /*300,331*/)
    /*300,338*/) /*289,339*/;
}

How is it possible to return an error in the context of a template? Well, code is translated with additional offset comments that allows then the contextualization.

Example

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  template: `
    <div style="text-align:center">
      <h1>
        Welcome to {{ title }}!

        <tr *ngFor="let hero of heroes">
            <td>{{hero.name}}</td>
        </tr>
      </h1>
    </div>
  `,
  styleUrls: []
})
export class AppComponent {
  @Input() title = 'Angular';

  heroes = 'fake array';
}

Angular version 9 with Ivy enabled maintains the behavior of the fullTemplateTypeCheck flag and introduces a strict mode with the flag strictTemplates that goes beyond the Angular 8 type checker. Activate the strict mode in the tsconfig.json:

...
"angularCompilerOptions": {
    "fullTemplateTypeCheck": true,
    "strictTemplates": true,
    ...
}

Re-run the npm run ngc and get a full better error reported by the compiler:

src/app/app.component.html:7:13 - error NG2339: Property 'name' does not exist on type 'string'.

7       <td>{{hero.name}}</td>
              ~~~~~~~~~

  src/app/app.component.ts:5:16
    5   templateUrl: './app.component.html',
                     ~~~~~~~~~~~~~~~~~~~~~~
    Error occurs in the template of component AppComponent.

More details available on the template type-check page.

Conclusions

The Angular 9 Ivy rendering architecture introduces a new compiler and a new rendering engine not only to exploit the incremental DOM technique but also a more powerful compiler.

Ivy is enabled by default, --aot is the default way of developing since the new compiler is faster than the previous one. Having AoT mode enable by default reduces also the risk of discrepancies between development and production code.

Ivy compiler goes even further, it has a better type-check making the reported error much more explicative and easier for the developer to identify the root cause of the issue.

We all are looking forward to see the new compiler applied to Angular Elements.

References

Angular Compiler Architecture

Tools

Angular 8 Bootstrap in deep

Eugenio Lentini — Mon, 23 Dec 2019 19:09:48 +0000

Slides
Lingo
The plan
Browser DOM
- DOM rendering is slow
Virtual DOM
- What Virtual DOM looks like
- How React uses the virtual DOM
Incremental DOM
Angular compiler
- Angular component
- Browser cannot render an Angular component
Angular vs. browser
- Browser role
- Angular role
Analyze the compiled code
- Set up the compilation task
- One and simple component
- Module factory function
- What is going to happen
- Component factory function
How Angular application bootstraps
- 0. IIEF
- 1. Platform
- 2. Application
- 3. Root component
- 4. Create nodes
- 5. The renderer
Conclusions
References

The Angular bootstrap sequence starts after the load of the index.html and the JavaScript bundles produced by Webpack. Angular Runtime creates the platform where the application can be started and finally the root component is rendered.

What follows is related to Angular View Engine and experimented on Angular 8.2.9.

View Engine is going to be replaced by Angular Ivy in version 9, detail introduction can be found in this other blog post

Angular Ivy: a detailed introduction

Eugenio Lentini ・ Dec 10 '19 ・ 14 min read

#angular #javascript #webdev #typescript

Slides

This post comes along with a presentation written in markdown, rendered via reveal.js and available on GitHub.

Lingo

Angular View Engine:{: .italic-violet-text} Angular rendering architecture (compiler and runtime) introduced in version 4 and substituted with Ivy in Angular version 9.
Angular compiler:{: .italic-violet-text} compiles templates and decorators into a code the runtime can execute.
Angular runtime:{: .italic-violet-text} execute the JavaScript code produced by the compiler to run the application.
Object Model (OM):{: .italic-violet-text} a way to model via object-oriented techniques (objects, classes, interfaces, properties, inheritance, encapsulation, etc) a system for development purpose. For instance, Apache POI implements an OM of Microsoft Excel that manipulates via a Java API.
Data Model (DM):{: .italic-violet-text} it represents entities at the database level, it deals with table schema, relationships between tables (FKs, PKs) but not advanced object-oriented concepts like inheritance or polymorphism. DM represents how OM classes are stored in a database.
DOM:{: .italic-violet-text} an object-oriented representation of an HTML document in a tree fashion that can be manipulated via the DOM API, for instance HTMLButtonElement is one of the DOM interfaces.
Shadow DOM:{: .italic-violet-text} it allows to separate DOM into smaller and encapsulated object-oriented representations of a HTML element.
Tree and nodes:{: .italic-violet-text} the DOM is organized in a logical tree where its nodes are the components or HTML elements.
Rendering/painting:{: .italic-violet-text} the browser process that transform the DOM into the UI.
Virtual DOM:{: .italic-violet-text} the virtual representation of the real DOM.
Diffing:{: .italic-violet-text} operation that compare two Virtual DOM.
Incremental DOM:{: .italic-violet-text} a technique to render and update an Angular component when change detection is fired.

The plan

Hello Reader, this is a long post so feel free to skip certain sections I have used to introduce and give a more complete context to the Angular bootstrap sequence that is the goal :bowtie:

The post starts with an introduction about the DOM and two rendering strategies{: .italic-red-text} used to speed up the page repainting. The incremental DOM strategy is the base of the Angular rendering architecture.

The Welcome to Angular simple application will help to introduce and talk about the Angular compiler, why and how the Angular declarative syntax is transformed into JavaScript code that can be executed by the Angular runtime in the browser. A deep look into the generated code and the Angular source code will show how the framework creates the DOM element and answer to change detection.

Some of the content and mechanisms has been changed with the introduction of the new rendering architecture called Angular Ivy.

Browser DOM

The Document Object Model (DOM) connects web pages to scripts or programming languages by representing the structure of a document such as the HTML representing a web page in memory.

MDN - Mozilla Developer Network

Tip
The HTML document is represented in an object-oriented fashion, as objects in a logical tree, by the DOM that also provides the API to manipulate those objects.

The DOM rendered gives the HTML page visible to the end-user.

DOM rendering is slow

Being the DOM represented as a tree, it makes easier to change and update it. What the user sees is the result of the DOM rendering operation that is the slow part. More a page or a component is complex more could take time to render it.

A page is usually made of many components, complex and non-complex. Every time one of them changes the all page (or a big part of it) needs to be re-rendered, a really expensive operation.

Tip
Frequent DOM manipulations make the user interface slow since the re-painting of the user interface is the most expensive part. In general, it is something that is not considered when the page is going to be implemented. For instance, changing the visibility of an element forces the browser to verify/check the visibility of all other DOM nodes.

Actions like changing visibility or the background of an element trigger a repaint. A simple click of the user could correspond to many different actions behind the scene and so many repainting actions slowing down the web page.

Two different techniques have been developed to overcome the rendering issue for complex web applications: Virtual DOM and Incremental DOM.

Virtual DOM

The key idea is to render the DOM the least possible{: .italic-red-text }. When a change detection occurs, instead of updating the real DOM, frameworks like React updates a Virtual DOM.

The Virtual DOM is a tree as well, made of nodes that are the page elements. When a new element is added/removed a new Virtual DOM is created, the difference between the two trees is calculated.

A transformations series is calculated to update the browser DOM so that it matches{: .italic-red-text } the latest new Virtual DOM. These transformations are both the minimal operations to be applied to the real DOM and the ones that reduce the performance cost of the DOM update.

Internals
The rendering process happens only on the difference. The bulk changes to be applied are optimized to improve the performance cost.

What Virtual DOM looks like

The Virtual DOM is something not official, no specification is provided differently from DOM and shadow DOM.

It is a copy of the original DOM as a plain JavaScript object (JSON) so that it can be modified how many times we want without affecting the real DOM. Virtual DOM can be divided in chunks so that it is easier to diffing the changes.

Example

When a new item is added to an unordered list of elements a copy of the Virtual DOM containing the new element is created.

The diffing process collects the differences between the two Virtual DOM objects so changes can be transformed in a bulk update against the real DOM.

Tip
No distinction about reflow (element layout that is position recalculation and geometry) and repaint (element visibility) has been done so far since most of the considered actions involve the repaint operation.

How React uses the Virtual DOM

In React a user interface is made of a set of components, each component has a state. For instance, the state of a drop-down menu is the array of the available elements and the current selected one.

Via the observer pattern React listens to state change to update the Virtual DOM. The diffing process makes React aware of which Virtual DOM objects have changed, only those objects will be updated in the real DOM.

Tip
As the developer you don't need to be aware of about how DOM manipulation happens at each state change. React does the job optimizing the performance cost behind the scenes.

React reduces the re-painting cost applying updates in bulk not at every single state change.

The great advantage of using the Virtual DOM is that we don't need any compiler. JSX, for instance, is really close to JavaScript, the key point is the render function that can be implemented using any programming language.

Virtual DOM drawbacks

The Virtual DOM required an interpreter to interpret the component. At compile time no way exists to know which parts of the interpreter will be required at runtime, so the whole stuff has to be loaded by the browser.
Every time there is a change, a new Virtual DOM has to be created, maybe a chunk and not the whole tree, but the memory footprint is high.

Incremental DOM

The key idea of the incremental DOM is:

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

Victor Savkin - Understanding incremental DOM

Each component is then compiled into two main instruction sequences:

view creation: invoked the first time the page is rendered, add the component to the DOM;
change detection: invoked at every state change to update the component into the DOM.

The advantages of the Incremental DOM are a low memory footprint and a skinny interpreter/runtime tailored on the compiled application.

Angular Ivy
The Incremental DOM strategy is already present in the Angular View Engine. As it will be shown, each component is compiled into a creation function and an update function. Angular Ivy goes further, it allows the tree-shaking of the Angular runtime that is not possible with the current rendering architecture.

Angular compiler

An Angular application is mainly made by Angular components organized in a tree fashion. Each component is implemented to accomplish a certain mission, for instance, the navigation bar, the drop-down menu, etc.

Angular component

An Angular component is characterized by a class, TypeScript code that expresses the logic, and a decorator that allows defining some metadata such as the selector, the template, etc. The HTML template represents the presentation layer of the component and it is implemented using a specific Angular declarative syntax.

Tip
When the developer writes a component uses TypeScript and the Angular declarative syntax for the template to bind a variable from the logic to the presentation layer and vice versa. Pay attention that no change detection is required to be added. Change detection works at runtime thanks to the compiler that adds it during the compilation phase.

Example

Consider a very simple component, the template can be inline or separated:

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent {
  title = 'a simple component';
}

A template is a bunch of HTML code with binding variables to present{: .italic-red-text }, with a certain look and feel, some content.

<div style="text-align:center">
  <h1>
    Welcome to {{ title }}!
  </h1>
</div>

Browser cannot render an Angular component

The browser is the execution environment, it loads the application and executes it. Unfortunately it cannot execute an Angular component as it is.

Tip A browser can interpret JavaScript and render HTML but not if written using the Angular declarative syntax.
Angular provides a compiler that, together with the TypeScript one, transforms "everything in something else" that a browser can understand.

During the build of an Angular project, two compilers come into play with different purposes:

tsc is the TypeScript compiler and generates the JavaScript w.r.t. the target specified in the tsconfig.json, for instance target: es2015.
ngc is the Angular compiler that translates the templates and decorators into JavaScript. The Angular compiler can work in two different modes:
- Ahead-of-Time (AoT): work at build time so that the templates are bundled along with the application, suitable for production.
- Just-in-Time (JIT): templates are not pre-compiled, the compiler comes along with the application, it is loaded by the browser and does the work at runtime, suitable for development.

Internals
During the development phase ng serve provides live reload functionality.
The process goes through @ngtools/webpack, compiled code is not saved to disk, everything is consumed in memory via streams and emitters.

Angular vs. browser

What are then the roles of the browser and Angular?

Once the Angular application has been fully transformed into JavaScript (HTML templates included), WebPack bundles it along with library dependencies in order to improve performance and load times.

Browser role

The browser role is to load the index.html and to provide the execution environment, the render and the event loop.

<!DOCTYPE html>
<html lang="en">
  <head>
    ...
  </head>
  <body>
    <app-root></app-root>

    <script src="runtime-es2015.js" type="module"></script>
    <script src="polyfills-es2015.js" type="module"></script>
    <script src="styles-es2015.js" type="module"></script>
    <script src="vendor-es2015.js" type="module"></script>
    <script src="main-es2015.js" type="module"></script>

    <!-- nomodule defer -->
    <script src="runtime-es5.js" nomodule defer></script>
    ...
  </body>
</html>

The scripts can be loaded both by modern browsers that supports ESM modules and by old ones that do not support modules via nomodule defer attributes.

Angular role

Consider an Angular application made of only the component previously introduced. The main-es2015.js contains the fully bundled application while runtime-es2015.js is the Angular runtime. Finally third party libraries and styles.

Tip
The transformed HTML template into JavaScript becomes a series of instructions that, once called, render the page building the components.
Skipping some details, roughly an element is a factory function that uses the injected Angular renderer to render the element w.r.t. the browser platform.

The Angular runtime bootstraps the AppModule that, in turn, creates and renders the root element of the application <app-root>. The file main-es2015.js contains the view definition factories produced by the compiler and enriched by Webpack.

Internals
If the browser platform is chosen, @angular/platform-browser, the element will be rendered creating the HTML code into the DOM via the Document interface: document.createElement(). When something changes, the element will update itself calling the update function.

Angular Ivy
The compilation process of View Engine produces .metadata.json and .ngfactory.js files. With Angular Ivy no more special files are produced, too complex to manage and to merge them. Ivy instructions are directly put into the component, a component knows how to create and update itself.

Analyze the compiled code

Let's see how to compile the application invoking only the ngc compiler and nothing else to inspect the compiled code easily and see where the generated JavaScript code invokes the DOM API to create the element.

Tip
The HTML template has been compiled into a sequence of JavaScript instructions that will be executed by the Angular runtime. The goal of the coming sections is to find where the document.createElement() is invoked after the different Angular entities (platform, application, and component) have been instantiated.

Setup the compilation task

Open the package.json file and add:

"scripts": {
  ...
  "compile": "ngc"
},

then in the tsconfig.json enable the d.ts files generation to have the TypeScript definitions:

"compilerOptions": {
  ...
  "declaration": true,
  ...
}

One and simple component

Create a new Welcome to Angular application via the Angular CLI.

The module and the component

The module is as follows:

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

then the component of the Welcome to Angular application:

@Component({
  selector: 'app-root',
  template: `
    <div style="text-align:center">
      <h1>
        {% raw %}Welcome to {{ title }}!{% endraw %}
      </h1>
    </div>
  `,
  styleUrls: []
})
export class AppComponent {
  @Input() title = 'Angular';
}

Compile

Run the command npm run compile and look into the folder dist/out-tsc/src/app where everything has been transformed into JavaScript and saved to disk.

The Angular compiler has produced some files, skip the .metadata and .d.ts ones:

app.module.js               // module class
app.module.ngfactory.js     // module factory, transformed metadata decorator
app.component.js            // component class
app.component.ngfactory.js  // component factory, transformed metadata decorator

Module factory function

The app.module.ngfactory.js contains the factory function creator:

import * as i0 from "@angular/core";
import * as i1 from "./app.module";
import * as i2 from "./app.component";
import * as i3 from "./app.component.ngfactory";
...
var AppModuleNgFactory = i0.ɵcmf(i1.AppModule, [i2.AppComponent], function(_l) {...}
...

Warning
The functions produced by the Angular template compiler start with ɵ to clearly warn to not use them because for sure the code will change soon in the future.

The function ɵcmf stands for create module factory, the map between the name and the real function is defined in the following static map object Map<ExternalReference, any>:

function createBuiltinExternalReferencesMap() {
  const map = new Map<ExternalReference, any>();
  ...
  map.set(Identifiers.createModuleFactory, ɵcmf);
  ...
  return map;

Angular Ivy
The aforementioned map object is one of the reasons why the View Engine is not tree-shakable. Angular Ivy should get rid of or change how this static map is defined to allow the runtime to be tree-shaken by any open-source tool.

What is going to happen

The compiler has transformed the decorators, @NgModule and @Component, into JavaScript instructions. Now "imagine" that the TypeScript class has been transpiled into JavaScript and the @Component decorator that decorates the class became the factory that tells Angular runtime how to create the component into the DOM (create view) and how to update it (change detection). The @NgModule decorators will tell the Angular runtime how to instantiate the application module and get service providers injected.

The module factory function will create an application object that, in turn, will bootstrap the application module and finally the root component.

Module factory implementation

The module factory function ɵcmf creates the module factory object AppModuleNgFactory previously shown. here the implementation:

export function createNgModuleFactory(
    ngModuleType: Type<any>, bootstrapComponents: Type<any>[],
    defFactory: NgModuleDefinitionFactory): NgModuleFactory<any> {
      return new NgModuleFactory_(ngModuleType, bootstrapComponents, defFactory);
    }

it implements the following interface:

export abstract class NgModuleFactory<T> {
    abstract get moduleType(): Type<T>;
    abstract create(parentInjector: Injector|null): NgModuleRef<T>;
}

Module creation

The module factory object can create a module of type AppModule defined in the class app.module.js, that will bootstrap a component of type AppComponent defined in the file app.component.js.

The defFactory is a module defintion function, ɵmod, used by the create method to produce the real module object. It contains an array of ɵmpd module provider definitions that, for instance, tell which sanitizer or producer has to be created and injected:

...
var AppModuleNgFactory = i0.ɵcmf(i1.AppModule, [i2.AppComponent], function(_l) {
  return i0.ɵmod([
    ...
    i0.ɵmpd(4608, i5.DomSanitizer, i5.ɵDomSanitizerImpl, [i4.DOCUMENT]),
    i0.ɵmpd(6144, i0.Sanitizer, null, [i5.DomSanitizer]),
    ...
    i0.ɵmpd(6144, i0.RendererFactory2, null, [i5.ɵDomRendererFactory2]),
    ...
  ]
}

Component factory function

Open app.component.ngfactory.js and look at ɵccf or create component factory function:

import * as i1 from "@angular/core";
import * as i2 from "./app.component";
...
var AppComponentNgFactory = i1.ɵccf(
  "app-root",
  i2.AppComponent, /* class or type */
  View_AppComponent_Host_0, /* factory that produces the app-root, component host, the node defintion */
  {},
  {},
  []
);

it is defined as follows:

export function createComponentFactory(
    selector: string, componentType: Type<any>, viewDefFactory: ViewDefinitionFactory,
    inputs: {[propName: string]: string} | null, outputs: {[propName: string]: string},
    ngContentSelectors: string[]): ComponentFactory<any> {

  return new ComponentFactory_(
      selector, componentType, viewDefFactory, inputs, outputs, ngContentSelectors
    );
}

The factory function is similar to module one except for some more parameters. A component can have @Input() and @Output properties and hence the arrays inputs and outputs.

Tip
It starts to be more and more clear how the component declaration is transformed into a set of arguments used by a factory to programmatically create the component at runtime.

Compiled template

What happened to the template? This is why you have read so far... I hope 😅

The component template has been transformed into a JavaScript object with the following interface:

export interface ViewDefinition extends Definition<ViewDefinitionFactory> {
  flags: ViewFlags;
  updateDirectives: ViewUpdateFn;
  updateRenderer: ViewUpdateFn;
  handleEvent: ViewHandleEventFn;
  nodes: NodeDef[];
  nodeFlags: NodeFlags;
  rootNodeFlags: NodeFlags;
  lastRenderRootNode: NodeDef|null;
  bindingCount: number;
  outputCount: number;
  nodeMatchedQueries: number;
}

The view definition ɵvid with the app-root host selector:

export function View_AppComponent_Host_0(_l) {
  return i1.ɵvid(
    0,
    [
      (_l()(),
        i1.ɵeld(
          0,0,null,null,1,"app-root",[],null,null,null,
          View_AppComponent_0,RenderType_AppComponent
        )),
      i1.ɵdid(1, 49152, null, 0, i2.AppComponent, [], null, null)
    ],
    null,
    null
  );
}

Host selector since the component is attached/hosted by the selector, the Angular component is a directive, hence the view definition is characterized by (links point to the Angular source code on GitHub):

element definition, ɵeld, the app-root, the function produces an ElementDef;
directive definition, ɵdid, the directive that represents the component, the function directiveDef produces an object of type NodeDef.

Both produced objects are of type NodeDef.

The element definition ɵeld references then View_AppComponent_0, the other JavaScript code that represents the component template:

export function View_AppComponent_0(_l) {
  return i1.ɵvid(0,
    [
      (_l()(),
      i1.ɵeld(0, 0, null, null, 1, "h1", [], null, null, null, null, null)),
      (_l()(), i1.ɵted(1, null, ["Welcome to ", "!"]))
    ],
    null,
    function(_ck, _v) {
      var _co = _v.component;
      var currVal_0 = _co.title;
      _ck(_v, 1, 0, currVal_0);
    }
  );
}

The ɵvid, viewDef function, takes two view update functions: updateDirectives and updateRenderer for the change detection along with the function to create the element the first time the application is loaded.

Tip
In a view definition function ɵvid there are two interesting things:

NodeDef[] array of nodes that is responsible of the view creation;
updateDirectives and updateRenderer functions responsible of the change detection update.

Angular Ivy
In Angular Ivy there are no more .ngfactory.js files, all the required code for view creation and change detection is inside the component. Imho the incremental DOM if fully implemented in Ivy, what is missing in View Engine is the possibility to tree-shake the runtime to squeeze it as much as possible.

How Angular application bootstraps

Once the compiled code has been analyzed, it is interesting to see the call sequence to the Angular runtime to find which function renders the component. At the end of the sequence there must be the sought after document.createElement() function call to the DOM API.

Build the application and start a live server to debug it into the browser:

ng build --aot
npx http-server dist/test-ivy

The Angular AOT compiler extracts metadata to interpret the parts of the application that Angular runtime is supposed to manage.

Basically, the compiler manages metadata interpretation and template compilation that can be controlled specifying some template compiler options in the tsconfig.json.

Angular Ivy
Activate the Ahead-of-Time compilation to have everything in JavaScript and saved to disk make it easier to inspect the generated code. With Angular Ivy --aot is not necessary anymore since it is activated by default. Ivy compilation is so fast that AoT compilation can be always used.

0. IIEF

The application starts in the file main-es2015.js. The option --aot contributes to some optimizations, bootstrapModule is replaced by bootstrapModuleFactory as you can observe from the file main-aot.ts:

import { platformBrowser } from '@angular/platform-browser';

import { AppModuleNgFactory } from './app.module.ngfactory';

// *** Follow bootstrapModuleFactory() ***
platformBrowser().bootstrapModuleFactory(AppModuleNgFactory);

Pay attention: in each piece of code there is a comment that allows following the bootstrap call sequence // *** Follow.

Tip
When invoking the ng build and not simply the compiler as done before, Webpack bundles what has been produced by the compiler, so opening the files results in a slightly different code.

Basically the IIEF function bootstraps the platform PlatformRef, that, in turn, instantiates the application ApplicationRef and then the module along with all the required injectable providers. Finally, the component is created and rendered into the DOM.

Internals
The application code is composed of app.module.ts and app.component.ts. First Angular runtime has to be started, then it creates the platform linked to the page, starts the application that is the module. Once the module has been started the component can be instantiated and rendered.

1. Platform

The Angular platform PlatfromRef is the entry point for Angular on a web page. Each page has exactly one platform and services bound to its scope. A page's platform is initialized implicitly when a platform is created via a platform factory (e.g. platformBrowser).

class PlatformRef {
    ...
    /**
     * Creates an instance of an `\@NgModule` for the given platform
     * for offline compilation.
     */
    bootstrapModuleFactory(moduleFactory, options) {
      // Note: We need to create the NgZone _before_ we instantiate the module,
      ...
      return ngZone.run((
        const ngZoneInjector = Injector.create(
          {providers: providers, parent: this.injector, name: moduleFactory.moduleType.name});

        // from here the ApplicationRef is created and available to be injected
        const moduleRef = InternalNgModuleRef<M>moduleFactory.create(ngZoneInjector);
        ...
        // *** Follow _moduleDoBootstrap() ***
        // moduleType: *class AppModule*
        this._moduleDoBootstrap(moduleRef);
        return moduleRef;
        ...
      ));
    }
    ...
    /**
     * Bootstrap all the components of the module
     */
    _moduleDoBootstrap(moduleRef) {
      ...
      const appRef = moduleRef.injector.get(ApplicationRef) as ApplicationRef;
      ...
      // loop over the array defined in the @NgModule, bootstrap: [AppComponent]
      moduleRef._bootstrapComponents.forEach((
        // *** Follow bootstrap() ***
        // bootstrap the root component *AppComponent* with selector *app-root*
        f => appRef.bootstrap(f)));
      ));
    }
}

Basically change detection is managed by Zone.js that run the module bootstrap. ApplicationRef reference is created and then it bootstraps the AppComponent component.

2. Application

The ApplicationRef reference represents an Angular application running on a page.

  class ApplicationRef {
      ...
      /**
       * Bootstrap a new component at the root level of the application.
       * When bootstrapping a new root component into an application, Angular mounts the
       * specified application component onto DOM elements identified by the componentType's
       * selector and kicks off automatic change detection to finish initializing the component.
       */
      bootstrap(componentOrFactory, rootSelectorOrNode) {
        ...
        /**
         * Use the componentFactory to create the root element app-root having this information:
         * componentType: class AppComponent
         * viewDefFactory: View_AppComponent_Host_0()
         * selector: app-root
         */
        // *** Follow create() ***
        const compRef = componentFactory.create(Injector.NULL, [], selectorOrNode, ngModule);
        ...
      }
  }

3. Root component

Build the root component:

  class ComponentFactory_ extends ComponentFactory {
    ...
    create(injector, projectableNodes, rootSelectorOrNode, ngModule) {
      const view = Services.createRootView(injector, projectableNodes || [], rootSelectorOrNode, viewDef, ngModule, EMPTY_CONTEXT);
    }
  }

Basically the Angular component_factory.ts holds the base class method to create a component of a certain type:

class ComponentFactory_ extends ComponentFactory<any> {

  viewDefFactory: ViewDefinitionFactory;

  /**
   * Creates a new component.
   */
  create(
      injector: Injector, projectableNodes?: any[][], rootSelectorOrNode?: string|any,
      ngModule?: NgModuleRef<any>): ComponentRef<any> {
    if (!ngModule) {
      throw new Error('ngModule should be provided');
    }
    const viewDef = resolveDefinition(this.viewDefFactory);
    const componentNodeIndex = viewDef.nodes[0].element !.componentProvider !.nodeIndex;
    // *** Follow createRootView() ***
    const view = Services.createRootView(
        injector, projectableNodes || [], rootSelectorOrNode, viewDef, ngModule, EMPTY_CONTEXT);
    const component = asProviderData(view, componentNodeIndex).instance;
    if (rootSelectorOrNode) {
      view.renderer.setAttribute(asElementData(view, 0).renderElement, 'ng-version', VERSION.full);
    }

    return new ComponentRef_(view, new ViewRef_(view), component);
  }
}

Basically the implementation uses the function resolveDefinition() to load the view definition. This function will be used many times around the code. The createRootView() function creates a ViewData object that contains the information that will be used later on to render the node into the DOM.

4. Create nodes

The code is going to arrive at the point where the DOM API is called to create and attach the element to the DOM.

function createRootView(root, def, context) {
  const view = createView(root, root.renderer, null, null, def);
  initView(view, context, context);
  // *** Follow createViewNodes() ***
  createViewNodes(view);
  return view;
}

the function function createViewNodes(view: ViewData){...} creates a DOM element w.r.t. its type:

function createViewNodes(view) {
  const nodes = view.nodes;
  for (let i = 0; i < def.nodes.length; i++) {
    switch (nodeDef.flags & 201347067 /* Types */) {
      case 1 /* TypeElement */:
        // H1 DOM element of type any, the function calls the DOM renderer to render the element
        // *** Follow createElement() ***
        const el = (createElement(view, renderHost, nodeDef)));
        ...
        // View_AppComponent_0()
        const compViewDef = resolveDefinition(((nodeDef.element)).componentView)));
        ...
        break;
      case 2 /* TypeText */:
        ...
        break;
      ...
    }
  }
}

5. The renderer

The createElement function will use the injected renderer to create the element.w.r.t. the platform where the application runs.

In case of PlatformBrowser, the DefaultDomRenderer2 class invokes the document interface method to create the real DOM element. DefaultDomRenderer2 extends and implements abstract class Renderer2.

createElement(name: string, namespace?: string): any {
    if (namespace) {
      // In cases where Ivy (not ViewEngine) is giving us the actual namespace, the look up by key
      // will result in undefined, so we just return the namespace here.
      return document.createElementNS(NAMESPACE_URIS[namespace] || namespace, name);
    }

    // *** FOUND ***
    return document.createElement(name);
  }

Tip
An HTML template is transformed in an intermediate format or Object Model by the Angular compiler.
Factory functions are automatically generated by the compiler and they are able to produce an object that can create a component or a node or a module. Then a renderer, specified by the chosen platform, will produce DOM elements in case of a DOM renderer.

Conclusions

It has been shown how the Angular compiler transforms the Angular declarative syntax and the decorators into something the Angular runtime can execute. The Angular compiler and the runtime constitute the rendering architecture.

A developer can use a simple syntax without worrying about change detection and performance optimization w.r.t. the DOM updates since the Angular framework, behind the scenes, does all the job. When new optimizations are available can be got transparently and effortlessly.

One of the big issues with the current rendering architecture, View Engine, is to not be tree-shakable and difficult to expand. Angular Ivy will solve all these issues being composed by an instruction set that can be easily expanded and tree-shaken to avoid the delivery of the full Angular runtime to the browser as today.

References

DOM

Virtual DOM

Angular compiler

Incremental DOM and Ivy

Zone

I reverse-engineered Zones (zone.js) and here is what I’ve found

Angular Ivy: a detailed introduction

Eugenio Lentini — Tue, 10 Dec 2019 20:15:46 +0000

Slides
Lingo
Rendering architecture
- Virtual DOM
- Incremental DOM
Enable Angular Ivy
- Enable Ivy in an existing project
- New project with Ivy
- Disable Ivy
Angular Ivy compilation
What Angular Ivy enables
- Tree-shaking
- Incremental compilation
- Locality
- Example: Ivy library compilation
- Flexibility
Angular Ivy build pipeline
Component lazy loading feature
Bundle size
Debugging
Conclusions
References

Angular Ivy is the new rendering architecture that comes, by default, with version Angular 9. The Angular rendering architecture is not new to a complete revamp, Angular 2.0, Angular 4.0 and now Angular 9.0 have introduced new compilers and runtime engines.

Currently, Angular stable version is 8.2.14 and Angular 9 is in RC5.

Slides

This post comes along with a presentation written in markdown, rendered via reveal.js and available on GitHub.

Lingo

Rendering architecture: compiler and runtime engine pipeline that allows an Angular application to be executed.
Runtime rendering function set/instruction set: set of JavaScript functions understandable by runtime, templates, and decorators are transformed into a sequence of instructions.
Virtual DOM and incremental DOM: techniques to create and update a component in the DOM.
View Engine: rendering architecture introduced in Angular 4,
angular.json is the workspace or build configuration file.
tsconfig.app.json is the project configuration file.
.ngfactory.js suffix for decorator factory files, class decorators like @Component is translated by the compiler into external files.
Locality: compiler should use only information from the component decorator and its class.
Global compilation: compilation process requires global static analysis to emit the application code.

Rendering Architecture

What is rendering architecture? It is the pair compiler:runtime. Angular framework is composed of two main parts:

compiler to transform templates written in Angular declarative syntax into JavaScript instructions enriched with change detection;
runtime to execute the application code produced by the compiler.

Currently, Angular 8 uses as rendering architecture called View Engine:

View Engine has been introduced with Angular version 4 and still used in version 8, but some limitations have been identified
- no tree-shakable: both the Hello World application and a very complex one are executed by the same and full runtime. If the internationalization module is not used, for instance, it is part of the runtime anyhow, basically the runtime it cannot be tree-shakable;
- no incremental compilation: Angular compilation is global and it involves not only the application but also the libraries.
Ivy will the new default rendering engine starting from version 9 and should solve the View Engine current issues:
- simplify how Angular works internally;
- tree-shakable the Hello World application does not require the full Angular runtime and will be bundled in only 4.7 KB;
- incremental compilation is not possible so the compilation is faster than ever and --aot can be now used even during development mode (advice from Angular team).

Ivy is an enabler.

Igor Minar - Angular team

The incremental DOM is the foundation of the new rendering engine.

Incremental DOM vs. Virtual DOM

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

Viktor Savkin - Nrwl

Each compiled component has two main sets of instructions:

view creation instructions executed when the component is rendered for the first time;
change detection instructions to update the DOM when the component changes.

Change detection is basically a set of instructions added at compile time. The developer's life is made easier since he is aware only of the variable binding in the Angular template declarative.

Incremental DOM enables better bundle size and memory footprint so that applications can perform really well on mobile devices.

Virtual DOM

Both React and Vue are based on the concept of Virtual DOM to create a component and re-render it when change detection happens.

Render the DOM is a very expensive operation when a component is added to the DOM or changes happen, the repaint operation has to take place. Virtual DOM strategy aims to reduce the amount of work on the real DOM and so the number of times the user interface needs to be repainted.

Tip
The end-user sometimes does not realize the complexity behind the rendering of a user interface. A simple click can generate HTTP requests, changes in the component, changes in other components and so on. Single change for the user can be a complex set of changes that must be applied to the DOM.

DOM manipulations happens every time a new component is going to be added, removed or changed from the DOM, so instead of operating directly on the DOM it operates on a JSON object called Virtual DOM. When a new component is added or an existing one removed, a new Virtual DOM is created, the node added or removed and the difference between Virtual DOMs is computed. A sequence of transformations is applied to the real DOM.

React documentation advice is to use JSX, a syntax extension to JavaScript, to define React elements. JSX is not a template language. A template is an enriched JavaScript expression that is interpreted at runtime. Plain JavaScript can also be used instead of JSX.

Virtual DOM technique has some disadvantages:

create a whole tree every time a change happens (add or remove a node), so the memory footprint is quite important;
an interpreter is required as long as the diff algorithm to compute the difference among the Virtual DOMs. At compile time it is not known which functionalities are required to render the application, so the whole thing has to be shipped to the browser.

Incremental DOM

It is the foundation of the new rendering engine. Each component template gets compiled into creation and change detection instructions: one to add the component to the DOM and the other one to update the DOM in-place.

Instructions are not interpreted by the Angular runtime, the rendering engine, but the instructions are the rendering engine.

Viktor Savkin - Nrwl

Since the runtime does not interpret the template component instructions, but the component references instructions it is quite easy to remove those instructions that are not referenced. At compile time the unused instruction can be excluded from the bundle.

The amount of memory required to render the DOM is proportional to the size of the component.

Tip
The compiled template component references some instructions of the Angular runtime which holds the implementation.

Enable Angular Ivy

Ivy can be enabled in an existing project with the latest Angular version but also directly scaffold a project with Ivy.

Enable Ivy in an existing project

Having an existing Angular (8.1.x) project run:

$ ng update @angular/cli@next @angular/core@next

both the Angular core and the CLI will be updated at the latest release candidate. One interesting thing to notice is the "aot": true in the angular.json workspace configuration file:

AOT compilation with Ivy is faster and should be used by default.

Angular docs

Then add the angular compiler options in the tsconfig.app.json:

{
  "compilerOptions": { ... },
  "angularCompilerOptions": {
    "enableIvy": true
  }
}

New project with Ivy

To start a new project with Ivy run:

$ new my-app --enable-ivy

Disable Ivy

To disable Ivy:

in angular.json set "aot": false;
in tsconfig.app.json remove the angularCompilerOptions option or set "enableIvy": false.

Angular Ivy Compilation

Consider the following Hello World Angular component:

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

@Component({
  selector: 'app-root',
  template: `
    <div style="text-align:center">
      <h1>
        Welcome to {{ title }}!
      </h1>
    </div>
  `,
  styleUrls: []
})
export class AppComponent {
  @Input() title = 'Angular!';
}

in Angular 8 with Ivy enabled, it gets compiled into the following code:

class AppComponent {
  constructor() {
    this.title = 'Angular!';
  }
}
AppComponent.ngComponentDef = defineComponent({
        selectors: [['app-root']],
        factory: function() { return new AppComponent();}
    },
    template: function(flags, context) {
        if (flags & 1) {
            elementStart(0, "div", 0);
            elementStart(1, "h1");
            text(2);
            elementEnd();
            elementEnd();
        } if (flags & 2) {...}
    },
    directives: [...]
  });

In Angular 8 with Ivy, the Angular decorators were compiled into static fields in the decorated class. So @Component becomes ngComponentDef static field. Back to View Engine, the ngc compiler produces .ngfactory separated files for each component and modules. With Ivy the code produced by the compiler is moving into component class static fields.

The elementStart(), elementEnd(), etc are the component referenced instructions, every component is its own factory, the framework does not interpret the component.

All the not referenced instructions at compile time are removed from the final application bundle.

Tip
The View Engine runtime is a single monolith interpreter that is not tree-shakable and has to be entirely shipped to the browser. Differently, Angular Ivy runtime is an instruction set that is a set of rendering functions like an assembly language for templates.

In Angular 9 RC5 and Ivy instead the compilation is a bit different:

export class AppComponent {
    constructor() {
        this.title = 'Angular';
    }
}
AppComponent.ɵfac = function AppComponent_Factory(t) { return new (t || AppComponent)(); };
AppComponent.ɵcmp = i0.ɵɵdefineComponent({ type: AppComponent, selectors: [["app-root"]], 
  inputs: { title: "title" }, decls: 3, vars: 1, 
  consts: [[2, "text-align", "center"]], 
  template: function AppComponent_Template(rf, ctx) { 
    if (rf & 1) {
        i0.ɵɵelementStart(0, "div", 0);
        i0.ɵɵelementStart(1, "h1");
        i0.ɵɵtext(2);
        i0.ɵɵelementEnd();
        i0.ɵɵelementEnd();
    } if (rf & 2) {
        i0.ɵɵadvance(2);
        i0.ɵɵtextInterpolate1(" Welcome to ", ctx.title, "! ");
    } }, encapsulation: 2 });

What Angular Ivy enables

Angular Ivy is an enabler. Simplifying how Angular works internally and the compilation process resolves current View Engine limitations and makes Angular easily extensible to new features.

The new Ivy engineering has been driven by three main goals: tree-shaking, locality, and flexibility.

Tree-shaking

Tree-shaking is the operation of removing dead code from the bundle so if the application does not reference some of the runtime rendering function, they can be omitted from the bundle making it smaller.

Dead code comes from libraries, Angular included. Angular CLI is powered by ~~Webpack uglify plugin~~ Webpack Terser plugin as tree-shaker that, in turn, receives information from Angular Build Optimizer Plugin about which code is used and which not. The Angular compiler simply does not emit those instructions, the plugin can gather information about component referenced instructions so can instruct ~~Uglify~~ Terser about what to include/exclude in/from the bundle.

While the @angular/core framework is tree-shakable, the View Engine runtime is not, it cannot be broken into small pieces and this is mainly due to the static Map<Component, ComponentFactory> variable.

Incremental compilation

The Angular 8 compilation pipeline started by ng build prod --aot is composed of five phases where the tsc and the ngc generates the template factories. ngc compiles the libraries as well. Ivy enables Incremental compilation that is libraries can be compiled and deployed on npm.

Locality

Currently Angular relies on global compilation. The compilation process requires a global static analysis of the entire application to combine different compilation outputs (application, libraries from the monorepo and libraries from npm) before emitting the bundle. Moreover, it is really complex to combine AOT libraries into a JIT application.

Tip
The compiler should use only information provided by component decorator and its class and nothing else. This simplifies the overall compilation process, no more component.metadata.json and component.ngfactory.json that requires complex management in the compilation pipeline.

Locality is a rule. Ivy compilation introduces the concept of component/directive public API: an Angular application can safely refer to components and directives public API, no more needed to know much about dependencies since extra information are added to .d.ts component files.

Example: Ivy library compilation

Add a library to the monorepo where your application is running ng generate library mylib.

Compile the library with ng build mylib, the following files are produced:

├── bundles
├── ...
├── lib
│   ├── mylib.component.d.ts
│   ├── mylib.module.d.ts
│   └── mylib.service.d.ts
├── mylib.d.ts
├── package.json
└── public-api.d.ts

Notice as well that this new message is displayed in version 9 due to Ivy activation:

Building Angular Package
******************************************************************************
It is not recommended to publish Ivy libraries to NPM repositories.
Read more here: https://next.angular.io/guide/ivy#maintaining-library-compatibility
******************************************************************************

Generated component

This is the component generated by the Angular CLI:

import { Component, OnInit } from '@angular/core';

@Component({
  selector: 'lib-mylib',
  template: `
    <p>mylib works!</p>
  `,
  styles: []
})
export class MylibComponent implements OnInit {

  constructor() { }

  ngOnInit() { }
}

Compiled library code

The metadata file mylib.metadata.json is not generated anymore, metadata are now part of the definition files.

Definition file of the component:

import { OnInit } from "@angular/core";
import * as i0 from "@angular/core";
export declare class MylibComponent implements OnInit {
  constructor();
  ngOnInit(): void;
  static ɵfac: i0.ɵɵFactoryDef<MylibComponent>;
  static ɵcmp: i0.ɵɵComponentDefWithMeta<MylibComponent,"lib-mylib",never,{},{},never>;
}

Definition file of the module:

import * as i0 from "@angular/core";
import * as i1 from "./mylib.component";
export declare class MylibModule {
    static ɵmod: i0.ɵɵNgModuleDefWithMeta<MylibModule, [typeof i1.MylibComponent], never, [typeof i1.MylibComponent]>;
    static ɵinj: i0.ɵɵInjectorDef<MylibModule>;
}

and the definition file of the service:

import * as i0 from "@angular/core";
export declare class MylibService {
    constructor();
    static ɵfac: i0.ɵɵFactoryDef<MylibService>;
    static ɵprov: i0.ɵɵInjectableDef<MylibService>;
}

Add a property to the component

Add to the library component an input field:

@Component({
  selector: 'lib-mylib',
  template: `
    <p>Please input your phone</p>
    <input #phone placeholder="phone number" />
  `,
  styles: []
})
export class MylibComponent implements OnInit {

  @Input('phone-number') private phone: string;

  constructor() { }

  ngOnInit() {
  }
}

The alias phone-number will be added to the input property providing additional metadata for the public API. The compiler generates the following definition file:

import { OnInit } from '@angular/core';
import * as i0 from "@angular/core";
export declare class MylibComponent implements OnInit {
    private phone;
    constructor();
    ngOnInit(): void;
    static ɵfac: i0.ɵɵFactoryDef<MylibComponent>;
    static ɵcmp: i0.ɵɵComponentDefWithMeta<MylibComponent, "lib-mylib", never, { 'phone': "phone-number" }, {}, never>;
}

Decorator that marks a class field as an input property and supplies configuration metadata. The input property is bound to a DOM property in the template. During change detection, Angular automatically updates the data property with the DOM property's value.

Input decorator - Angular docs

The property phone-number is the name part of the public API while phone is the private name, an implementation detail. Since it can change, the code must be compiled every time to emit, in case, an error if there is a property name mismatch. For this reason, the current Angular version must rely on global compilation.

Angular Ivy instead relies on the public API, so library code can be compiled and safely shipped to npm.

Browser property

The input property is bound to a DOM property in the template.

Basically

When the browser loads the page, it “reads” (another word: “parses”) the HTML and generates DOM objects from it. For element nodes, most standard HTML attributes automatically become properties of DOM objects.

Attributes and properties - javascript.info

The Angular compiler transforms the decorators and the templates into JavaScript instructions not only to create elements into the DOM but also extra content properties and attributes used by the runtime to "keep-alive" the application.

Flexibility

Angular Ivy is more flexible than View Engine because if new features are introduced in Angular new instructions will be implemented in the set. Ivy is easier to be extended and optimized.

Angular Ivy Build Pipeline

The compilation of an Angular application is just half of the process since the libraries the application depends on having to be made compatible with the new runtime.

ngcc (Angular compatibility compiler) is a new compiler that convert and compile the libraries. Libraries compatible with ViewEngine, the previous rendering engine of Angular, are converted into Ivy instructions so that the "library can participate in the Ivy runtime" and be fully compatible.

The new compiler has been implemented to make libraries compatible with the new format without obliging maintainers to rewrite important parts of them and, moreover, not all the applications need to be compatible with Ivy.

In Angular version 9 Ivy is enabled for application only and ngcc is used to convert existing libraries making them Ivy compatible. Over time application will start to become more and more Ivy compatible and so the libraries, then ngcc will not be any more necessary. Libraries can be converted on the fly into Ivy compatible libraries during the build or installation process.

The incremental transition from version 9 to version 11 will make ngcc only required for some few cases:

Angular version	ngcc
9	app on Ivy (opt-out) and libraries VE compatible
10	stabilize Ivy instruction set, libraries ship Ivy code
11	`ngcc` backup for obsolete libraries or not updated yet

ngcc-validation project is the way the Angular team tests the libraries' compatibility.

Component lazy loading feature

Angular is an enabler, it will allow more improvement about performance not only for the build but also for the application. Since version 2 Angular has a component lazy loading feature but just at router level. Lazy loading at component level requires a lot of boilerplate code and some patches to make it work.

With Angular Ivy will be much simpler. Consider the following example: click on an image, lazy load the bundle and add the component to the view. Lazy loading improves the speed of an application. Ideally it will be:

@Component(...)
export class AppComponent{
  constructor(
      private viewContainer: ViewContainer,
      private cfr: ComponentFactoryResolver) {

    // lazy click handler
    async lazyload() {
      // use the dynamic import
      const {LazyComponent} = await import('./lazy/lazy.component');
      this.viewContainer.createComponent(LazyComponent);
    }
  }
}

View Engine obliges to pass via the ComponentFactoryResolver to resolve the lazy component into a factory and to load it:

this.viewContainer.createComponent(this.cfr.resolveComponentFactory(LazyComponent));

Bundle size

To evaluate the bundle size improvement, the Angular team uses a metric{: .italic-red-text} the Hello World application. Building with Angular Ivy, the final minimized bundle is ~4.5kB and ~2.7kB with Closure Compiler.

Angular Elements can be then bundled more efficiently and, moreover, Ivy is ready for future bundlers/optimizers.

Debugging

A new API has been added to the global ng object. In the ChromeDevTools just open the console and type ng to see the new options:

Consider to have a <mat-drover></mat-drover> component from the Angular Material library, it is possible to directly act on the component from the console (thanks to Juri Strumpflohner for the example in his tutorial):

// grab the component instance of the DOM element stored in $0
let matDrawer = ng.getComponent($0);

// interact with the component's API
matDrawer.toggle();

// trigger change detection on the component
ng.markDirty(matDrawer);

From the Elements tab just select the element of the debug action, a $0 will appear close to it, it can be used as selector/placeholder for the element in the console.

NgProbe will not be probably supported anymore:

In Ivy, we don't support NgProbe because we have our own set of testing utilities with more robust functionality.

We shouldn't bring in NgProbe because it prevents DebugNode and friends from tree-shaking properly.

Platform browser - Angular source code

Conclusions

Angular team has done an amazing job, it was really a pleasure to attend the Angular Connect 2019 and see the improvement done on the new rendering architecture introduced last year.

Development can be done now with aot compilation enabled by default to avoid possible mismatches between the development and the production environment.

Another interesting point is the Angular Elements. I think the project can now really speeds up thanks to the new compiler and rendering engine. Currently, it is not possible to create a library project and compiler it as web components, this will really a killing feature. Moreover, the generated web components have "too much Angular inside", they are a bit too big, Ivy should reduce the amount of the framework that wraps an Angular component.

Really impressive is the lazy loading that could be achieved in a very simple manner, powerful but keeping the readability of the code simple.

Special thanks

Special thanks to

Lars Gyrup Brink NielsenFollow

👨‍🏫 Co-Founder of This is Learning, Organizer of AarhusJS ✍️ Writer, Speaker, FOSS Maintainer 📗 Author 🏆 Microsoft MVP 🌟 GitHub Star 🌊 Nx Champion 🦸 Angular Hero of Education

for the peer review and for having found some inaccuracies between Angular 8 and Angular 9 with Ivy enabled.

Forem: Eugenio Lentini

An introduction to Angular 9 Ivy Compiler

Table Of Contents

Angular Ivy: a detailed introduction

Eugenio Lentini ・ Dec 10 '19 ・ 14 min read

Lingo

Quick overview

Angular Ivy compiler model

Compiler enables decoupling

Simple project setup

Let's compile

ngtsc

ngcc

ngc

JIT vs. AoT

Compilation models

TypeScript compilation model

Angular Ivy compilation model

TypeScript transpiler architecture

Extension points

Compilation steps

1. Program creation

2. Analysis

3. Resolve

4. Type checking

5. Emit

Compiler features

Module compilation scope

Export compilation scope

Partial evaluation

Template type checking

Example

Conclusions

References

Angular Compiler Architecture

Tools

Angular 8 Bootstrap in deep

Table Of Contents

Angular Ivy: a detailed introduction

Eugenio Lentini ・ Dec 10 '19 ・ 14 min read

Slides

Lingo

The plan

Browser DOM

DOM rendering is slow

Virtual DOM

What Virtual DOM looks like

Example

How React uses the Virtual DOM

Virtual DOM drawbacks

Incremental DOM

Angular compiler

Angular component

Example

Browser cannot render an Angular component

Angular vs. browser

Browser role

Angular role

Analyze the compiled code

Setup the compilation task

One and simple component

The module and the component

Compile

Module factory function

What is going to happen

Module factory implementation

Module creation

Component factory function

Compiled template

How Angular application bootstraps

0. IIEF

1. Platform

2. Application

3. Root component

4. Create nodes

5. The renderer

Conclusions

References

DOM

Virtual DOM

`ngtsc`

`ngcc`

`ngc`