TanStack nel 2026: Query, Router, Start e cosa risolve ciascuno

TanStack è una famiglia di librerie headless e indipendenti dal framework, ognuna delle quali risolve un problema difficile del frontend: stato del server, routing, tabelle, form, virtualizzazione e ora anche un framework full-stack. Installi solo i pezzi che ti servono. Nessuno presume che tu usi gli altri, ed è per questo che un team Next.js e un team Vue possono usare gli stessi strumenti.

Il nome viene da Tanner Linsley, che nel 2019 ha creato TanStack Query (allora React Query). Sette anni dopo, la stessa idea, logica headless senza opinioni sulla tua UI, gira su otto librerie. Se costruisci app React ricche di dati, dashboard, pannelli di amministrazione, tool interni, probabilmente ne hai già usata una in produzione.

La versione in 30 secondi

Parti da Query. Gestisce i dati che vivono sul tuo server. Aggiungi Router se stai iniziando una nuova app e vuoi una navigazione type-safe. Aggiungi Table, Form o Virtual quando incontri il problema specifico che ciascuno risolve. Usa Start solo se vuoi un framework full-stack basato su Vite al posto di Next.js. Tutto il resto (Store, DB, AI) è più giovane e va tenuto d'occhio prima di affidargli un'app in produzione.

Perché un insieme di librerie separate invece di un unico framework?

La maggior parte degli strumenti frontend spedisce logica e UI saldate insieme. Un date picker arriva con il suo markup e i suoi stili. TanStack fa l'opposto. Ogni libreria spedisce la logica (caching, ordinamento, validazione, gestione del focus), ti passa lo stato e poi si toglie di mezzo. Il markup lo scrivi tu, con i tuoi componenti e il tuo design system.

Questo ha un costo e un vantaggio. Il costo: scrivi più codice di collegamento rispetto a un widget pronto all'uso. Il vantaggio: la libreria non litiga mai con il tuo design system, e lo stesso nucleo funziona in React, Vue, Solid, Angular e Svelte. Per uno studio che spedisce un design system su misura in ogni progetto, l'approccio headless è il motivo per cui ci torniamo sempre.

Le librerie, una per una

TanStack Query: stato del server senza boilerplate

Query è il punto in cui la maggior parte dei team scopre TanStack. Mette in cache ogni risposta del server, deduplica le richieste concorrenti per lo stesso dato, ricarica in background i dati scaduti e ti dà gratis gli stati di caricamento ed errore. In pratica elimina le centinaia di righe di useEffect, flag di caricamento e codice di cache manuale che un tipico layer di fetch accumula.

All'inizio del 2026 supera i 12 milioni di download settimanali su npm, il che lo rende la risposta di default allo stato del server in React. Una cosa che non è: un sostituto di Redux o Zustand. Query gestisce lo stato del server. Il tuo stato client (un flag di modale aperta, una bozza di form, la scelta del tema) ha ancora bisogno di un piccolo store. I due risolvono problemi diversi e convivono bene.

TanStack Router: un routing che il compilatore può controllare

Router lega i parametri dell'URL, i search params, i dati dei loader e i link a un unico albero di rotte generato, tutto controllato dai tipi in fase di build. Rinomina una rotta o cambia un parametro e TypeScript ti segnala ogni link rotto prima ancora di avviare l'app. Un team ha raccontato che un refactoring degli URL su un codebase grande è passato da mezza giornata di controllo manuale a un controllo dei tipi di dieci secondi.

Il routing a file di Next.js funziona, ma la sua type safety è sottile: un plugin dell'editor per i suggerimenti sui link, non una garanzia in fase di compilazione. Se il tuo prodotto è una dashboard con URL profondi e parametrizzati, Router si guadagna il posto. È anche la base su cui si costruisce il framework full-stack.

TanStack Start: l'opzione full-stack basata su Vite

Start ha raggiunto la v1.0 a marzo 2026. Poggia su Vite e su TanStack Router e aggiunge SSR, server function e streaming. Il modello è client-first con rendering server opzionale, l'opposto di Next.js, che è server-first e ti chiede di abilitare il comportamento client con 'use client'. Start si deploya ovunque giri Nitro, quindi non sei legato a un singolo host.

Ha vinto il Breakthrough of the Year ai 2026 Open Source Awards, il che indica slancio, non maturità. Start è stabile ma giovane. Per un sito marketing ricco di contenuti, o per un team già dentro il flusso Next.js e Vercel, Next.js resta la scelta più sicura e più facile da coprire con nuove assunzioni.

Table, Form e Virtual: il centro collaudato

Table è un motore headless per ordinamento, filtri, raggruppamento e paginazione che colleghi al tuo markup di tabella. Virtual disegna solo le righe visibili sullo schermo, così una lista da 100.000 righe resta fluida. Form ha raggiunto la v1 e copre React, Vue, Angular, Solid e Lit con validazione type-safe. Tutti e tre sono pronti per la produzione, e lo sono da un pezzo. Aggiungili il giorno in cui incontri il problema che risolvono, non prima.

Store, DB e AI: da osservare, non su cui scommettere ancora

Store è il piccolo nucleo reattivo su cui si appoggiano le altre librerie, utile anche da solo per uno stato client leggero. DB è più recente: un database lato client costruito su differential dataflow che si aggancia alle tue chiamate useQuery esistenti, ancora pre-1.0 alla v0.6. AI è il più giovane, e ha vinto l'AI Project of the Year agli stessi premi del 2026. Valgono un prototipo. Non valgono una dipendenza in produzione finché non si assestano.

Come adottarlo senza una grande riscrittura

A TanStack non si migra. Si aggiunge una libreria alla volta. Il percorso tipico: inserisci Query in un'app esistente, avvolgi il fetch dei dati di una schermata in un hook useQuery ed elimina lo useEffect e lo stato di caricamento che sostituisce. Spedisci. Misura. Se l'app è nuova e piena di rotte, la costruisci su Router come passo successivo. Tabelle e form arrivano dopo, schermata per schermata, dove la versione fatta a mano ha iniziato a fare male.

Questo percorso incrementale è tutto il senso di un design headless a scopo singolo. Ogni libreria sta in piedi da sola, quindi non sei mai costretto a una riscrittura tutto-o-niente per trarre valore da un pezzo solo. Un team può tenere Query in produzione per un anno senza toccare il resto.

Quando TanStack va bene, e quando no

Usa le librerie TanStack quando la tua app è ricca di dati e interattiva: dashboard, back office di un SaaS, tool interni, tutto ciò che ha tabelle e form su dati live del server. Il design headless rende di più quando gestisci un design system su misura e vuoi il controllo completo del markup.

Usane di meno quando il sito è per lo più contenuto statico. Un sito marketing o un blog non ha bisogno di Query o Router. Bastano i server component e un semplice fetch. E non adottare tutto l'insieme il primo giorno. I manutentori lo dicono chiaro: parti da Query, aggiungi Router su una build nuova, aggiungi il resto solo quando emerge un problema reale.

Dove si colloca rispetto al resto del tuo stack

Query si abbina al tuo framework, non lo sostituisce. Puoi usarlo dentro Next.js oggi stesso e aggiungere Router più avanti, o mai. La stessa disciplina che rende Router utile, prendere gli errori in fase di compilazione, è il motivo per cui teniamo la modalità strict di TypeScript sempre attiva in ogni progetto.