Are We Moving Beyond React? The Rise of Visual State Systems

React is still the default for serious product teams. That part has not changed.

What is changing is the state conversation around it. More teams are hitting the same wall: as interactions get richer, state logic spreads across reducers, contexts, derived selectors, and effect chains that are harder to reason about than the UI itself.

So the real question is not whether React is going away. The question is whether React's default state model is enough by itself for the next generation of interactive apps.

Why this conversation is back

The pressure points are familiar:

• deeply nested interaction flows
• real-time updates across multiple surfaces
• expensive rendering in dashboards, editors, and complex visual interfaces

React gives teams strong composition and ecosystem leverage. But in larger apps, it also forces a lot of discipline around state shape and update boundaries. The official docs increasingly emphasize careful state structure, reducer patterns, and external store integration for scaling complexity (React docs, useReducer, useSyncExternalStore).

That is where alternative paradigms are gaining attention.

Model 1: React state as render-tree state

React state is tied to component position in the render tree. That gives predictable behavior and a clear mental model when your state is mostly local.

import { useReducer } from 'react'

type State = { count: number }
type Action = { type: 'inc' } | { type: 'dec' }

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case 'inc':
      return { count: state.count + 1 }
    case 'dec':
      return { count: state.count - 1 }
  }
}

Strengths:

• explicit update paths
• testable reducer logic
• mature tooling and patterns

Where teams struggle:

• derived state spread across many components
• broad re-render surfaces when state boundaries are coarse
• coordination overhead between local state, context, and external stores

React is not weak here. It is just opinionated around component-first state.

Model 2: Signals as dependency-tracked state

Signals model state as observable values that track dependencies on read and notify consumers on change. Preact, Angular, and Solid all now have strong signal-based primitives (Preact Signals, Angular Signals, Solid createSignal).

import { signal, computed } from '@preact/signals'

const count = signal(0)
const doubled = computed(() => count.value * 2)

count.value += 1

Strengths:

• fine-grained updates by dependency
• less boilerplate for derived values
• easier composition of reactive data flows

Tradeoffs:

• dependency relationships can become implicit if overused
• debugging requires discipline around effects and write boundaries
• team conventions matter more than framework defaults

Signals work best when teams want smaller update surfaces without hand-wiring every selector path.

Model 3: Graph-based visual systems (Pretext angle)

This is where things get interesting. Some systems are not state managers at all, but still represent a shift in how UI work is modeled.

Pretext is a good example. It is a multiline text measurement and layout engine, not a React replacement and not a signal library. But its architecture reflects the same broader trend: move from opaque render passes to explicit dependency graphs and incremental recomputation.

Pretext separates one-time preparation from fast repeat layout:

import { prepare, layout } from '@chenglou/pretext'

const prepared = prepare('AGI 春天到了. بدأت الرحلة', '16px Inter')
const result = layout(prepared, 320, 20)

Key idea:

• expensive analysis happens once (prepare)
• repeated layout operations are cheap arithmetic (layout)
• no DOM measurement loop for every pass

That is not "state management" in the React sense. But it is absolutely part of the same movement toward visual systems that are graph-aware, incremental, and explicit about dependencies.

Side-by-side comparison

So are we moving beyond React?

Beyond React itself, not really.

Beyond React-only state thinking, yes.

The practical pattern today is hybrid:

1. React for composition, routing, and data boundaries.
2. Signals for fine-grained reactive state where render scope matters.
3. Graph-based subsystems for expensive visual or layout-heavy workloads.

This is less about framework loyalty and more about choosing the right computational model for each class of problem.

A pragmatic adoption path

If you want to test this shift without rewriting your app, pick one high-friction area:

• a dashboard panel that updates frequently
• a complex form with heavy derived state
• a visual text or layout surface with performance pressure

Measure baseline behavior first, then introduce one alternative model in isolation. If the mental model and performance improve together, expand from there.

Final note

React is still the center of gravity. But the frontend state story around it is getting more plural. Signals and graph-oriented systems are not hype cycles in opposition to React. They are tools for parts of the problem React's default model does not always solve elegantly at scale.