Angular JIT: Runtime Template Compilation
Angular JIT ships the compiler to the browser and builds components on the fly. It speeds up development rebuilds but pushes compilation cost to runtime. The footgun is deploying it to production, bloating bundles and hiding template errors until runtime.
Why it exists
Angular components are written with templates that contain custom syntax such as structural directives and property bindings. These templates are not valid JavaScript and cannot execute directly in a browser. Before the browser can render a component, something must transform that template into executable instructions. JIT compilation exists to perform this transformation inside the browser rather than on the build machine.
The mental model
Think of JIT as bringing a furniture factory to the customer's house instead of delivering assembled chairs. The browser receives raw blueprints, the Angular compiler, and a set of instructions. On every application bootstrap, the factory runs and assembles the components from those blueprints. This means the browser does the work that a build server could have done earlier.
How it works
When you build an Angular application with JIT enabled, the build process skips template compilation. The emitted bundle contains the uncompiled component templates along with the Angular compiler itself. At runtime, the browser loads this compiler, which parses each template string, checks bindings against component classes, and generates executable render functions. These functions are then used by Angular's change detection to update the DOM. Because compilation happens on the client, template errors such as misspelled variables or invalid bindings are only caught when the code executes in the browser.
When to use it
JIT is useful during local development when fast incremental rebuilds matter more than bundle size. Since the build step does not compile templates, changed files rebuild quickly. It is also necessary for dynamic component scenarios where templates are constructed from runtime data and are therefore unknown at build time, such as rendering user-provided forms or CMS-driven layouts.
When not to use it
Do not use JIT for production deployments. Shipping the compiler to users adds significant overhead to the initial bundle and increases startup time. It also defers error detection from the build pipeline to the user's session, meaning template mistakes become runtime exceptions rather than build failures. Modern Angular tooling defaults to Ahead-of-Time compilation for production builds precisely to avoid these problems.
One canonical example
Running ng serve in older Angular versions or with AOT explicitly disabled uses JIT. The browser downloads the compiler and your raw component metadata. When the application bootstraps, the JIT compiler processes AppComponent's template and produces the factory required to render it. If a template references a property that does not exist on the component class, the build succeeds but the browser throws a runtime error the moment that component initializes.
Interview question
Why might an Angular developer intentionally choose JIT compilation over AOT?
- a.To minimize the production bundle by skipping the template compilation step during the build
- b.To catch template syntax errors such as misspelled variables before the application deploys
- c.To speed up initial page loads by deferring compilation until components are first rendered
- d.To support rendering templates that are generated from runtime data unknown at build timeCorrect
Why? this is the answer
JIT is necessary for dynamic scenarios such as CMS-driven layouts where templates are unknown at build time. The most tempting distractor is the belief that skipping build compilation reduces bundle size, but JIT actually ships the compiler to the browser, significantly increasing the payload.
Just read this? Test yourself on what you have been reading.
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on angular — each one lists the topics its interview covers.
See open roles