Angular Signals

Aleksandr Gusev — Fri, 24 Apr 2026 18:34:08 +0000

Angular Signals — A Shift in Angular Reactivity

Angular has changed significantly over the past few years. What was once often perceived as a heavy framework with complex change detection and a strong reliance on Zone.js is gradually moving toward a more explicit and predictable reactivity model.

One of the key steps in this direction is Signals.

What are Signals?

Signals in Angular introduce a new way of handling state that makes reactivity more explicit.

In simple terms:

Angular used to rely heavily on Zone.js and implicit change detection
Now it introduces a model where state and dependencies are explicitly defined

A Signal is a reactive primitive that holds a value and notifies the system when that value changes.

Why this matters

One of the long-standing challenges in Angular was not complexity itself, but implicit reactivity.

Developers often had to deal with questions like:

What exactly triggered a UI update?
Why did this component re-render?
Where does change detection actually stop?

Signals make this behavior more explicit and predictable.

Now:

dependencies are directly readable
updates are more granular
less framework-level “magic” is involved

A simple mindset shift

Before Signals:

“Angular will figure out what needs to update.”

With Signals:

“I explicitly define what depends on what.”

This is not just a technical change — it’s a conceptual shift in how we think about UI reactivity.

What changes in practice

1. More predictable state management

Signals move Angular closer to simple reactive primitives instead of relying on global change detection mechanisms.

2. Reduced reliance on Zone.js

Angular is gradually moving toward a model where Zone.js is no longer the central piece of reactivity.

Note: What is Zone.js?

Zone.js is a library that was historically at the core of Angular’s change detection system.

In simple terms, it:

tracks asynchronous operations (setTimeout, HTTP requests, events)
and notifies Angular when it should check for UI updates

This allowed Angular to automatically update the UI without explicit developer intervention.

However, this convenience comes with a trade-off: behavior becomes less transparent, since it is not always clear what triggered a re-render.

Signals address part of this by making reactivity more explicit and controlled.

Signals vs RxJS

Signals do not replace RxJS — they serve different purposes.

RxJS:

streams and events
asynchronous workflows

Signals:

local state
synchronous reactivity
UI-driven updates

They complement each other rather than compete.

Where Signals shine

Signals are especially useful in:

complex UI state
forms and interactive interfaces
applications where predictability matters

Final thoughts

Signals are not just a new API in Angular.

They represent a shift toward:

more explicit reactivity
more predictable UI behavior
a simpler mental model for developers

It’s one of the most meaningful evolutions in Angular in recent years — aimed at reducing hidden complexity without sacrificing power.

Why Being a Senior Developer Is Less About Tech Stack and More About Thinking

Aleksandr Gusev — Tue, 20 Jan 2026 18:24:41 +0000

After nearly a decade in professional web development, I’ve noticed that many discussions about seniority focus on the wrong things. People ask which tech stack you need to learn or how many years it takes to become a senior. In my experience, those questions miss the point.

Being a senior developer is not about specific technologies or job titles. It’s about the way you think and the responsibility you take.

A Tech Stack Is a Tool, Not a Level

Throughout my career, I’ve worked with different frameworks and approaches. Some were trendy, others were already considered outdated when they were introduced. Almost all of them eventually changed.

What didn’t change was the level of responsibility.

A junior developer worries about how to write code.
A mid-level developer worries about how to write correct code.
A senior developer worries about why this code should exist at all.

Responsibility Comes Before the Title

Senior-level thinking often appears long before the official title:
— when you think about maintainability, not just delivery;
— when you question requirements instead of blindly implementing them;
— when you understand that there is no perfect solution, only trade-offs.

At some point, you stop writing code for machines and start writing it for people who will read and maintain it months or years later.

Architecture Is Not About Diagrams

Architecture is often associated with clean diagrams and well-known patterns. In reality, architecture is more about:
— where the system can break;
— how expensive changes will be;
— who will maintain it and how.

Sometimes the best architectural decision is the most boring one.

Experience Is Not the Number of Projects

Experience doesn’t come from the number of projects or lines of code. It comes from situations where you:
— had to fix someone else’s mistakes;
— rolled back your own wrong decisions;
— supported a product for years instead of shipping it and moving on.

These moments are what actually shape professional judgment.

Final Thoughts

Being a senior developer is not a goal or a status. It’s a side effect of long-term work on real products and taking responsibility for the consequences of your decisions.

You can learn a tech stack.
Professional thinking takes time to earn.

This way of thinking has helped me make better long-term decisions in real-world products.

DEV Community: Aleksandr Gusev