TanStack Start v1 RC — серьёзная альтернатива Next.js или очередной хайп?

Когда Theo (t3.gg) — человек чей бренд буквально построен на T3-стеке с Next.js — публично говорит «TanStack Start выглядит отлично», это сигнал что в экосистеме что-то меняется. TanStack Start достиг v1.0 Release Candidate, и за несколько месяцев RC-стадии успел накопить реальные продакшн-кейсы и честную критику.

Почему это появилось

Next.js с версии 13 стал всё сложнее для понимания. App Router, React Server Components по умолчанию, директивы 'use client' и 'use server', кэширование которое в 14-й версии было включено по умолчанию, а в 15-й — выключено. Каждый мажорный релиз переворачивал ментальную модель.

TanStack Start — это ответ команды Tanner Linsley на накопившееся раздражение: фреймворк с явными решениями вместо магии, клиент-ориентированной архитектурой с опциональным SSR, и сквозной типизацией как первоклассной фичей.

«Мы не ищем ещё один фреймворк ради фреймворка. Мы хотим снова получать удовольствие от сборки без борьбы с инструментом который выбрали чтобы помогать» — Dev.to

Что внутри

В основе стека — TanStack Router и Vite. 90% любого фреймворка — это роутер, и Start целиком наследует Router с его инферированной системой типов.

Серверные функции вместо API-роутов

Вместо отдельных файлов API-роутов — createServerFn:

import { createServerFn } from '@tanstack/start'
 
const getUser = createServerFn()
  .validator((id: string) => id)
  .handler(async ({ data: id }) => {
    return await db.user.findUnique({ where: { id } })
  })
 
// Вызов со стороны клиента — полностью типизирован
const user = await getUser({ data: userId })

Тип ответа автоматически инферируется из handler — никакого ручного описания API-контракта. Разработчики в комьюнити отмечают что это «полностью заменяет потребность в tRPC/GraphQL/REST» для большинства случаев.

URL как типизированное состояние

Один из самых недооценённых аспектов — search params как полноценное типизированное состояние с runtime-валидацией через Zod:

const Route = createFileRoute('/products')({
  validateSearch: z.object({
    page: z.number().default(1),
    filter: z.string().optional(),
  }),
})

Параметры URL теперь не string | undefined из useSearchParams() — они типизированы и валидированы.

Что говорит сообщество

Реакция разделилась предсказуемо. Те кто пришёл из проектов на TanStack Router и TanStack Query — в восторге. Переход на Start для них органичен: те же концепции, добавленные серверные примитивы. Один разработчик на InfoQ описал опыт: «серверные функции полностью заменили потребность в tRPC, middleware компонуемый и полностью типизирован».

Критика сосредоточена на двух точках. Первое — RSC пока не готовы, они в активной разработке и появятся как non-breaking v1.x дополнение. Для проектов где Server Components критичны — преждевременно. Второе — активный memory leak в TanStack Form (issue #5734 на GitHub) остаётся открытым, что заставляет часть разработчиков ждать перед продакшн-деплоем.

Стоит ли переходить с Next.js

Прямой ответ: зависит от типа проекта.

TanStack Start выигрывает там где важна клиент-ориентированная интерактивность, сложная навигация с типизированными параметрами, и хочется избежать магии Next.js App Router. SaaS-приложения, дашборды, интерактивные инструменты — хорошая территория.

Next.js остаётся сильнее для контент-ориентированных сайтов где RSC и server-first архитектура — не опциональная фича, а суть подхода.

Здоровая конкуренция в экосистеме — это хорошо. TanStack Start не убивает Next.js, он даёт реальную альтернативу тем кто устал от постоянно меняющихся дефолтов.