When Angular introduced Signals, the community reaction was immediate.
Some were excited.
Some were confused.
Some assumed RxJS was on its way out.
After using both in real Angular applications, I realized something important:
Signals don’t replace Observables — they clarify how we should think about state and reactivity.
This article isn’t about syntax.
It’s about the mental shift Angular Signals introduced.
Understanding the Core Difference
At a high level:
Signals are about state
Observables are about streams over time
Once I understood this, many design decisions became clearer.
What Signals Really Changed for Me
Signals shine when dealing with:
local component state
derived values
template-driven reactivity
They are:
synchronous
explicit
easy to trace
When a signal changes, Angular knows exactly what to update.
This made my components:
smaller
easier to reason about
less dependent on RxJS operators
Signals encouraged me to keep UI state simple and intentional.
Why Observables Are Still Essential
Observables remain the right tool for:
HTTP requests
user events
WebSockets
async workflows
They model time, not just values.
Features like:
subscribe
switchMap
retry
debounceTime
are still critical in real-world applications.
Trying to replace Observables with Signals in these scenarios only adds confusion
The Most Important Lesson
The real improvement wasn’t performance.
It was clarity.
Instead of forcing RxJS everywhere, I now ask:
Is this state? ** Signal**
Is this async over time? Observable
That single question improved: readability, maintainability,team communication
How I Use Them Together
In practice, I recommend:
fetch data with Observables
convert results into Signals
let Signals drive the UI
This combination feels natural and balanced.
Angular didn’t remove power.
It redistributed responsibility.
Signals didn’t make Observables obsolete.
They made Angular more honest about intent.
And for me, that’s the real win.
Top comments (0)