Ankit Sharma
Table of Contents
- Why Angular used Zone.js
- Signals: The foundation of modern Angular reactivity
- How Zoneless Change Detection works
- How to enable Zoneless Change Detection
- Why Zoneless Change Detection can be more efficient
- Where Zoneless Angular has the biggest impact
- Migrating existing applications
- Removing Zone.js
- Performance and bundle size
- Testing in Zoneless Angular
- Frequently Asked Questions
- Closing thoughts
- Related Blogs
TL;DR: Zoneless Angular replaces Zone.js-based change-detection scheduling with explicit Angular notifications such as signals, template events, and AsyncPipe emissions. The result can be more predictable rendering, simpler debugging, and greater control over UI updates. Before migrating, developers should verify external integrations, Reactive Forms workflows, third-party libraries, and tests for compatibility.
Angular’s popularity didn’t come from powerful APIs alone. It came from a developer experience that felt effortless.
Update a variable, and the UI updates automatically.
For years, Zone.js powered that experience by helping Angular know when application state might have changed. But as Angular applications grew larger and more complex, developers began facing challenges with performance tuning, debugging, and understanding exactly what triggered UI updates.
To address these challenges, Angular has introduced new reactive capabilities, including signals and zoneless change detection.
In Angular 20.2, zoneless change detection became stable, and Angular 21 enables it by default. Instead of relying heavily on Zone.js to detect asynchronous activity, Angular now uses more explicit mechanisms to determine when UI updates should occur.
Why Angular used Zone.js
Historically, Angular relied on Zone.js to monitor asynchronous browser operations such as:
- Timers
- Promises
- DOM events
- Network callbacks
When one of these operations completed, Angular received a notification and scheduled change detection.
The process looked roughly like this:
Async operation
↓
Zone.js detects completion
↓
Angular is notified
↓
Change detection runs
↓
Views update
This model worked well and removed much of the complexity involved in keeping UI and application state synchronized.
However, it also introduced challenges:
- Change detection could run more often than necessary.
- Debugging sometimes became harder because of zone-related call stacks.
- Performance optimization could require significant investigation.
- It was not always obvious what triggered a UI update.
As Angular evolved, the framework began moving toward more explicit reactive patterns.
Signals: The foundation of modern Angular reactivity
One of Angular’s most important additions is signals.
A signal represents a reactive state that Angular can track directly.
readonly count = signal(0);
add() {
this.count.update(value => value + 1);
}
When the signal changes, Angular receives a precise notification that the state has been updated.
This allows Angular to react to specific state changes instead of relying solely on global asynchronous activity.
What Signals do not do
A common misconception is that signals replace Angular change detection.
They do not.
Signals provide:
- Reactive state
- Dependency tracking
- Change notifications
- Reactive relationships between values
Angular still performs change detection. Signals simply help Angular understand more precisely when updates are required.
Signals vs. RxJS
Another common question is:
Should signals replace RxJS?
Usually, no.
The two technologies solve different problems.
Signals are ideal for
- Component state
- Local reactive data
- Derived UI state
- Fine-grained updates
RxJS is ideal for
- Event streams
- WebSocket communication
- Stream transformations
- Complex asynchronous workflows
- Service orchestration
In modern Angular applications, they frequently work together.
A common approach is:
- RxJS manages asynchronous workflows.
- Signals manage UI state.
How Zoneless Change Detection works
The core idea behind zoneless Angular is straightforward.
Instead of monitoring broad asynchronous activity, Angular reacts to recognized update notifications.
Traditional model:
Async activity
↓
Zone.js tracks activity
↓
Angular is notified
↓
Change detection runs
Zoneless model:
Angular notification
↓
Angular schedules updates
↓
Relevant views refresh
Angular can receive notifications through mechanisms such as:
- Signal updates used by templates
- Template and host event handlers
AsyncPipeemissionsComponentRef.setInput()ChangeDetectorRef.markForCheck()
Angular still schedules and batches updates efficiently. The difference is that updates are driven by explicit application state changes rather than broad asynchronous interception.
How to enable Zoneless Change Detection
Angular 20 applications can enable zoneless mode using.
provideZonelessChangeDetection():
import { bootstrapApplication } from '@angular/platform-browser';
import { provideZonelessChangeDetection } from '@angular/core';
bootstrapApplication(AppComponent, {
providers: [
provideZonelessChangeDetection()
]
});
Angular 21 applications use zoneless change detection by default.
If an application requires traditional Zone.js behavior, Angular also provides an explicit opt-in:
provideZoneChangeDetection()Why Zoneless Change Detection can be more efficient
Under the traditional model, Angular often performed change detection because something might have changed.
With zoneless change detection, Angular updates when It receives a recognized notification.
Potential benefits include:
- Reduced unnecessary work
- More predictable rendering behavior
- Easier debugging
- Better performance tuning visibility
However, these improvements are not guaranteed.
Actual results depend on factors such as:
- Application architecture
- Component count
- Update frequency
- Signals adoption
- Existing change-detection patterns
The best approach is to benchmark before and after migration rather than expecting universal gains.
Where Zoneless Angular has the biggest impact
Small applications may show little difference.
The biggest benefits often appear in applications with:
- Real-time dashboards
- Data-heavy interfaces
- Collaborative systems
- Frequent asynchronous updates
- External integrations
These environments generate many state changes, making explicit update mechanisms more valuable.
Working with external integrations
Third-party integrations are often where zoneless behavior becomes most noticeable.
Consider:
readonly unread = signal(0);
vendorApi.onUnreadCountChanged(count => {
this.unread.set(count);
});
The external callback itself is not important.
What matters is that Angular learns about the state change through a supported mechanism. Since the template consumes the signal, Angular can schedule the required UI update.
This represents a key mindset shift: State changes should be communicated through Angular-aware reactive mechanisms.
Template Bindings and Change Detection APIs
Many existing applications use APIs such as:
NgZone.run()markForCheck()detectChanges()
These APIs remain useful.
In zoneless applications:
markForCheck()remains a supported notification mechanism.detectChanges()performs an immediate local check.- Existing
NgZone.run()calls do not have to be removed simply because an application adopts zoneless mode.
Signals often reduce the need for manual notifications, but Angular’s existing APIs remain fully relevant.
Migrating existing applications
Moving to zoneless Angular is usually straightforward conceptually, but real-world migrations require careful validation.
The most common issues occur when applications rely on implicit updates that Zone.js previously detected automatically.
Consider this example:
vendorMap.on("markerSelect", marker => {
this.selectedLabel = marker.label;
});The code runs correctly, but Angular may not know it needs to update the UI.
A signal-based approach provides a clear notification path:
readonly selectedLabel = signal("none");
vendorMap.on("markerSelect", marker => {
this.selectedLabel.set(marker.label);
});Areas that deserve special attention
Review integrations involving:
- Third-party UI libraries
- Rich-text editors
- Charting libraries
- Mapping frameworks
- WebSockets
- Custom event systems
- Enterprise component libraries
- Microfrontends
- Reactive Forms workflows
Many of these integrations worked seamlessly before because Zone.js automatically detected asynchronous activity.
Reactive forms considerations
Reactive Forms deserve extra attention.
Operations such as:
setValue()patchValue()FormArray.push()
update the form model correctly but may not automatically schedule component change detection.
When templates depend directly on updated form state, connect those updates to Angular notification mechanisms such as:
this.cdr.markForCheck();or expose state using signals.
Removing Zone.js
Once an application and its dependencies are fully compatible:
- Remove Zone.js from application polyfills.
- Review test configuration.
- Migrate Zone.js-dependent testing utilities.
- Execute a full application build.
- Run the complete test suite.
Remove the package only after confirming that neither production code nor tests still depend on it.
Performance and bundle size
A common question is: Does removing Zone.js automatically improve performance?
Not necessarily.
Potential benefits include:
- Reduced runtime overhead
- Cleaner performance profiling
- Fewer unnecessary change-detection cycles
- Smaller client bundles
- Improved responsiveness in highly interactive applications
Applications most likely to benefit include:
- Real-time monitoring systems
- Large dashboards
- Data visualization platforms
- Applications with heavy asynchronous workloads
As always, measurement matters more than assumptions.
Library compatibility considerations
Will existing libraries continue to work?
In many cases, yes.
Still, compatibility testing is essential.
Pay particular attention to:
- Angular Material
- Internal design systems
- Charting libraries
- Rich-text editors
- Mapping frameworks
- Enterprise UI libraries
- Third-party widgets
The key question is whether state changes are communicated to Angular through supported update mechanisms.
Testing in Zoneless Angular
Testing is another area that often requires review.
Evaluate usage of:
fakeAsync()tick()flushMicrotasks()fixture.detectChanges()
Zone.js-dependent testing utilities cannot be used with Vitest.
Modern Angular projects increasingly favor native asynchronous testing patterns and Vitest timer utilities.
When possible, allow Angular to schedule updates naturally and validate behavior using:
await fixture.whenStable();The goal is to test explicit application behavior rather than relying on assumptions introduced by zone-based execution.
Frequently Asked Questions
No. Zoneless change detection controls how Angular schedules updates. Does Zoneless Angular Make OnPush Mandatory?
ChangeDetectionStrategy.OnPush controls how views participate in change detection. They solve different problems.
No. Zone.js remains fully supported. Angular is simply providing alternatives that enable more explicit reactive patterns.Is Zone.js Deprecated?
Yes. RxJS continues to work well in Angular applications, particularly when paired with mechanisms such as AsyncPipe.Can I Use RxJS Without Signals?
Not necessarily. Migration decisions should consider: • Application complexity Many organizations will benefit from gradual adoption rather than immediate migration.Should Every Application Migrate?
• Existing architecture
• Third-party dependencies
• Performance goals
• Team readiness
Closing thoughts
Zoneless change detection is less about removing Zone.js and more about making application updates explicit.
Combined with signals, it gives Angular developers greater visibility into when state changes occur and why the UI updates in response. The result is a more predictable and transparent reactivity model that can simplify debugging, improve maintainability, and reduce unnecessary work in some scenarios.
Zone.js remains a valid choice, especially for mature applications with established dependencies and workflows. But for teams embracing modern Angular patterns, zoneless change detection offers a compelling path to a more explicit, controllable reactive architecture.
The goal isn’t simply to remove Zone.js. It’s to build Angular applications that are easier to understand, easier to maintain, and better aligned with modern reactive development practices.
No spam, just valuable updates.