Angular 9 Lands with Ivy — The Rewrite That Actually Shipped

Angular 9 shipped today, and with it, the Ivy rendering engine is finally the default. If you’ve been following the Angular project for the past couple of years, you know this has been a long time coming. The team first previewed Ivy at ng-conf 2018, and after a cautious opt-in period during Angular 8, it’s now front and center. For those of us who’ve watched framework rewrites go sideways more than once, this is a noteworthy moment — not because it’s revolutionary, but because it actually landed.

What Ivy Actually Changes

#

At its core, Ivy is a complete rewrite of Angular’s rendering pipeline — the compiler and runtime that turns your templates into executable code. The previous engine, View Engine, worked fine but produced larger bundles and was harder to tree-shake effectively. Ivy addresses this by generating code that’s more amenable to dead code elimination.

The practical results are encouraging. Early adopters during the Angular 8 opt-in period reported meaningful reductions in bundle size, particularly for smaller applications. The Angular team’s own benchmarks show bundle sizes dropping by around 25-40% for modest apps. For large enterprise applications — which is where Angular lives and breathes — the gains are more incremental, but still welcome.

Compilation speed is the other headline improvement. Ivy’s locality principle means that each component can be compiled independently, without needing to analyze the entire application. This translates to faster rebuilds during development, which is something every developer appreciates. The --aot flag is now the default for ng serve, which means you catch template errors during development rather than at build time. That alone is worth the upgrade.

The Template Type-Checking Story

#

One of the less flashy but more impactful changes is improved template type-checking. Angular has always had an advantage over React in that templates are structured and analyzable, but the type-checking was historically a bit loose. With Ivy, the strictTemplates option in tsconfig.json enables much more thorough checking of template expressions.

I’ve been experimenting with this in a side project, and it catches real bugs — mistyped property names, incorrect event bindings, type mismatches in pipes. If you’re already using TypeScript for its type safety (and you should be), having that safety extend into your templates is a natural evolution. It’s not quite at the level of what Elm gives you, but it’s a significant step for a mainstream framework.

// tsconfig.json
{
  "angularCompilerOptions": {
    "strictTemplates": true,
    "strictInjectionParameters": true,
    "strictInputAccessModifiers": true
  }
}

I’d recommend enabling these flags on any new project immediately. For existing projects, you can enable them incrementally — the compiler will tell you exactly what needs fixing.

Upgrade Path and Migration

#

The Angular team deserves credit for their upgrade tooling. Running ng update @angular/core @angular/cli handles most of the migration automatically, including updating RxJS imports to use the tree-shakeable format and adjusting for deprecated APIs. I ran it on a medium-sized project (about 150 components) and the automatic migration handled roughly 90% of the changes.

The remaining 10% were mostly edge cases around ViewChild and ContentChild queries, which now require an explicit static flag. It’s a minor inconvenience that makes the behavior more predictable:

// Before: timing was implicit and confusing
@ViewChild('myRef') myRef: ElementRef;

// After: you declare when you need the reference
@ViewChild('myRef', { static: true }) myRef: ElementRef;  // Available in ngOnInit
@ViewChild('myRef', { static: false }) myRef: ElementRef; // Available in ngAfterViewInit

This is the kind of breaking change I can get behind — it makes implicit behavior explicit, reducing a whole category of timing-related bugs.

The Broader Framework Landscape

#

Angular 9 arrives at an interesting moment. React continues to dominate mindshare, Vue 3 is in development with its own Composition API, and Svelte is generating excitement with its compiler-first approach. Angular’s position has always been as the “enterprise choice” — opinionated, batteries-included, TypeScript-first.

With Ivy, Angular doesn’t suddenly become hip or trendy, and that’s fine. What it does is become more competitive on the metrics that matter: bundle size, compilation speed, and developer experience. The framework still has a steeper learning curve than React or Vue, and the module system remains more ceremony than I’d like. But for teams building large, long-lived applications with complex forms and routing, Angular’s structure is a feature, not a bug.

My Take

#

I’ve been building web applications since before jQuery was a thing, and if there’s one pattern I’ve seen repeatedly, it’s that the best framework rewrites are the boring ones. The ones that improve things incrementally while maintaining backward compatibility. Ivy is exactly that — no flashy new syntax, no paradigm shifts, just a better engine under the hood.

The real test will be how the ecosystem adapts. Libraries need to be compiled with Ivy-compatible versions, and while the Angular team has provided a compatibility compiler (ngcc) to bridge the gap, it adds overhead to node_modules processing. I expect this transitional pain to last about six months before most maintained libraries ship Ivy-native builds.

If you’re on Angular 8, upgrade. If you’re on Angular 7 or earlier, plan your upgrade path — the tooling makes it smoother than you’d expect. And if you’re not using Angular at all, this release alone probably won’t change your mind. But it should reassure anyone who bet on Angular that the framework is in good hands.

This post is part of my weekly series covering the developer landscape as it evolves throughout 2020.