Overview of 954: Fullstack TanStack! The Scoop with Tanner Linsley
Wes Bos and Scott Tolinski grab Tanner Linsley at GitHub Universe for a quick, wide-ranging conversation about the current state and future of TanStack libraries. The discussion covers TanStack DB (a client-side sync engine), TanStack Start and Router work, thoughts on Next.js’s new workflow directive and compiler directives in general, a fresh perspective on server components, team growth, and hints about an upcoming (undisclosed) TanStack project.
Main topics discussed
- TanStack DB: what it is and how it works (client-side sync engine, collections, schema-driven queries, transaction model).
- Incremental adoption and integration with existing backends (REST, WebSockets, React Query, IndexedDB).
- Next.js “use workflow” / durable workflows: pros, use cases, and the directive debate.
- Directives vs explicit APIs/wrappers: Tanner’s critique of directive proliferation and the importance of type safety and traceability.
- Server components: Tanner’s “server elements” insight and an alternative approach he’s prototyping for TanStack Start.
- TanStack team growth and a teased new library (undisclosed, community working group involved).
TanStack DB — deep dive
- Purpose: A client-side sync engine (the client half) designed for super-fast local queries and incremental adoption.
- Primary model:
- Collections = tables. You define schema for collections (schema-based for type safety and queryability).
- Query engine supports joins, WHERE clauses, and complex queries; uses differential data flow for speed.
- Data feeding options:
- Push data into collections from anywhere: REST responses, React Query, WebSockets, IndexedDB, live event streams.
- This makes TanStack DB agnostic to backend transport and incrementally adoptable.
- Mutations & syncing:
- Built-in transaction framework: common operations (insert/update/delete) are modeled as transactions, mostly automatic.
- Implementations supply the actual network/API calls once (e.g., fetch to REST), and TanStack DB batches and manages those calls behind the scenes.
- Allows reuse of existing auth/permission flows (e.g., long polling / HTTP) without inventing new authentication for sockets.
- Key benefit: extremely fast local reads from the cache with background syncing — Tanner calls this “transformational.”
Directives and the “use workflow” conversation
- Durable workflows overview:
- Workflows allow pausing/resuming async functions for long durations (e.g., waiting, sleeping, multi-step flows) while preserving state — useful for agents, scheduled checks, etc.
- Tanner finds durable execution powerful and valuable.
- The directive debate:
- Tanner appreciates the convenience but warns about proliferation of compiler directives (magic flags) that are hard to extend and can hurt type safety and traceability.
- He likens directives to a Boolean “useState” for compilers — limited and potentially brittle if extended with ad-hoc syntaxes.
- Preference: explicit wrappers/APIs that are importable and traceable (even if less “magical”), because they’re safer, type-friendly, and easier to standardize.
- Practical nuance: Some directives like useServer/useClient have value; Tanner supports standards but calls for future-proof, type-safe designs.
Server components — Tanner’s alternative view
- Observation: Current server components are often server-rendered elements rather than true transferable components.
- Tanner’s goal: enable sending server-side logic/tasks to the client in a way that preserves inversion of control — server does what only it can do, then returns something that the client can continue working with (slots, composability).
- Status: Prototype stage in TanStack Start. He’s teasing a different implementation that may reduce the need for “use client” in many cases.
Team & roadmap notes
- TanStack is now a wider team effort — contributors include Manuel Schiller, Sam Willis, Kyle Matthews, and others.
- They’re prototyping another significant library (early alpha). Tanner declined to specify what it is, but stressed it’s intended to be foundational and community-backed. He explicitly ruled out building a CMS or ORM.
- Community engagement: Tanner is reading lots of social discussion and wants the community to stay positive and aligned with TanStack values.
Notable quotes
- “This speed... is transformational.” — on how fast local cache + background sync changes UX and developer experience.
- “A directive is kind of like the useState Boolean of compilers.” — cautioning about limited extensibility and type-safety of directives.
Key takeaways for developers
- If you need ultra-fast local queries with background sync and incremental adoption, TanStack DB is worth watching/trying when available.
- Prefer schema-based client stores for type safety and powerful query semantics (joins, where clauses).
- When adopting new compiler directives, weigh convenience versus long-term maintainability, type safety, and standardization. Explicit wrappers/APIs may be more future-proof.
- Durable workflows are powerful for long-running/resumable logic; they solve real problems (agents, delayed checks), but consider how the feature is surfaced (directive vs API).
- Server components are still evolving; new approaches that support inversion of control between server and client may become important.
Recommended next steps / resources
- Read Tanner’s blog post on directives (linked in episode notes) for a fuller explanation of his critique and suggestions.
- Follow TanStack repos and Discord for alpha previews of TanStack DB, Start, Router, and the unnamed new project.
- Try to architect client sync layers so they can accept data from multiple transports (REST, sockets, caches) to maximize incremental adoption.
Final note
This episode is a concise look into TanStack’s evolution: moving from single-author libraries to a team-driven ecosystem, focusing on client performance, developer ergonomics, and careful thought about emerging platform features (directives, workflows, server components).