Telerik blogs
Angular Ivy

What is Angular Ivy? Learn how this new rendering engine for Angular works, how you can stay up to date as it develops and what it means to you.

If you're in the Angular world, you may have been hearing this buzzword "Ivy" being tossed around. But what is Ivy? Is it a plant you want to avoid? A comic book villain? A group of colleges? Nope, not in this case. Ivy is Angular's upcoming new rendering pipeline and view engine. Miško Hevery and Kara Erickson gave us a first look at Ivy in the ng-conf 2018 day 1 keynote. In this article, we're going to take a look at what Ivy is, how it works, and how you can stay up to date on its progress.

Just a caveat: Ivy is still in early stages of being actively developed, so this article is subject to change. Okay, let's get to it!

What's So Great About Ivy

So, Ivy is Angular's new rendering pipeline and view engine. What does that mean, though? To put it simply, Angular's view engine takes the templates and components we've written and translates them into regular HTML and JavaScript that the browser can read and display. This means, for example, that your template variables and data bindings get rendered to the page with correct data.

Ivy is going to be the third incarnation of this engine for Angular 2+. First, there was the original compiler (which was not referred to as a view engine). Then, for version 4, the team introduced the view engine, referred to as "renderer2." Ivy is next in line. Ivy is going to be smaller, faster, and simpler. In fact, early demos by Rob Wormald and Igor Minar of a "Hello, World" application are an incredibly tiny 3.2KB!

Angular Ivy

You can check out the code for that demo here.

The theme of smaller, faster, and simpler applies not only to bundle sizes, but also to the compilation process. This is mainly due to two key concepts: locality and tree-shaking. Let's take a closer look at these.


Locality means that Ivy compiles one file at a time. It only looks at a component and its template, not its dependencies, when generating the output. Compiling one file at a time will mean smaller sets of instructions, and it will also mean we'll be able to do incremental builds. Renderer2 was unable to do this, because it needed to do a static analysis of all code and generate a file called metadata.json that could be used to generate the compilation instructions. This template data was then sent to the Angular interpreter in order to be translated into something readable by the DOM. Ivy compresses these steps, and the template HTML is turned into instructions that are then readable by then DOM.

Locality translates into several benefits. In addition to faster compilation and the lack of a metadata.json step, this simplified process means that library creators will be able to ship AoT (ahead of time compiled) code through npm. Essentially, we'll have an equivalence between AoT and JIT (just in time). That's great news for developers - one of the early frustrations with the AoT compiler and renderer was that, often, template code that worked in JIT would not compile with AoT.

One last benefit of locality is that there's more opportunity for meta-programming, like higher order components and the ability to dynamically generate modules, components, or pipes. Not everyone will need this kind of advanced functionality, but it's a further step in making Angular a more sophisticated platform.


Ivy has been designed from the start with tree-shaking in mind. "Tree-shaking" means removing unused pieces of your code, which results in smaller bundles and faster load times.

Tree-shaking is done using static analysis, which doesn't actually run your code. Because of this, it must take into account all possible scenarios and include anything that might be needed in the bundle. For example, if you've imported a function but hidden it behind a false conditional, that function will still get included in the bundle, even though it's never called:

import { myCoolFunction } from './other';

const myCondition = false;

if (myCondition) {
  myCoolFunction(); // this will still be included

Ivy has been designed with this in mind. In Renderer2, the code was similar to a series of conditionals that would include different parts of Angular if they were found in your application. Ivy, on the other hand, breaks things down into smaller, more atomic functions. These atomic functions make the renderer code much more friendly to tree-shaking, because they generate only the code you need from the template you've written.

To put it simply: Ivy makes sure that, if you're not using something in Angular, it doesn't get included.

The tree-shakable features of Angular include:

  • Template syntax
  • Dependency injection
  • Content projection
  • Structural directives
  • Lifecycle hooks
  • Pipes
  • Queries
  • Listeners

You can see why that "Hello World" demo is so crazy small - it only needs a tiny part of Angular's core functionality!

What Ivy Means to You

Locality and tree-shaking are total game-changers. When we combine the two, we end up with:

  • Smaller builds
  • Faster rebuild times
  • Faster development
  • A simpler, more hackable pipeline
  • Human readable code

But what else does this mean for you? When Ivy goes live, is it going to break everything? The answer is no - you shouldn't notice any changes other than the better build process. All of the heavy lifting will be done in the background, totally transparent to you the developer.

There's one other way that Ivy will affect you. Because of the drastic simplification of the Ivy pipeline, templates will be part of the stack trace. You'll no longer have to deal with cryptic error messages when something is broken in your template syntax - you'll see the exact line number where something is wrong. You'll even be able to set breakpoints in your templates to debug them. If you're like me, that's a huge sigh of relief.

Normally, the renderer doesn't affect day-to-day development much. For those of us in the real world, though, we've had our fair share of frustrations with the AoT compiler when moving from development to production. Ivy is going to drastically improve our development experience by removing much of the "black box" of the rendering process. Awesome!

Try it Yourself

If you're itching to to poke around at some sample code, you can take a look at the todo app that Kara demonstrated at ng-conf. Fair warning: this is all highly experimental and bleeding edge!

First, you'll need to install the new Bazel build system for your OS. Follow the instructions in the documentation to get it up and running.

Next, clone the Angular repo:

git clone

Open up a terminal inside of that directory and navigate to the todo app code:

cd packages/core/test/bundling/todo

Run these two commands to install the dependencies and run the development server:

bazel run @yarn//:yarn

bazel run //packages/core/test/bundling/todo:devserver

You can also run that last command with :prodserver to see the production build.

Poke around, try to break things, and take a look at the instructions.ts file to see the the compilation instructions that Ivy generates.

Angular Ivy

How to Stay Up to Date

We've learned about how Ivy works, the benefits it promises, and how it will affect you. We've also seen a little bit of sample code. So when is Ivy being released?

Miško showed this slide of the Ivy roadmap at ng-conf 2018 ("today" meant April 18, 2018):

Angular Ivy

You can see that the phases of Ivy's timeline start with work on the runtime, which overlaps with work on the template compiler. Once those are being wrapped up, the beta will start alongside Google's internal verification process. This verification process includes making sure Ivy introduces no breaking changes for Google's 600+ internal applications that use Angular. This ensures that there will be complete backwards compatibility before Ivy gets released into the wild.

Until Google's done testing Ivy, it can be tested via the enableIvy: true flag of angularCompilerOptions.

To keep an eye on Ivy's progress, you can check on this GitHub document and watch this GitHub issue. Or, if that's not exciting enough for you, community member Oussama Ben Brahim created a Firebase app called Is Ivy Ready that provides a beautiful little UI for this purpose. Way to go, Oussama!

Where to Learn More

Here are a few more resources to learn more about Ivy and treeshakable providers:

About the Author

Sam Julien

Sam Julien is an Angular teacher and developer and the founder of the comprehensive video course He's also the co-organizer of Angular Portland. When he's not coding, you'll find Sam outside hiking and camping like a good Oregonian.

Related Posts


Comments are disabled in preview mode.