Note: 📺 Check out the video recording of a community discussion about this RFC @ angularnation.net

Summary

The Angular team would like to understand the remaining use-cases for Angular's JIT compilation mode, and discover any gaps that prevent adoption of the AOT compilation mode for these use-cases.

We'd like you, the community, to share with us how and why you still use JIT mode, and what prevents you from using AOT.

Background information

When Angular launched as v2.0 back in 2016, the template compiler supported two distinct compilation modes: JIT (just in time) and AOT (ahead of time) compilation.

While initially JIT was readily available and the primary mode for both development and production build workflows, our intention has always been to primarily focus on AOT mode which was harder to implement, but offered more opportunities to improve the development experience (e.g. type checking, autocompletion, automated refactoring, and faster development server and unit testing incremental iteration cycle), as well as user experience (faster and smaller apps, thanks to significantly better runtime and payload size optimizations).

Over the last many releases we overhauled the AOT compiler and kept on improving it. As of Angular v9 the AOT compilation mode is the default for all development and production workflows for all CLI application and library workflows (it's been the default at Google for much longer than that). There are only a few remaining cases where JIT compilation is still used:

• unit testing workflows which run either in mixed JIT+AOT mode, or JIT-only mode
• use-cases relying on dynamically generating templates and views at runtime
• the legacy and long-deprecated dynamic upgrade layer within @angular/upgrade
• customized build pipelines of large monolithic projects that use JIT to speed up incremental builds for interactive workflows

The use of the JIT compiler for these use-cases suffers from a lack of type checking, as well as performance and security issues that are a side-effect of compiling code at runtime in the browser (and in the JavaScript context shared with the production application).

The security implications are serious enough that our Information Security Engineering team at Google has early-on disallowed the use of Angular's JIT compiler in production environments at Google.

As of v13, the legacy View Engine compilation pipeline will no longer be part of Angular's stack (more info and also here), which significantly simplifies Angular, especially for library authors, which have had to ensure compatibility of their libraries with both View Engine and Ivy during the transition.

It is our goal to keep making Angular simpler and streamline internal complexity that affects Angular application developers and library authors in direct and indirect ways, and as part of this effort we'd like to evaluate if keeping JIT compilation mode around is still providing Angular developers with value that justifies the increase in complexity, security risks, and maintenance cost for everyone, including Angular application developers, library developers, as well as the Angular team.

There are many benefits to standardizing on AOT compilation mode, the main ones include:

• consistency and predictability — JIT and AOT modes behave identically once all the templates & metadata are collected, and all the JavaScript references (module imports, class references, etc) are resolved. However, the collection of templates & metadata, and resolution of JavaScript symbols is significantly different between AOT and JIT, and requires special considerations in the application and library code (inconsistent behavior of what can and cannot be declared with Angular's decorators), in the library packaging format (the npm packages must support both JIT and AOT compilation), and also in the Angular compiler and runtime, which needs to accomodate the needs and quirks of both JIT and AOT.

• fewer runtime performance and security pitfalls, and fewer confusing APIs for developers — for example the @angular/platform-browser-dynamic package and the Compiler APIs could be removed.

• addition of view composition APIs to support commonly requested use-cases that are currently handled via JIT compilation — for example dynamic view composition (e.g. new core APIs for dynamically assembling and composing views out of directives, and components at runtime to support data-driven form, and other UIs).

• focus on further build time improvements for AOT — for example by out-of-band type-checking for TypeScript and Template compilation, and transition to parallelizable localized compilation.

Community feedback

We'd like the community to share with us how and why you still use JIT mode, and what prevents you from using AOT.

We are specifically interested to know if there are use-cases that we are not familiar with (not listed in this RFC)?

Additionally, we'd also like to hear if you face organizational or technical restrictions that require you to use the JIT compilation mode?

The information provided by the community will help us understand what gaps we need to fill, and if it is feasible to deprecate and remove the JIT mode some time in the future once all the significant gaps are filled.

This RFC will close on Sep 8, 2021. Thank you for participating!