La foto de 2026: qué explica el desplazamiento

Cerramos el nivel con los números y, sobre todo, con lo que los números significan. En 2026 el dato es nítido: Redux cayó del 57% al 38% de uso mientras Zustand casi triplicó su adopción, y Jotai y Valtio se consolidaron en sus nichos. Pero un porcentaje no explica nada por sí solo; el trabajo del ingeniero maduro no es celebrar la caída sino entender la causa, porque solo la causa se generaliza a la próxima decisión. La tesis de este capítulo es que el desplazamiento no fue una moda ni un veredicto contra la calidad de Redux, sino la conjunción de tres fuerzas que, juntas, encogieron el problema hasta que la herramienta grande dejó de encajar.

Los números y la trampa de leerlos mal

La caída de Redux del 57% al 38% y la casi triplicación de Zustand son reales, pero invitan a dos lecturas perezosas. La primera es la de la moda: la comunidad es voluble y persigue lo nuevo. La segunda es la de la decadencia: Redux se quedó obsoleto. Ambas son falsas y peligrosas, porque quien las cree elegirá la próxima librería por tendencia y no por ajuste. La lectura correcta empieza por una pregunta distinta: si Redux resolvía bien su problema, y sigue resolviéndolo, qué cambió para que la mayoría dejara de necesitar esa solución. La respuesta no está en las librerías de estado, sino en lo que dejó de ser estado.

Hay además una cautela metodológica que conviene tener presente al leer cualquier encuesta de adopción: miden intención, uso declarado o satisfacción, no idoneidad. Que una herramienta suba no prueba que sea mejor para tu caso, y que otra baje no prueba que se haya vuelto peor. Los porcentajes describen hacia dónde se mueve la manada, no hacia dónde deberías moverte tú. Su valor real no es dictar la elección, sino señalar un cambio de fondo que merece explicación —y esa explicación, no el número, es lo que se transfiere a tu decisión.

flowchart TD
T[estado de una app tipica] --> S[estado de servidor]
T --> C[estado de cliente]
S -->|emigra a| Q[TanStack Query y RSC]
C --> G[estado global simple]
C --> L[estado local useState]
G -->|le basta| Z[Zustand 3KB]
style S fill:#f38ba8,color:#11111b
style Q fill:#a6e3a1,color:#11111b
style Z fill:#89b4fa,color:#11111b

Tres fuerzas, no una

Primera fuerza: el estado de servidor se marchó. Vimos en la lección 1 que buena parte de lo que llenaba los stores de Redux eran datos de red cacheados a mano. Cuando TanStack Query, SWR y compañía convirtieron el cacheo, la revalidación y la sincronización de servidor en un problema resuelto y aparte, ese contenido salió de los stores para siempre. No es que la gente dejara Redux por Zustand: es que dejó de meter en cualquier store una categoría entera de estado que nunca debió vivir ahí. Esta es, con diferencia, la fuerza más grande, porque en muchas apps el estado de servidor era la mayoría del store.

Segunda fuerza: los componentes de servidor encogieron el cliente. Con React Server Components y el enrutador de aplicación de Next.js, una porción del estado que antes se hidrataba y gestionaba en el cliente pasó a resolverse en el servidor antes de llegar al navegador. Menos JavaScript de cliente significa menos estado de cliente que coordinar, y por tanto menos superficie para cualquier gestor de estado global. El default del ecosistema se desplazó de todo en el cliente a lo mínimo en el cliente, y con él la cantidad de estado que un gestor global tenía que sostener.

Tercera fuerza: lo que quedó era pequeño. Restadas las dos categorías anteriores, el estado global de cliente que sobrevive en la app mediana es modesto: sesión, tema, preferencias de interfaz, un carrito, algún modal. Para eso, un framework de 15KB con cuatro conceptos es desproporcionado, y un hook de 3KB es exacto. La adopción de Zustand no creció porque fuera un Redux mejor, sino porque el problema encogió hasta el tamaño de Zustand. La causa y el efecto son fáciles de invertir aquí, y hacerlo lleva a la conclusión equivocada: no ganó la herramienta pequeña, se reveló pequeño el problema.

Las tres fuerzas no actuaron por separado ni en cualquier orden: se reforzaron entre sí. Al sacar el estado de servidor se vació la mayor parte del store; al mover render al servidor se redujo el estado de cliente restante; y sobre ese residuo diminuto, el peso de la herramienta pasó de ser un detalle a ser un factor decisivo. Es la composición de las tres, y no ninguna en solitario, la que explica un desplazamiento tan grande en tan pocos años.

Elegir en 2026: un mapa, no un ganador

La conclusión operativa no es hay un ganador sino hay un mapa. Cada herramienta ocupa la posición para la que su modelo mental coincide con la forma del problema, y elegir bien es hacer coincidir forma con forma, no popularidad con proyecto.

Y ese emparejamiento es más una habilidad de diagnóstico que de catálogo. No consiste en memorizar cuatro nombres y sus pesos, sino en aprender a mirar un fragmento de estado y reconocer su forma: si es un puñado de valores sueltos, si es un grafo de dependencias, si es una escritura imperativa, o si es estado de servidor disfrazado. Sabido eso, la herramienta casi se elige sola, y da igual cuáles sean las de moda el año en que leas esto.

Antes que cualquiera de esas cuatro, aplica el filtro que resume todo el nivel: la mayor parte de tu estado quizá no sea de cliente. Saca primero el estado de servidor a una caché de datos, resuelve lo local con useState o useReducer, y solo entonces mira qué estado global de cliente queda de verdad. Es habitual que, hecho ese cribado, el residuo sea tan pequeño que la elección entre las tres ligeras importe menos que el hecho de no haber alcanzado Redux por reflejo.

El cribado se puede escribir como código, y hacerlo revela que la parte difícil no es elegir librería sino clasificar el estado con honestidad:

// Primero clasifica cada porcion de estado; la libreria es lo ultimo que decides.
type Clase = 'servidor' | 'local' | 'clienteSimple' | 'derivado' | 'imperativo'

function herramienta(clase: Clase): string {
  switch (clase) {
    case 'servidor':      return 'TanStack Query, no un store'
    case 'local':         return 'useState o useReducer'
    case 'clienteSimple': return 'Zustand'
    case 'derivado':      return 'Jotai'
    case 'imperativo':    return 'Valtio'
  }
}

La función caricaturiza pero no miente: el switch es trivial, y la dificultad entera está en asignar bien la Clase de cada dato, sobre todo en reconocer cuánto de lo que llamas estado de cliente era estado de servidor disfrazado. Hecha esa clasificación con rigor, el mapa se recorre casi solo, igual que el árbol de decisión del cierre de nivel que ya conoces.

Lo que no cambió: dónde Redux sigue en su sitio

Un capítulo honesto sobre el desplazamiento debe nombrar también lo que resistió. Redux no cayó al cero, se estabilizó en un 38% que dista de ser marginal, y ese suelo no es inercia: es la porción de problemas para los que su ceremonia es inversión y no peaje. En bases de código grandes, con muchos desarrolladores tocando el mismo estado, las convenciones estrictas de Redux —acciones nombradas, reductores puros, un único árbol auditable— documentan un protocolo compartido que un store libre no impone. El time-travel debugging sigue sin rival para depurar flujos complejos, y RTK Query es una solución de estado de servidor madura y muy capaz. Donde el estado es genuinamente grande y el equipo también, la estructura que a la app pequeña le sobra, a la grande le falta.

Conviene además no confundir el 38% con estancamiento. Redux sigue recibiendo mantenimiento activo, RTK incorpora mejoras y su documentación es de las mejores del ecosistema. Una herramienta que se estabiliza en su nicho natural tras perder los casos que nunca le correspondieron no está en declive: está encontrando su nivel. El declive real habría sido quedarse como default reflejo mientras el problema medio la desbordaba por exceso, y de ese destino la ola ligera la salvó tanto como salvó a sus usuarios.