Frontend development is finally admitting what many teams have felt for years: “re-render everything” is a blunt instrument. In its place, a more precise paradigm is spreading across frameworks—signals. These reactive primitives track what depends on what, then update only the parts of the UI that actually need to change. Angular did it first, Solid made it feel effortless, and Vue/Preact/Qwik shipped variants. React, meanwhile, is still treating memoization as an art form instead of a baseline capability.

This isn’t just trend-chasing. It’s a different mental model—one that reduces wasted work and makes performance less of a self-inflicted tax.

What signals change: from “re-render the world” to “update the truth”⌗

The core idea behind signals is simple: state is represented by primitives that know who depends on them. When a signal changes, the system automatically recalculates derived values and re-renders only the minimal set of consumers.

Contrast that with the dominant React pattern most apps still follow:

  • UI re-renders when component state/props change.
  • Developers then try to prevent unnecessary re-renders using React.memo, useMemo, and useCallback.
  • When optimization fails, the fix is often “sprinkle more memoization,” sometimes with fragile dependency arrays and unclear performance wins.

Signals flip that burden. You describe reactive relationships once, and the runtime keeps them consistent. If a UI subtree doesn’t depend on the updated signal, it never re-renders in the first place.

A practical way to see the difference: imagine a dashboard with filters on the left and a chart list on the right. When a user toggles a filter, only the chart list needs to change. With signals, that dependency is explicit: chart rendering consumes filter signals, while unrelated UI doesn’t. With re-render-everything, the “chart list” is often still re-rendered indirectly—React will reconcile anyway, and whether reconciliation short-circuits depends on memoization strategy and component structure.

Angular, Solid, Vue, Preact, Qwik: the ecosystem is converging⌗

Signals aren’t one monolithic thing—each framework has its own flavor—but the trajectory is clear: the industry is converging on dependency-tracked reactivity as the default.

  • Angular adopted signals as a first-class reactivity model. It’s not positioned as a niche optimization; it’s the direction of the platform.
  • Solid is essentially “signals-first.” Reactive updates are granular by design, and UI updates are tied directly to reactive reads.
  • Vue introduced reactivity that feels very close to signals in practice, with dependency tracking and targeted updates baked into the framework’s reactivity system.
  • Preact has followed the same pragmatic path: keep updates precise and fast without forcing developers into a maze of memoization hooks.
  • Qwik takes the idea further by optimizing for resumability (the ability to load less JavaScript up front), while still using signals/reac­tivity patterns to keep UI updates aligned with actual data dependencies.

The common thread across these ecosystems is that “efficiency” isn’t an afterthought. It’s what the runtime does while you focus on building features.

React’s holdout: power through memoization, or a performance tax in disguise?⌗

React has a sophisticated rendering model and a strong mental framework—there’s a reason it became the default for years. But in the signal era, React’s current stance reads less like a principled design decision and more like a willingness to outsource performance to developers.

In practice, the React approach often looks like this:

  1. A state update occurs.
  2. Components re-render.
  3. Developers attempt to curb the blast radius:
    • useMemo to avoid recomputing expensive derived values.
    • useCallback to stabilize function identities passed to children.
    • React.memo to prevent re-renders of child components.
  4. If something still re-renders, you profile, refactor, and repeat.

The problem isn’t that React memoization can work. It’s that the default path requires constant vigilance. A small code change—like capturing stale values incorrectly or missing a dependency in a memo hook—can silently sabotage performance (or correctness).

Worse, many teams end up with optimization logic that’s harder to read than the actual UI code. The application becomes a patchwork of “render control” rather than a clean expression of data dependencies.

To be blunt: React didn’t just lag behind signals. It kept the assumption that developers can and should manually manage reactivity boundaries.

The real benefit: signals make performance predictable, not heroic⌗

The most compelling argument for signals is not raw speed—it’s predictability.

With dependency-tracked updates, the system knows exactly which computations and UI pieces are affected. That turns performance into a property of the programming model, not a recurring project management task.

Consider a common React performance trap: a list rendering component with derived sorting/filtering. Developers often wrap the sort with useMemo and the callbacks with useCallback. But the real work is determining whether the dependencies truly change when they should. In large apps, dependency arrays become a form of long-term technical debt.

Signals reduce this fragility. Derived values are automatically recomputed when (and only when) the signals they read change. You’re not asking React to guess when recomputation is necessary—you’re telling the reactive system what depends on what.

Here’s what that looks like conceptually:

  • A derived value reads filterSignal and itemsSignal.
  • When filterSignal changes, only the derived value recalculates.
  • Only the UI bound to that derived value updates.

No need to propagate “stability” via useCallback just to satisfy referential equality.

Practical migration mindset: you don’t need a rewrite to learn from signals⌗

React might not be shipping signals broadly tomorrow (or ever, in the same way), but you can still adopt the core lesson: make dependencies explicit.

If you want the practical benefits without a framework switch, start by changing how you structure state:

  • Co-locate derived state with its inputs. If something is derived from multiple sources, keep it near the code that consumes it and ensure it’s recomputed only when those sources change.
  • Avoid passing unstable objects/functions deep into the tree. Even in React, this is often where performance leaks out.
  • Prefer localized state updates over global “everything changed” patterns. If one change invalidates a huge subtree, your reactivity boundaries are too coarse.
  • Profile before optimizing. The goal isn’t to memoize everything—it’s to stop re-render storms at the source.

If you’re already using React and feel forced into the memoization treadmill, signals are the clearest signal (pun intended) that you should reconsider your architecture. You don’t have to adopt a new framework to adopt the mindset: dependencies should drive updates, not the other way around.

And if you are choosing a new stack today? The decision is hard to justify for teams optimizing for correctness and performance without micromanaging re-render boundaries. Angular/Solid/Vue/Preact/Qwik aren’t perfect, but their direction is coherent: reactive primitives first, optimization as default behavior rather than a developer chore.

Conclusion: signals are the direction of travel—React should catch up⌗

Signals represent a shift from “render cycles as the unit of work” to “data dependency as the unit of truth.” That change reduces unnecessary work, simplifies reasoning about updates, and removes a large portion of the performance burden from developers.

React can still build great products, and it will keep its loyal base. But the ecosystem is converging on signals because they solve a real, recurring problem: re-render-everything models force developers to simulate dependency tracking after the fact. Signals don’t simulate—they embody it.

At this point, the question isn’t whether signals are better. It’s whether React wants to treat them as a feature of modern UI engineering rather than a competing philosophy—because the rest of the industry already has.