A Signal in the Noise: The Real Reason Signals Were Born (1/4)

Picture this: You use ChangeDetectionStrategy.OnPush. You rely on async pipes instead of manual subscriptions. You structure your data flow top-down, avoiding unnecessary state mutations.And you split up your components so only the parts that matter re-render.

Still…sometimes it feels like Angular is doing too much. Change detection runs across large portions of the tree. Templates re-evaluate even when nothing really changed.

Even a small reactive value—like toggling a boolean—can ripple through your app in ways that feel wasteful.

The Long-Time Pain Point for Angular

For a long time, Angular had one problem that wouldn’t go away: the way it handles updates. The system it used—called “dirty checking”—relied on Zone.js and basically said: “After anything changes, let’s check everything just to be safe.” That sounds okay at first, but in bigger apps, it added a lot of work.

Signals weren’t born to solve a broken system.

They were born to replace a model that scales poorly.

What if Angular didn’t have to check your entire component tree?
What if it knew, with certainty, exactly what changed—and only re-rendered that?
That’s what Signals enable.

Signals: A Simpler Way to React to Changes

So, what’s a Signal?

Signals focus on where the change matters, not just when something changes. Instead of checking everything all the time, Angular can now update only the exact parts that need it. This means less work, less waiting, and smoother apps.

Signals give Angular the ability to:

• Track exact dependencies in the template.

• Skip entire component subtrees unless data actually changed.

• Recalculate only the minimal required expressions.

And they don’t require you to memorize obscure APIs or lifecycle tricks.
No need to run change detection manually. No dirty checks. Just reactive updates that go straight to the parts that care. Simple, fast, and focused.

Signals vs. RxJS: Not the Same

You might be thinking: “Wait, don’t we already use RxJS for reactivity?” Yep—but Signals are different.

• RxJS is perfect for async streams: events, HTTP, user input. It’s like a pipeline for things that keep changing over time.

• Signals are for state—something that just exists right now and updates over time. You don’t need .subscribe(), no async pipe, no ngOnDestroy. It’s synchronous and way easier to use in templates and components. You can still use RxJS for streams and Signals for state—and mix them when you need to.

const count = signal(0);
const double = computed(() => count() * 2);

Signals and RxJS work together. Use Signals for quick changes in your app’s parts, and RxJS for streams, or mix them when you need to.

Why This Matters for You

If you’ve already optimized your app the traditional way, Signals will feel like unlocking a hidden level of control.

You’ll:

• Cut down unnecessary re-renders.

• Remove redundant change detection cycles.

• Avoid needing manual performance hacks like markForCheck().

• This isn’t just about dev ergonomics. It’s about performance at scale.

Curious about what’s next? In the next article, I’ll explore how Signals represent a whole new way of thinking in Angular—and why this shift matters for the future of your apps.