TanStack en 2026: Query, Router, Start y qué resuelve cada uno

TanStack es una familia de librerías headless e independientes del framework, cada una de las cuales resuelve un problema difícil del frontend: estado del servidor, routing, tablas, formularios, virtualización y ahora también un framework full-stack. Instalas solo las piezas que necesitas. Ninguna da por hecho que uses las demás, y por eso un equipo de Next.js y uno de Vue pueden usar las mismas herramientas.

El nombre viene de Tanner Linsley, que en 2019 creó TanStack Query (entonces React Query). Siete años después, la misma idea, lógica headless sin opinión sobre tu UI, corre en ocho librerías. Si construyes apps de React con muchos datos, dashboards, paneles de administración, herramientas internas, probablemente ya hayas puesto una en producción.

La versión en 30 segundos

Empieza por Query. Gestiona los datos que viven en tu servidor. Añade Router si estás empezando una app nueva y quieres navegación type-safe. Añade Table, Form o Virtual cuando te topes con el problema concreto que resuelve cada uno. Usa Start solo si quieres un framework full-stack basado en Vite en lugar de Next.js. Todo lo demás (Store, DB, AI) es más joven y conviene vigilarlo antes de apostar una app en producción por ello.

¿Por qué un conjunto de librerías separadas en vez de un solo framework?

La mayoría de las herramientas de frontend entregan lógica y UI soldadas. Un selector de fechas viene con su propio marcado y sus estilos. TanStack hace lo contrario. Cada librería entrega la lógica (caché, ordenación, validación, manejo del foco), te pasa el estado y luego se aparta. El marcado lo escribes tú, con tus componentes y tu design system.

Eso tiene un coste y una ventaja. El coste: escribes más código de conexión que con un widget listo para usar. La ventaja: la librería nunca pelea con tu design system, y el mismo núcleo funciona en React, Vue, Solid, Angular y Svelte. Para un estudio que entrega un design system a medida en cada proyecto, headless es la razón por la que volvemos a él.

Las librerías, una por una

TanStack Query: estado del servidor sin boilerplate

Query es donde la mayoría de los equipos descubre TanStack. Cachea cada respuesta del servidor, deduplica las peticiones concurrentes por el mismo dato, recarga en segundo plano los datos caducados y te da gratis los estados de carga y error. En la práctica elimina los cientos de líneas de useEffect, banderas de carga y código de caché manual que acumula una capa de fetch típica.

A principios de 2026 supera los 12 millones de descargas semanales en npm, lo que lo convierte en la respuesta por defecto al estado del servidor en React. Una cosa que no es: un sustituto de Redux o Zustand. Query gestiona el estado del servidor. Tu estado de cliente (una bandera de modal abierta, un borrador de formulario, la elección de tema) sigue necesitando un pequeño store. Los dos resuelven problemas distintos y conviven bien.

TanStack Router: un routing que el compilador puede comprobar

Router ata los parámetros de la URL, los search params, los datos de los loaders y los enlaces a un único árbol de rutas generado, todo comprobado por tipos en tiempo de build. Renombra una ruta o cambia un parámetro y TypeScript marca cada enlace roto antes de arrancar la app. Un equipo contó que un refactor de URLs en una base de código grande pasó de media jornada de revisión manual a una comprobación de tipos de diez segundos.

El routing por archivos de Next.js funciona, pero su type safety es fina: un plugin del editor para sugerencias de enlaces, no una garantía en tiempo de compilación. Si tu producto es un dashboard con URLs profundas y parametrizadas, Router se gana su sitio. También es la base sobre la que se construye el framework full-stack.

TanStack Start: la opción full-stack basada en Vite

Start llegó a la v1.0 en marzo de 2026. Se apoya en Vite y en TanStack Router y añade SSR, server functions y streaming. El modelo es client-first con renderizado de servidor opcional, lo contrario de Next.js, que es server-first y te pide activar el comportamiento de cliente con 'use client'. Start se despliega donde corra Nitro, así que no quedas atado a un solo host.

Ganó el Breakthrough of the Year en los 2026 Open Source Awards, lo que indica impulso, no madurez. Start es estable pero joven. Para un sitio de marketing con mucho contenido, o para un equipo ya metido en el flujo de Next.js y Vercel, Next.js sigue siendo la opción más segura y más fácil de cubrir con nuevas contrataciones.

Table, Form y Virtual: el centro probado

Table es un motor headless para ordenación, filtros, agrupación y paginación que conectas a tu propio marcado de tabla. Virtual dibuja solo las filas visibles en pantalla, lo que mantiene fluida una lista de 100.000 filas. Form llegó a la v1 y cubre React, Vue, Angular, Solid y Lit con validación type-safe. Los tres están listos para producción, y lo están desde hace tiempo. Añádelos el día en que te topes con el problema que resuelven, no antes.

Store, DB y AI: observa, no apuestes todavía

Store es el pequeño núcleo reactivo en el que se apoyan las otras librerías, útil por sí solo para un estado de cliente ligero. DB es más reciente: una base de datos del lado del cliente construida sobre differential dataflow que se engancha a tus llamadas useQuery existentes, todavía pre-1.0 en la v0.6. AI es la más joven, y ganó el AI Project of the Year en los mismos premios de 2026. Merecen un prototipo. No merecen una dependencia en producción hasta que se asienten.

Cómo adoptarlo sin una gran reescritura

A TanStack no se migra. Se añade una librería a la vez. El camino habitual: mete Query en una app existente, envuelve el fetch de datos de una pantalla en un hook useQuery y borra el useEffect y el estado de carga que sustituye. Publica eso. Mide. Si la app es nueva y tiene muchas rutas, la montas sobre Router como siguiente paso. Tablas y formularios llegan después, pantalla a pantalla, donde la versión hecha a mano ha empezado a doler.

Este camino incremental es todo el sentido de un diseño headless de propósito único. Cada librería se sostiene sola, así que nunca te ves forzado a una reescritura de todo o nada para sacar valor de una sola pieza. Un equipo puede tener Query en producción durante un año sin tocar el resto.

Cuándo encaja TanStack, y cuándo no

Usa las librerías de TanStack cuando tu app tiene muchos datos y es interactiva: dashboards, back office de un SaaS, herramientas internas, cualquier cosa con tablas y formularios sobre datos en vivo del servidor. El diseño headless rinde más cuando gestionas un design system a medida y quieres el control total del marcado.

Usa menos cuando el sitio es sobre todo contenido estático. Un sitio de marketing o un blog no necesita Query ni Router. Bastan los server components y un fetch sencillo. Y no adoptes todo el conjunto el primer día. Los mantenedores lo dicen claro: empieza por Query, añade Router en una build nueva, añade el resto solo cuando aparezca un problema real.

Dónde se sitúa junto al resto de tu stack

Query se combina con tu framework, no lo sustituye. Puedes usarlo dentro de Next.js hoy mismo y añadir Router más adelante, o nunca. La misma disciplina que hace que Router valga la pena, atrapar los errores en tiempo de compilación, es la razón por la que mantenemos el modo strict de TypeScript siempre activo en cada proyecto.