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 2025?

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 2025, 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 2025, 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.