Angular is going through a quiet but important shift in how reactivity is handled. With the introduction of Signals, many developers are starting to ask a simple question:
Do we still need RxJS in Angular applications in 2026?
The short answer is: yes — but not everywhere.
The real answer is more interesting, and it’s about architecture, not preference.
Two different mental models #
To understand the discussion, it helps to separate two fundamentally different models of reactivity.
RxJS: asynchronous streams
RxJS is built around:
- event streams
- asynchronous composition
- time-based operations
It shines when dealing with:
- HTTP requests
- WebSockets
- complex async workflows
- event orchestration
RxJS is about time and events.
Signals: local reactive state
Signals represent a different idea:
- synchronous reactivity
- local state tracking
- explicit dependencies
They are best suited for:
- UI state
- derived state
- component-level reactivity
Signals are about state and UI consistency.
Code comparison #
Signals example
import { signal, computed } from '@angular/core';
const count = signal(0);
const doubled = computed(() => count() * 2);
function increment() {
count.set(count() + 1);
}
Signals make state and dependencies explicit. No subscriptions, no hidden wiring.
RxJS example
import { BehaviorSubject, map } from 'rxjs';
const count$ = new BehaviorSubject(0);
const doubled$ = count$.pipe(
map(value => value * 2)
);
function increment() {
count$.next(count$.value + 1);
}
RxJS introduces a stream-based model where everything flows through observables.
The real problem is not technology, but mixing models #
The biggest architectural issue in modern Angular applications is not choosing between RxJS and Signals.
It is mixing them without clear boundaries.
When both are used everywhere:
- state becomes duplicated
- logic becomes scattered
- it becomes unclear where the “source of truth” lives
Where RxJS is still the right tool #
Even in 2026, RxJS is still essential:
- HTTP request pipelines
- cancellation and retry logic
- real-time data streams
- coordination of multiple async sources
If the problem involves time, concurrency, or event composition, RxJS is still the better abstraction.
Where Signals are a better fit #
Signals work better when the problem is local and state-driven:
- component state
- derived UI values
- form state
- simple reactive bindings
Signals reduce unnecessary complexity and make data flow more explicit.
Architectural boundary #
A simple rule:
RxJS handles the outside world.
Signals handle the UI world.
- RxJS = integration layer
- Signals = presentation layer
When this boundary is respected, Angular applications become significantly easier to maintain.
Final thoughts #
In 2026, RxJS is not obsolete in Angular — it is simply no longer the only reactive model.
Signals introduce a second layer that allows developers to simplify UI logic without abandoning reactive power.
The best Angular applications are not those that choose one over the other, but those that clearly define when to use each.
Architecture is not about tools.
It is about boundaries.