The TanStack Ecosystem: How We Build Websites and Web Apps the Right Way

Before we talk about any specific library, we need to talk about rendering strategy. The choice between server-side rendering (SSR) and a single-page application (SPA) is architectural, and getting it wrong early creates expensive problems later.

When you need SSR: public-facing websites

If your project is a public-facing website, a company site, a marketing page, a blog, a content-driven product, SSR is not optional. It is the correct choice. Here is why:

• Search engine discoverability. Search crawlers, especially non-Google ones, do not reliably execute JavaScript. If your content only exists in the DOM after a client-side render, it may not get indexed. With SSR, the full HTML is delivered from the server, no JavaScript required to see your content.
• Core Web Vitals. Google uses Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) as ranking signals. SSR dramatically improves LCP by delivering fully-rendered HTML on the first byte, rather than waiting for JavaScript to download, parse, and execute.
• Social sharing and link previews. When someone shares a link on LinkedIn or Slack, the Open Graph metadata is read from the server response. With a SPA, there may be nothing to read.
• Perceived performance. Users see meaningful content faster, even on slower connections, because the browser is rendering HTML rather than waiting for a JavaScript bundle.

When a SPA makes sense: authenticated web applications

The calculus changes entirely for authenticated, private web applications, dashboards, internal tools, data platforms, customer portals. These products typically sit behind a login, which means:

• Search engines cannot crawl them anyway, SEO is irrelevant.
• The user experience is session-based and stateful, often with complex client-side interactions.
• Time-to-interactive matters more than time-to-first-paint.
• The data is user-specific and cannot be meaningfully pre-rendered on the server.

In these cases, a SPA built on TanStack Router alone, without the full SSR machinery of TanStack Start, is often a leaner, faster, and more appropriate choice. You get all the type-safe routing power without the overhead of a server rendering pipeline you do not need.

“The rendering strategy you choose is not a technical detail, it is a product decision. The right answer depends on who needs to find your content and how.”

TanStack Start is a full-stack React framework built on top of TanStack Router. It brings together file-based routing, server functions, streaming SSR, and end-to-end TypeScript in a way that keeps the underlying mechanics visible and understandable, without hiding them behind heavy abstractions.

For public-facing websites, Start is our go-to choice. The server-rendering pipeline delivers fully-formed HTML on the initial request, search crawlers see real content, and Open Graph tags are populated correctly on every page. You get the SEO and performance benefits of a traditional server-rendered site with the full power of a modern React component model.

What makes Start particularly well-suited for client work is its server functions, typed, co-located functions that execute on the server but can be called from client components like any other async function. This eliminates the friction of maintaining a separate API layer for simple data fetching needs, while still keeping a clear boundary between server and client code.

Streaming SSR means users see content progressively, fast initial paint, with slower data arriving as it becomes available, which improves both perceived performance and Core Web Vitals scores on content-heavy pages. Start handles this with minimal ceremony, which matters when you are shipping real products under real deadlines.

TanStack Router is the routing layer underneath TanStack Start, and it is also a standalone routing solution for SPA projects. It is the most type-safe client-side router available in the React ecosystem, and that is not a marketing claim, it is a measurable difference in how you work.

Every route, every URL parameter, and every search parameter is fully typed. If a route expects a numeric id parameter, TypeScript knows that. If you try to link to a route with the wrong parameter shape, the compiler catches it, not the user at runtime. For applications with complex navigation, deeply nested views, and URL-driven state, this eliminates an entire class of bugs.

Search params as first-class state

One of Router's standout features is its treatment of URL search parameters as typed, validated state. Filters, pagination, sort order, selected tabs, any piece of UI state that benefits from being shareable via URL can be managed through search params with full TypeScript support. Users get shareable links. Developers get type safety. Everyone wins.

For web applications that live behind a login, dashboards, internal tools, client portals, Router alone is often the right choice. No server rendering machinery, no SSR pipeline, just a lean and powerful client-side routing layer that keeps the application fast and the codebase focused.

TanStack Query is the library that made async state management feel sane. Before Query (then known as React Query), managing server state meant sprawling useEffect chains, hand-rolled loading states, manual cache invalidation, and a lot of bugs that were subtle and hard to reproduce. Query changed that completely.

The core insight is that server data, data that lives on an API and needs to be fetched, cached, and kept in sync, is fundamentally different from local UI state. Query treats it differently. You define a query with a key and a fetch function, and Query handles caching, background refetching, stale data policies, and error states automatically.

In practice, this means components can declare what data they need and trust Query to provide it, without worrying about whether it has already been fetched, whether it is still fresh, or whether multiple components requesting the same data will result in multiple network requests. The result is dramatically simpler components and dramatically fewer data-related bugs.

Query integrates naturally with TanStack Start and Router. Loader functions on routes can pre-fetch query data on the server, so components hydrate instantly with data already in the cache. It is one of those integrations that genuinely feels like it was designed together, because it was.

Forms are genuinely hard. They involve synchronous and asynchronous validation, field-level and form-level error states, submission state management, and an endless variety of UI patterns. TanStack Form handles all of it without runtime magic or hidden abstractions.

The approach is headless by design. Form does not render anything itself, it manages state and validation logic, and you wire it to whatever UI you are using. That means full control over markup, accessibility, and styling, while Form handles the parts that are genuinely hard to get right.

TypeScript integration is unusually complete. Field values, validation schemas, and submission payloads are all typed end-to-end. If your form has a field called email that expects a string, TypeScript enforces that at every point where you interact with it, reading the value, validating it, and submitting it. Mismatches become compile errors, not runtime surprises.

Async validation, checking whether a username is available, validating an address against an external service, is a first-class feature, not an afterthought. Debouncing, loading states, and cancellation are all handled by the library. The result is forms that behave well under real-world conditions without requiring custom plumbing for every edge case.

TanStack DB is the newest major addition to the ecosystem, and it addresses a real gap: what happens when your application needs a reactive, queryable client-side data layer that goes beyond what a standard fetch-and-cache model can provide?

Think of it as a reactive, client-first store with live queries and optimistic mutations. You define collections of data, write queries against them, and any component observing those queries re-renders automatically when the underlying data changes, whether that change comes from a server sync, a local mutation, or an optimistic update.

This is particularly valuable for applications where data changes frequently and UI needs to stay in sync without full round-trips to the server. Optimistic mutations let you update the UI immediately while the server request is in flight, then reconcile when the response arrives, giving users a fast, responsive experience even over slower connections.

For the kinds of data-intensive web applications Select Interactive builds, platforms with real-time updates, complex filtering, and multi-user state, TanStack DB provides exactly the primitives needed without the overhead of a full offline-first sync engine. It is the right level of sophistication for most production use cases.

TanStack Table is the library that first established the headless pattern in the React ecosystem, and it remains the best implementation of it. If your application needs to display, sort, filter, group, or paginate tabular data, Table handles the logic while leaving every pixel of the UI to you.

The headless approach matters more than it might initially appear. Pre-built table components, the kind you drop in from a UI library and get a working grid, are fast to start with and painful to customize. The moment your design or data requirements deviate from the library's assumptions, you are fighting the library instead of building your product. Table eliminates that fight entirely.

Column definitions, sorting logic, filter functions, pagination controls, row selection, and column visibility are all managed by the Table instance. Your markup renders whatever the Table state describes, which means it works with any component library, any styling system, and any design spec you bring to it.

For enterprise and data-driven projects, this is the difference between a table component that fits the design and one that dictates it. Combined with TanStack Query for server-side pagination and filtering, it forms a complete and efficient solution for handling large datasets without loading everything into the client.

TanStack AI is the ecosystem's answer to a question the web development community has been wrestling with: how do you build AI-powered UI features without locking yourself into a single provider, a proprietary SDK, or an opinionated abstraction that will be difficult to change later?

The answer, consistent with every other TanStack library, is headless primitives with a unified interface. TanStack AI provides the state management, streaming response handling, and conversation state scaffolding needed to build AI-powered features, chat interfaces, content generation tools, AI-assisted forms, intelligent search, without caring which model provider is powering them.

Streaming responses, where text arrives token by token rather than in a single payload, are handled natively. This is critical for AI interfaces because it makes the experience feel fast and responsive even when model latency is measurable. Without proper streaming support, AI features feel sluggish. With it, they feel alive.

For Select Interactive, TanStack AI represents the natural extension of a stack we already trust. Rather than reaching for a separate AI SDK with its own state model and component patterns, we can integrate AI features into existing TanStack Start and Router applications using the same mental model. The same headless philosophy, the same TypeScript-first design, the same respect for developer control. It fits.

As AI capabilities become table stakes for web products, and they are heading there fast, having a composable, provider-agnostic layer for those features is not a nice-to-have. It is an architectural decision that determines how much flexibility you retain as the AI landscape continues to evolve. We'd rather be building on a foundation that doesn't bet everything on a single vendor's API.