Angular is Getting a Rust-Powered Compiler: Here's What's Coming

TypeScript 7 just shipped, and the numbers are hard to ignore: a full rewrite of the compiler in Go, with reported 10x speedups. If you've read my previous posts on Angular 21 and Angular 22, you know this framework doesn't sit still when the ecosystem moves. This time, the move is bigger than a new API. It's a rewrite of how Angular itself gets compiled.

Angular's compiler team just published a deep dive into their plan, and it's one of the most significant architectural shifts I've seen from them. Let's break it down.

The problem: Angular can't just "use" TypeScript 7

Angular's existing compiler is built directly on top of TypeScript's compiler APIs, specifically the ts.Transformer API, which lets Angular hook into the compilation pipeline and inject its own transformations. The catch: TypeScript 7 is written in Go, and Go can't expose that kind of API surface to a TypeScript-based consumer. Crossing the language barrier alone would eat into any performance gain.

So Angular can't just "upgrade" to the fast compiler. They have to decouple from it entirely.

The solution: ngp, the Angular Preprocessor

Angular's answer is a new tool, internally called ngp (Angular Preprocessor), that handles Angular-specific compilation before TypeScript ever sees the code. And yes, it's written in Rust:

Input:  dashboard.ts
Output: dashboard.ng.ts          → runtime code (decorators compiled)
        dashboard.ngtypecheck.ts → type-checking shim for templates

For every .ts file with an @Component, @Pipe, or similar decorator, ngp produces two outputs:

• .ng.ts: your actual component code, with Angular decorators already compiled down. This is what gets bundled and shipped to the browser.

• .ngtypecheck.ts: a synthetic file that translates your template expressions into type-checkable TypeScript, so you still get accurate error messages when you bind the wrong type to [user]="currentUser".

Both come with source maps, so tooling still points back to your original file when something breaks.

Why Rust, and why not Go like Microsoft?

This is the part I found most interesting. Angular didn't pick Rust because Go is bad. They picked it because of what already exists in each ecosystem.

Go made sense for Microsoft because TypeScript's existing codebase is also garbage-collected, so porting was more natural. Angular's compiler has simpler data structures; that wasn't the deciding factor for them. What mattered was tooling maturity: a native library with a parser, AST, semantic analyzer, and code transformer, ready to build on.

That library already exists in Rust: oxc (the Oxidation Compiler), the same engine powering Vite. So instead of reinventing a JS/TS toolchain from scratch, Angular is building on top of it.

The hybrid architecture

Here's the part that stood out to me as a practical dev, not just a spec reader: ngp isn't a pure Rust rewrite, at least not yet.

• Analyzer (Rust): parses your source with oxc, finds Angular-decorated classes, maps NgModule relationships, and reads dependency metadata, all multithreaded.

• Backend (TypeScript): still runs Angular's existing template compiler to actually generate output. Rewriting that piece entirely would take much longer, so for now it stays in TS.

The Rust side ships via napi-rs, which means it can load either as a native Node module or fall back to WebAssembly. The same WASM path also lets ngp run inside browser-based tools like StackBlitz.

What this means for you (not much, yet)

No breaking changes are expected beyond a handful of rare template type-checking edge cases, and those will be documented like any other breaking change. Existing projects don't need to do anything. An experimental version is planned for later this year, and it'll power both the CLI build and the language service.

Wrapping up

This isn't a new Angular feature you'll add to your app. It's Angular re-architecting itself to keep pace with a JS tooling ecosystem that's moving to native code. Vite went Rust-adjacent with oxc, TypeScript went Go, and now Angular is following the same instinct: keep the type system in TS, move the heavy lifting to native code.

If ngp delivers even a fraction of the speedup TypeScript 7 got, incremental builds on large Angular codebases could look very different a year from now.

If you missed it, check out my previous post on Angular 22's 6 biggest stable features: Signal Forms, Zoneless by default, and more.