--- title: Who Owns the Tree? RSC as a Protocol, Not an Architecture description: TanStack Start's creator argues that React Server Components should be understood as a protocol for serializing rendered output, not a single fixed... canonical: https://daily.dev/posts/who-owns-the-tree-rsc-as-a-protocol-not-an-architecture-ymh0laq6d twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Who Owns the Tree? RSC as a Protocol, Not an Architecture | daily.dev og:description: TanStack Start's creator argues that React Server Components should be understood as a protocol for serializing rendered output, not a single fixed... og:url: https://daily.dev/posts/who-owns-the-tree-rsc-as-a-protocol-not-an-architecture-ymh0laq6d og:image: https://api.daily.dev/og/posts/yMh0Laq6D.png og:image:alt: Who Owns the Tree? RSC as a Protocol, Not an Architecture og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Who Owns the Tree? RSC as a Protocol, Not an Architecture **[TanStack](https://daily.dev/sources/tanstack-blog)** · 9 min read · 0 upvotes · 0 comments ## Summary TanStack Start's creator argues that React Server Components should be understood as a protocol for serializing rendered output, not a single fixed architecture. The dominant 'server owns the tree' model (server composes, 'use client' marks interactive holes) is just one way to use that protocol; TanStack Start also supports a 'client owns the tree' model via Composite Components, letting a client-composed app pull in server-rendered fragments through server functions rather than inverting the whole route to the server. The piece also explains why Start deliberately avoids a Next.js-style 'use cache' directive, opting instead for transparent Flight-stream bytes that can be cached at any layer (render, server, network, client) since Start targets many deployment platforms rather than one owned persistence layer. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What are Composite Components in TanStack Start and how do they differ from the standard RSC 'use client' model? Composite Components let a client-owned tree pull in server-rendered fragments, inverting the usual RSC direction. A server function returns a rendered React fragment as Flight data, the client passes it to a CompositeComponent element and supplies slots via children or render props, so the server-rendered fragment positions those slots while the client still owns the surrounding tree. This avoids inverting an entire client-shaped route to the server just to render one server-shaped region, which is what the standard 'use client' boundary approach requires. _Weighing RSC composition strategies for a new app? daily.dev surfaces framework deep dives like this one._ ### Why doesn't TanStack Start implement a caching directive like Next.js's 'use cache'? TanStack Start avoids a caching directive because that shape requires the framework or platform to own the persistence contract (keys, storage, invalidation, cross-instance sharing), which only makes sense when a framework is married to one platform. Since Start targets Cloudflare Workers, Netlify, Vercel, Node, Bun, Railway, and any Nitro target, there is no single portable persistence layer, so it instead returns Flight stream bytes that can be cached at the render, server, network, or client layer using tools like React.cache, Redis, HTTP headers, or TanStack Query. _Comparing caching approaches across meta-frameworks? daily.dev collects these architecture debates in one place._ ## Similar posts on daily.dev - [TanStack Start gets RSC](https://daily.dev/posts/tanstack-start-gets-rsc-mijrowtfp) · Bytes by ui.dev · 60 upvotes · 5 comments - [React Server Components in TanStack – Frontend Masters Blog](https://daily.dev/posts/react-server-components-in-tanstack-frontend-masters-blog-daelxa2oz) · Frontend Masters · 0 upvotes · 0 comments - [TanStack Start RSC vs. Next.js RSC: Performance, DX, and production readiness](https://daily.dev/posts/tanstack-start-rsc-vs-next-js-rsc-performance-dx-and-production-readiness-57ke4idgh) · LogRocket · 0 upvotes · 0 comments - [Issue \#470: TanStack Start rethinks React Server Components — React Status](https://daily.dev/posts/issue-470-tanstack-start-rethinks-react-server-components-react-status-dzezbky2i) · React Status · 0 upvotes · 0 comments --- Tags: [#react](https://daily.dev/tags/react), [#nextjs](https://daily.dev/tags/nextjs) [View this post on daily.dev](https://daily.dev/posts/who-owns-the-tree-rsc-as-a-protocol-not-an-architecture-ymh0laq6d) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Who Owns the Tree? RSC as a Protocol, Not an Architecture","url":"https://daily.dev/posts/who-owns-the-tree-rsc-as-a-protocol-not-an-architecture-ymh0laq6d","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/who-owns-the-tree-rsc-as-a-protocol-not-an-architecture-ymh0laq6d"},"datePublished":"2026-08-23T12:23:58.665Z","dateModified":"2026-08-23T12:58:20.706Z","description":"TanStack Start's creator argues that React Server Components should be understood as a protocol for serializing rendered output, not a single fixed...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/baa3acf5dcfbe34aacc28206b290512a?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/baa3acf5dcfbe34aacc28206b290512a?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"TanStack","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"TanStack","logo":"https://media.daily.dev/image/upload/s--TVIrvIT7--/f_auto,q_auto/v1787487634/logos/tanstack-blog?_a=BAMAMicg0","url":"https://daily.dev/sources/tanstack-blog"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/who-owns-the-tree-rsc-as-a-protocol-not-an-architecture-ymh0laq6d","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"react,nextjs","timeRequired":"PT9M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"TanStack","item":"https://daily.dev/sources/tanstack-blog"},{"@type":"ListItem","position":3,"name":"Who Owns the Tree? RSC as a Protocol, Not an Architecture"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/who-owns-the-tree-rsc-as-a-protocol-not-an-architecture-ymh0laq6d#faq","mainEntity":[{"@type":"Question","name":"What are Composite Components in TanStack Start and how do they differ from the standard RSC 'use client' model?","acceptedAnswer":{"@type":"Answer","text":"Composite Components let a client-owned tree pull in server-rendered fragments, inverting the usual RSC direction. A server function returns a rendered React fragment as Flight data, the client passes it to a CompositeComponent element and supplies slots via children or render props, so the server-rendered fragment positions those slots while the client still owns the surrounding tree. This avoids inverting an entire client-shaped route to the server just to render one server-shaped region, which is what the standard 'use client' boundary approach requires. Weighing RSC composition strategies for a new app? daily.dev surfaces framework deep dives like this one."}},{"@type":"Question","name":"Why doesn't TanStack Start implement a caching directive like Next.js's 'use cache'?","acceptedAnswer":{"@type":"Answer","text":"TanStack Start avoids a caching directive because that shape requires the framework or platform to own the persistence contract (keys, storage, invalidation, cross-instance sharing), which only makes sense when a framework is married to one platform. Since Start targets Cloudflare Workers, Netlify, Vercel, Node, Bun, Railway, and any Nitro target, there is no single portable persistence layer, so it instead returns Flight stream bytes that can be cached at the render, server, network, or client layer using tools like React.cache, Redis, HTTP headers, or TanStack Query. Comparing caching approaches across meta-frameworks? daily.dev collects these architecture debates in one place."}}]} ```