Elegir en 2026: el árbol de decisión honesto

Esta es la lección que la mayoría de la gente busca cuando llega a un track como este, y por eso conviene decir desde la primera línea que no va a haber un ganador. Habrá algo mejor: un procedimiento que hace la elección casi mecánica una vez has hecho el trabajo previo, y una estimación honesta del coste de equivocarse en cada dirección, que es el dato que de verdad debería gobernar una decisión reversible. La tesis de fondo es que la pregunta popular —cuál es el mejor gestor de estado— es incontestable no porque falte información sino porque está mal formulada, y que su versión correcta, cuál es la herramienta mínima para esta clase de dato en este equipo y este dominio, tiene una respuesta casi siempre evidente en cuanto se hacen tres preguntas en el orden debido.

Descontar el ruido antes de decidir

Tres factores aparecen en toda comparación pública y ninguno de los tres debería pesar apenas en la decisión. El primero es el tamaño del paquete. La diferencia entre las opciones de esta lección se mide en unos pocos kilobytes comprimidos, una cifra que queda por debajo del ruido en cualquier aplicación que ya cargue un framework, una librería de gráficos y tres fuentes tipográficas. Es un argumento legítimo en una isla interactiva de un sitio estático y casi irrelevante en un panel de gestión, y sin embargo se esgrime igual en ambos casos.

El segundo es la popularidad. El número de descargas mide la inercia de las bases de código existentes, no la calidad de la herramienta para tu problema; buena parte del volumen de Redux corresponde a proyectos escritos hace ocho años que nadie va a reescribir. Como señal de riesgo tiene algo de valor —una librería con un solo mantenedor y sin actividad es un riesgo real— pero como criterio de elección entre cuatro opciones todas sanas y mantenidas, no discrimina nada.

El tercero, y el más contaminante, es la experiencia previa del que decide. Es un factor legítimo y hay que contarlo, pero hay que contarlo con su nombre: si el equipo lleva cuatro años con Redux Toolkit, ese conocimiento acumulado vale más que las ventajas marginales de cualquier alternativa, y decir eso en voz alta es una decisión de ingeniería impecable. Lo que corrompe la discusión es disfrazar esa preferencia de argumento técnico y sostener que la herramienta que uno conoce es objetivamente superior.

El árbol honesto

Con el ruido descontado y el estado repartido, el árbol tiene tres preguntas y cuatro hojas. Las preguntas van en este orden y no en otro, porque cada una vuelve irrelevante a la siguiente cuando se responde que no.

flowchart TD
E[estado de cliente compartido] --> Q1{hay poco y no lo lee media app}
Q1 -->|si| NADA[nada: estado local mas contexto o la url]
Q1 -->|no| Q2{el dominio exige trazabilidad estricta}
Q2 -->|si| RTK[redux toolkit]
Q2 -->|no| Q3{es un grafo de valores derivados unos de otros}
Q3 -->|si| JOTAI[jotai]
Q3 -->|no| ZUS[zustand]
style NADA fill:#cba6f7,color:#11111b
style RTK fill:#89b4fa,color:#11111b
style JOTAI fill:#f9e2af,color:#11111b
style ZUS fill:#a6e3a1,color:#11111b

La primera hoja es la que más cuesta aceptar y la más frecuentemente correcta: no usar nada. Si el estado compartido son tres o cuatro valores estables que cambian poco —el tema, el idioma, el usuario ya cacheado—, un contexto con un valor memoizado los resuelve sin dependencias. La objeción clásica es que el contexto renderiza a todos sus consumidores en cada cambio, y es cierta, pero el matiz decide el caso: para valores que cambian una vez cada varios minutos, esa penalización es inobservable. El contexto es mal gestor de estado que cambia rápido y buen distribuidor de valores estables, y confundir esas dos cosas es lo que hizo que se ganase una mala fama que no siempre merece.

// La hoja mas barata, escrita bien: un contexto por valor y no un contexto para todo.
const TemaCtx = createContext<Tema>('claro')
const SesionCtx = createContext<Sesion | null>(null)

// Separarlos importa mas que memoizar: un cambio de tema no debe tocar
// a quien solo lee la sesion. Un contexto con un objeto de diez campos
// convierte cualquier cambio en un render de todos sus consumidores.
export function useValorTema() {
  const [tema, setTema] = useState<Tema>('claro')
  return useMemo(() => ({ tema, setTema }), [tema]) // referencia estable
}

La segunda pregunta —si el dominio exige trazabilidad estricta— es la única que apunta a Redux Toolkit sin ambigüedad, y conviene definirla con precisión para que no signifique lo que a cada uno le apetezca. Exige trazabilidad estricta un dominio en el que haya que reconstruir qué pasó a partir de un informe de error, en el que exista deshacer profundo, en el que los cambios deban auditarse por obligación regulatoria, en el que varias pantallas coordinen un mismo proceso largo, o en el que el equipo sea lo bastante grande como para que la convención valga más que la libertad. Ninguna de esas condiciones se cumple en la mayoría de productos, y por eso la respuesta honesta a la segunda pregunta suele ser no.

Los cuatro empates y cómo se rompen

El árbol resuelve la mayoría de los casos, pero hay cuatro situaciones en las que dos hojas empatan de verdad y hace falta un criterio adicional. Fingir que el árbol las resuelve sería el tipo de deshonestidad que esta lección quiere evitar.

El cuarto empate merece una nota aparte porque su respuesta contradice un instinto muy extendido. Usar dos gestores en el mismo producto no es un fallo de arquitectura si cada uno tiene un territorio declarado; lo que es un fallo es que el mismo dato pueda vivir en cualquiera de los dos. Un carrito en Zustand y un grafo de configuración derivada en Jotai conviven sin problema mientras el plano diga cuál va dónde. Lo que produce caos no es la pluralidad de herramientas sino la ausencia de fronteras, y ese es exactamente el mismo diagnóstico que el de las costuras de la lección anterior.

// La frontera de escritura no la da la libreria: la das tu, en cualquiera de ellas.
// Zustand sin frontera: cualquiera escribe lo que quiera desde donde quiera.
const malo = create((set) => ({ items: [], set }))

// Zustand con frontera: acciones nombradas y nada de set desnudo hacia fuera.
const useCarrito = create<Estado>((set, get) => ({
  items: [],
  anadir: (id: string) => set({ items: [...get().items, id] }),
  vaciar: () => set({ items: [] }),
}))

// La diferencia no aparece en el paquete ni en el rendimiento:
// aparece a los dos anos, cuando alguien pregunta quien vacio el carrito.

Ese fragmento resume por qué la elección de librería importa menos de lo que parece. La garantía que de verdad decide si una base de código envejece bien —que exista un conjunto estrecho y nombrado de formas de escribir— se puede tener o perder en las cuatro hojas del árbol. Redux Toolkit la impone y por eso cuesta ceremonia; Zustand la permite y por eso hay que decidirla; el contexto la exige a mano; Jotai la reparte entre átomos de escritura. La herramienta cambia quién se encarga de mantener la garantía, no si la garantía hace falta.

Equivocarse: el coste asimétrico de cada error

La pregunta que debería cerrar cualquier decisión reversible no es cuál es la mejor opción sino cuánto cuesta corregir cada error posible, y en este caso los costes son marcadamente asimétricos, lo que permite decidir con mucha menos angustia de la que suele acompañar a estas discusiones.

La lectura de esa tabla es la conclusión práctica del nivel entero: el error de librería es barato y el error de reparto es caro. Puedes cambiar Zustand por Jotai en un mes de trabajo repartido; no puedes deshacer con la misma facilidad haber tratado la mitad de la aplicación como estado propio cuando era una copia del servidor, porque eso no vive en un archivo de configuración sino en cada componente que lee, escribe y sincroniza. De ahí se deduce dónde debe ir el cuidado: mucho en el plano, poco en el catálogo.