Fullstack TanStack! The Scoop with Tanner Linsley 🔗 **Source:** [Fullstack TanStack! The Scoop with Tanner Linsley](https://www.youtube.com/watch?v=QE-Xp85l59Y) > [!note]+ Document Notes > tags: [tanstack, fullstack, react] > author: Syntax > source: YouTube > reference: https://www.youtube.com/watch?v=QE-Xp85l59Y > date created: 2024-12-19 14:30 > > # 🏷️ Title: Fullstack TanStack! The Scoop with Tanner Linsley > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Try TanStack DB for incremental adoption of local-first sync — Live at GitHub Universe #tanstack - [H2] Evaluate directive alternatives for better type safety — Blog post discussion #react - [H3] Watch for TanStack's secret foundational project announcement — Working group in Discord #community ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [TanStack](https://tanstack.com) - [Syntax Podcast](https://syntax.fm) ## 📝 Summary - Live interview with Tanner Linsley at GitHub Universe covering TanStack ecosystem updates - Why it matters: TanStack is expanding beyond Query into sync engines, routers, and full-stack solutions - Key stakeholders: React developers, full-stack teams, local-first advocates - Risks and tradeoffs: Directive proliferation vs type safety, incremental adoption challenges - Bottom line takeaway: TanStack DB enables local-first development without full platform commitment, plus mystery foundational project in development ## 📖 Main Content TanStack has evolved from just Query into a comprehensive ecosystem with multiple maintainers. The interview covers three main areas: TanStack DB (a local-first sync engine), thoughts on React directive patterns, and hints about future projects. TanStack DB represents a client-side sync engine that allows incremental adoption of local-first patterns. Unlike solutions requiring full PostgreSQL commitment, it works with existing APIs through collections (table-like structures) powered by differential data flow. Developers can push data from any source (React Query, WebSockets, IndexedDB) and query using familiar SQL-like syntax with joins and where clauses. Tanner expresses concerns about directive proliferation in React, specifically around Next.js 15's "use workflow" directive. While acknowledging the utility of workflow/durable execution concepts, he argues directives lack type safety and extensibility compared to function wrappers, comparing them to "the useState boolean of compilers." The conversation reveals TanStack is prototyping server components that send actual components (not just elements) to clients, enabling inversion of control and reducing need for "use client" directives. Additionally, a mystery foundational project involves a large working group of community members addressing commonly requested functionality. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=0) — [H1] TanStack ecosystem expansion - Key idea: TanStack now has libraries Tanner didn't create, indicating team growth - Evidence: "This is the first year that libraries are out that I didn't create" #### ⏱️ [02:30](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=150) — [H1] TanStack DB as sync engine - Key idea: Client-only sync engine with incremental adoption approach - Evidence: "It is like a sync engine, but it's only the client part of it" #### ⏱️ [03:15](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=195) — [H2] Collections and query engine - Key idea: Table-like structures with SQL-style querying powered by differential data flow - Evidence: "You can do joins, you can do wear clauses, you can do really fun tricky things" #### ⏱️ [04:00](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=240) — [H2] Agnostic data sources - Key idea: Collections can receive data from any source for flexibility - Evidence: "You could shove data into those from React query, from a websocket, from index DB" #### ⏱️ [05:30](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=330) — [H3] Schema requirement for type safety - Key idea: Unlike Query's async function approach, DB needs schemas for joins and type safety - Evidence: "It is schema based because you need to be able to have strict type safety" #### ⏱️ [07:45](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=465) — [H2] Transaction framework - Key idea: Automatic transaction management with customizable implementation details - Evidence: "Insert, update, and delete, you just supply the implementation details for those" #### ⏱️ [10:30](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=630) — [H1] Next.js workflow directive critique - Key idea: Workflow/durable execution is exciting but directive approach has problems - Evidence: "The workflow stuff itself is actually really exciting... we've got to be honest with ourselves" #### ⏱️ [13:00](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=780) — [H2] Directive proliferation problem - Key idea: Directives are like boolean flags that lack extensibility and type safety - Evidence: "A directive is kind of just like this boolean. You only have the one choice" #### ⏱️ [15:15](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=915) — [H3] Preference for wrapper functions - Key idea: Function wrappers provide better type safety and traceability than directives - Evidence: "Why don't we just use rappers? Maybe they're not pretty... but at least they're type safe" #### ⏱️ [17:00](https://www.google.com/watch?v=QE-Xp85l59Y?t=1020) — [H1] Server components innovation - Key idea: TanStack working on sending actual components, not just rendered elements - Evidence: "What they really are or what we've seen is server elements" #### ⏱️ [18:30](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=1110) — [H2] Inversion of control goal - Key idea: Server should handle server-only tasks, client maintains control for client tasks - Evidence: "I want to be able to send it a task to do this thing on the server... but then come back to me" #### ⏱️ [20:00](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=1200) — [H2] Community momentum and pressure - Key idea: 95% of TanStack discussion comes from community, creating marketing but also pressure - Evidence: "95% of the stuff that I've been reading on Twitter is just coming from random people" #### ⏱️ [22:15](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=1335) — [H1] Mystery foundational project - Key idea: Large-scope project with working group, something community has requested - Evidence: "We've got a huge working group channel in our Discord with a bunch of people" #### ⏱️ [23:30](https://www.youtube.com/watch?v=QE-Xp85l59Y?t=1410) — [H3] No CMS or ORM plans - Key idea: TanStack explicitly avoiding content management and object-relational mapping - Evidence: "I do not want to make a CMS or or or an OM" ## 📚 References - [TanStack Query](https://tanstack.com/query) - [TanStack Router](https://tanstack.com/router) - [Cloudflare Durable Objects](https://developers.cloudflare.com/durable-objects/) - [Electric SQL](https://electric-sql.com/) ## 🗣️ Paraphrase - TanStack has grown from a single-maintainer project into a team-driven ecosystem with specialized focus areas like routing, sync engines, and full-stack solutions - The new TanStack DB offers a middle ground for local-first development by providing client-side sync capabilities that work with existing backend infrastructure rather than requiring wholesale platform migration - There's growing concern about React's directive pattern proliferation, with arguments favoring explicit function wrappers that maintain type safety and developer experience over magic compiler transformations ## 📰 Newsletter Exciting updates from the TanStack ecosystem! At GitHub Universe, Tanner Linsley revealed TanStack DB - a game-changing client-side sync engine that brings local-first capabilities to your existing WordPress or custom API setup. Unlike solutions requiring complete backend overhauls, TanStack DB lets you incrementally adopt lightning-fast local caching with real-time sync. The key insight? You get SQL-like querying with joins and complex operations running at browser speed, while your data can come from anywhere - REST APIs, WebSockets, or even WordPress's REST API. Perfect for headless WordPress sites needing blazing performance without architectural rewrites. Plus, keep an eye out for TanStack's mysterious new foundational project currently in development with a large community working group. Whatever it is, the community has been asking for it! Resources: [TanStack](https://tanstack.com), [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create demos showing TanStack DB with WordPress REST API integration - Education: Workshop on local-first patterns for WordPress developers - Developer experience: Document migration paths from traditional state management - Developer marketing: Case studies on performance improvements with local-first sync - Community management: Monitor TanStack working group for WordPress-relevant developments #### WordPress - Core: Evaluate local-first patterns for Gutenberg block editor performance - Core Performance: Profile benefits of client-side sync engines for admin interfaces - Core AI: Consider local-first approaches for AI feature responsiveness - Community: Meetup content on modern state management patterns - Documentation: Guides for headless WordPress with sync engine integration - Meta: API reliability considerations for sync engine data sources ## 🧪 Hypotheses - Local-first sync engines can dramatically improve WordPress admin performance by caching frequently accessed data client-side - Incremental adoption of sync patterns is more practical for existing WordPress sites than full platform migrations - Directive-based APIs create more maintenance burden than explicit function wrappers in large codebases - Server components that maintain client control will have higher adoption than current server element patterns ### 📊 Methodology - Benchmark WordPress admin operations with and without client-side sync caching - A/B test directive vs wrapper API patterns for developer experience and type safety - Measure adoption rates of incremental vs wholesale local-first implementations ### ❓ Questions - How will TanStack DB handle WordPress-specific data patterns like post meta and taxonomies? - What performance gains are realistic for typical WordPress admin workflows? - How does the mystery TanStack project relate to existing ecosystem tools? ### 🔮 Future Research - Integration patterns between TanStack DB and WordPress REST API optimization - Comparative analysis of local-first solutions for content management systems - Developer experience metrics for directive vs function-based APIs ### 💡 Implications - Practice: Local-first patterns may become standard for high-performance WordPress applications - Policy: API design decisions should consider sync engine compatibility - Security: Client-side caching introduces new considerations for sensitive data handling - Education: Developer training needs to cover local-first architectural patterns - Funding: Performance-critical WordPress projects may need budget for sync engine integration ### 🧠 Learning Styles Assessment Reading level estimate: Grade 12 #### 👀 Visual learners - Present: Architecture discussion of sync engines and data flow - Improve: Diagrams showing TanStack DB data flow, before/after performance charts #### 🔊 Aural learners - Present: Podcast format with natural conversation flow - Improve: Chapter markers for different topics, audio summary #### 🗣️ Verbal learners - Present: Technical concepts explained through analogies and examples - Improve: Glossary of terms like "differential data flow" and "durable execution" #### 🧩 Kinesthetic learners - Present: Discussion of hands-on implementation details - Improve: Step-by-step TanStack DB setup guide, interactive examples #### 🧠 Logical learners - Present: Clear problem-solution structure, technical reasoning - Improve: Decision tree for choosing sync engine approaches, performance benchmarks #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion, working group mentions - Improve: Discord community links, pair programming suggestions #### 🧘‍♀️ Solitary learners - Present: Individual exploration of concepts encouraged - Improve: Self-paced learning paths, reflection questions on architecture decisions #### 🌿 Naturalistic learners - Present: Ecosystem thinking about library relationships - Improve: Analogies to natural systems, sustainability of architectural choices ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, interview format is naturally accessible - Improve: Transcript timestamps, speaker identification #### Keyboard navigation - Present: Standard video controls available - Improve: Jump-to-section shortcuts, transcript navigation #### Contrast and readability - Present: Video content with good visual contrast - Improve: High-contrast transcript options #### Text resizing and reflow - Present: Responsive video player and transcript - Improve: Transcript formatting for different screen sizes #### Media and captions - Present: Full transcript provided - Improve: Professional captions, downloadable transcript #### Forms and interactions - Present: Basic video interaction controls - Improve: Interactive transcript with clickable timestamps ### 🌍 DEIB Assessment #### Cultural breadth - Present: Technical discussion accessible to global developer community - Improve: Examples from diverse technical ecosystems #### Inclusive language - Present: Professional technical language, gender-neutral terms - Improve: Define technical jargon for broader accessibility #### Neurodiversity support - Present: Clear conversation structure with topic transitions - Improve: Visual topic markers, structured bullet points in transcript #### Representation - Present: Tech leaders sharing knowledge openly - Improve: Highlight diverse contributors to TanStack ecosystem #### Psychological safety - Present: Respectful technical discussion, constructive criticism - Improve: Community guidelines reference for further discussion ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear technical requirements lead to architectural decisions - Inductive strength: Performance claims based on general principles of local caching - Causal reasoning: Directive proliferation causes maintainability issues - Analogical strength: Comparing directives to "useState boolean" effectively illustrates limitations #### Fallacies - Appeal to novelty: Some preference for "new" approaches without full justification - False dilemma: Directive vs wrapper presented as binary choice without hybrid options #### Tone of voice - Overall tone: Enthusiastic but technical, balancing optimism with practical concerns ### 🛡️ DARVO Analysis - Deny: No concerning denials present - Attack: No personal attacks on other tools or developers - Reverse victim/offender: Not applicable to technical discussion - Emotional cues and rhetoric: Positive technical enthusiasm, constructive criticism ## 🎯 Conclusion TanStack is evolving into a comprehensive full-stack ecosystem with TanStack DB leading the charge toward incremental local-first adoption. The emphasis on maintaining existing API compatibility while adding sync capabilities represents a pragmatic approach to modern application architecture. Developers should evaluate local-first patterns for performance-critical applications while remaining aware of the ongoing debates around React directive patterns versus explicit APIs. ## 🧱 Refactor Appen <!-- deep-read:sections end --> ## 📺 Video  --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=QE-Xp85l59Y)* **[00:00]** Welcome to Syntax. Today we are live at GitHub Universe and we have Tanner Lindsley in the box. >> Yes. Look who we have here. >> Water in the floor. >> Hello. Hello. >> Taking all the merch drinking all the drinks. >> I don't have that low. You know that low range you've got on yours? I do. >> I don't have that either. >> I'm jealous. >> What's up? >> Now I got the Hey. Hey guys. You like your JavaScript? >> Yeah. >> Hey, I got some [laughter] cool JavaScript tips for you. >> Wow. That's great, guys. >> Oh Uh so Tanner uh is the creator of **[00:34]** Tanstack everything. Um you've probably used Tanstack query >> almost everything. >> Tanstack almost everything. >> This is the first year that libraries are out that I didn't create >> that you haven't even touched before. Yeah. That's uh >> it's more of a Tanstack team now, right? >> Yeah. You guys got like lots of lots of folks. We had Corbin on the podcast what maybe a year a year and a half ago and he was telling us about how you write libraries to work with multiple things. >> Yeah. It's so funny. Yeah. When I talked to Corbin at the thing I was like I **[01:05]** think it was about like four years ago we had you on the I looked it up. It was 2024. I'm like oh okay four years ago. Yeah. >> Time flies. Yeah. Right. since we've last talked. I know that you're cooking on stuff right now and we'll have you on for a proper podcast, but we thought we would just grab you into to chitchat, but like you've been you've been cooking, right? Like you've uh what have you been working on? >> Yeah, we've been cooking some fun stuff. I have been heads down on Tanac start and router lately. Me and Manuel Schiller have mostly been working on that. Sam Willis and Kyle Matthews from **[01:37]** Electric have been putting a ton of work into Tanstack DB. Oh, that's so that's your like sync engine local first. Scott absolutely loves this stuff. >> Oh, yeah. We were talking about it last night. >> Yeah. Like like if I wasn't doing router and start like that, I would be working on that cuz I'm just so excited about it. >> Tell us about about like what that is. >> So it it is like a sync engine, but it's only it's only the client part of it. So you you set up what we call collections. **[02:09]** Yeah. And they're basically tables and you can you can then query those collections using like a queries syntax that you're used to from like drizzle or like it's it's a first class query engine. You know, you can do joins, you can do wear clauses, you can do really fun tricky things and that's all powered by this differential data flow system behind the scenes in the browser. So it's really really fast to run these queries on these collections. Okay, >> but those collections can be powered agnostically. So you could shove data **[02:40]** into those from React query, from a websocket, from index DB. So you can you can push data into these collections from anywhere. >> Okay. >> So it's like you get to start building your own sync engine. >> Yeah. >> Which is what makes it incrementally adoptable. Yeah. Which is very important. >> That's what we were talking about with zero. >> Yeah. >> Which is what I'm using for everything. you are have to have either your Postgress set up already uh and and be committed to that or you have to build from scratch. Yeah. So that incremental **[03:12]** adoption piece is much more difficult and with the syntax site it wouldn't be possible because we're not on Postgress unless yeah we move to Postgress. One of the benefits if we we peel it back. One of the benefits to to tan stack query is that like you just needed an an async function. Yeah. >> You know, and you didn't it's not like it had to be a fetch call. Not like it had to be this like weird signature or whatever. It just needs to be a synchronous function and past that you don't give a h how what happens. Is that the same thing with the sync engine? >> Same spiritual idea. You do need a **[03:44]** little bit more. So yes, you need async functions to, you know, you need to be able to push your data into the collection. >> Yeah. >> And that can happen through a REST call setup. You've got like you can use React Query to push data in there. >> Okay. >> Or you can set up a socket or a live stream of events coming in. So that's the first thing you need is to be able to push data in. The second thing you need is it it is schema based >> because you need to be able to have strict type safety. But not just that, you need to be able to query this stuff like a table and do joins on ids and **[04:16]** joins on things. So, oh yeah, >> it takes a schema. So, it's it's not relational, but you can treat it like that. So, let's see. Data schema. >> That's really it. That's all you need. >> Yeah. And I think one thing that people really don't realize is just how transformative the speed can be when you're working in these local cache systems. It is so fast. And I I feel like I'm always constantly talking about this. Yeah. And **[04:46]** like a year from now, people are gonna be like, "This is the fastest. You've been so early to this stuff and not everyone realizes how good it is." >> So shockingly fast. That's why I'm excited for the tanstack DB. I'm excited for this incremental adoption. I would love to use it on syntax. Uh and like just know that like that that speed in which you're able to load things from your local data cache with with syncing happening behind the scenes or whatever that process is is transformational. **[05:17]** >> What does the actual syncing look like? You know, like I I understand like querying you're pulling data down, but like what happens when you need to like have a mutation or whatever? >> So [clears throat] the transaction there's there's a transaction framework built into it. Okay. And a lot of that is automatic. So when you work with individual collections, you know, you're doing an insert or a deletion or or an update, a lot of those transactions are managed for you around kind of these common actions you can take. >> And all you have to do is supply the implementation details of those common **[05:48]** actions and you can also create your own, but like insert, update, and delete, you you just supply the implementation details for those. So you may have a collection that's powered by a really old crappy REST API. Yeah. And when you call those three functions, you got to go in and actually make a fetch call with the data and do the thing, right? But once you set that up one time, you can then go back to your your business logic, your application layer, and you can interact with that collection as if it's synchronous. You can just mutate properties. You can **[06:18]** delete and add things. And behind the scenes, it's batching and doing all those fetch calls for you. >> And that gives you easy control over permissions and stuff like that because you're not changing your API, right? Yeah. Yeah. That that's a problem that I know Zero has been trying to solve in different ways of permissions of which if you're not having to adopt a whole new thing, right? Yeah. You're just using your API and and I got a rep electric, which is where Kyle and and Sam are from. >> Yeah. Kyle's been on that for a while now. Yeah. >> But by using uh long polling, right? You **[06:51]** get to you get to reutilize all your normal authentication flows because it's just REST. It's just it's just HTTP, right? >> Yeah. So you don't have to invent something new for sockets and go through kind of that charade. >> I'm excited to try that out. Let's switch gears a little bit. Nex.js last week launched Nex.js 16 launched a workflow with the use workflow directive which is a little bit magic, right? Um I haven't really caught up with what everybody's saying about it, but I know I know you've had some thoughts on it. **[07:21]** Can you give us the scoop as to what you think about that? The workflow stuff itself is actually really exciting. Yeah. Like we we've got to be honest with ourselves that like durable execution is really exciting. Yeah. >> Uh no matter what you're using. >> So like maybe pause just for a second like the idea with the for the audience listening the idea with a a workflow is that you can like you can have an async function and you can just like pause that function for 42 days. Yeah. Or you can have like multiple steps or you can say like come back and sleep for 30 **[07:51]** minutes and and come back and check if this thing and it's really cool like I'm I've used the Cloudflare durable objects and their workflow. Big fan of that and like all of your memory, all of your variables, all of that sort of just like is reinstated. There's like injest. There's a couple of like other startups in that space. So it's it's great especially for for agents where you're like come back in in half an hour but you don't have to like save your variables to database or anything like that. sort of just like >> seals it up. But >> it's a hot space and it's useful. It's really cool to do that. >> Yeah. And if you want to see all of the **[08:23]** errors in your application, you'll want to check out Sentry at centry.io/sintax. You don't want a production application out there that well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to centry.io/sax. Again, we've been using this tool for a long time and it totally [music] rules. All right. I think the interesting part that kind of was trending a lot on Twitter and social media these the last few days has been around their usage of directives **[08:54]** for kind of setting that up. And on on one hand you look at it and it's like it does look really innovative and cool to be like oh look what you had to do with these other APIs and nesting things in functions and setting them up to to be resilient. Uh we've replaced all that with just these kind of magic directives. So, on one hand, it does look really great and and man, it sells well. Even when I saw it, I was like, "Oh, wow. That looks really cool." Yeah. >> But for me personally, I I I think that we kind of have a directive problem. Just **[09:25]** >> we're getting a little obsessive about using them for everything. And so, I I decided to collect some of my thoughts on directives in general. Uh not just about use workflow, but just about all the directives that we've kind of chosen to adopt over the last couple years and put them into a little blog post that I did. Okay. Yeah. >> And like give us the the cliffnotes of that like what should we be using instead of these magic directives. >> So from my perspective people are saying that magic directives are the way to indicate that some kind of transformation is happening under the **[09:56]** hood by a compiler. >> Okay. >> And I I would say that we've actually been doing that for a long time without directives >> with just functions and and other things and transform. Yeah. JSF. Um, and for me, I'd say, you know what, let let's use Yeah, sure. Let's invent ways to do compiler tricks because it's all tricks. None of it's real JavaScript. So, if we're going to invent tricks, my opinion is that they should at least be uh futurep proof for type safety. Yeah. >> And especially room to grow because I I **[10:28]** actually messaged this to David Kersheed today and I said, "Hey, I actually thought of you because directives are kind of like the use state boolean." >> Oh. >> of of compilers, right? >> And I know that he would be like, "Oh my gosh, use state." >> Yeah, that's that's David Kpiano. You say anything about state machines, he arrives. >> But in the same spirit, a directive is kind of just like this boolean. You only have the one choice. It's either there or it's not. And and if if anybody wants to try and expand that into, okay, well, now we have this special colon syntax **[11:00]** and now there now there's directives, but there's also magic functions that change how those directives are. >> Directive arguments, right? Yeah, I'm like, okay, we're starting to invent JavaScript again. And in that case, I would just say, well, why don't we just use rappers? Maybe they're not pretty. And and maybe they maybe they don't scream, hey, a compiler is doing something here. But at least they're type safe. They're traceable. They have an import. You can follow them back to a spec hopefully, you know, even JSX >> looks pretty magical, you know, but but **[11:32]** you can you can go and say, oh, what's the pragma being used here? you can trace that pragma back to oh here's the actual transforms that are happening under the hood. So you know there's been a lot of talk about creating standards and wanting to share work across the ecosystem and and I love that and there's there's some leeway and personally like for things like use server and use client you know I like the spirit of that like trying to share uh and make it as useful as possible for everybody. Yeah, >> at the same time I'm building a meta framework and I'm not using server. I **[12:05]** mean we support it. >> We support it but I don't want to use it cuz I want type safety and I want all this nice stuff. So you know I'm kind of on the on the team of like you know if you want to try and create standards that's great. Let's make them open and and make them easy to customize and safe. But I just feel like going down this directive route is going to create a lot of >> standard proliferation. >> Yeah. And I don't like that. >> Yeah. Yeah. Yeah. That that tracks for sure. >> Cool. Well, we'll link up the blog post below and people can check it out. But **[12:36]** love hearing that. What other what other spicy takes you got? >> Um, you know, we're we're working on React server component support for for TANS stack start >> and we're going to support the normal flavors of server components how everybody wants to use them. But we have kind of a a special take on server components that I think is going to be a little bit unique. I'm not going to share too much because we're still in the prototype stage. We we know that it it works, but we just don't have it ready to show off. But the teaser is **[13:06]** that uh we've been talking about server components for a long time now. >> Yeah. >> But in reality, what they really are or what we've seen is server elements. When you think about like returning a server component from next or or wherever these days, you're not returning a component to the client or or you know to render. You're returning an element that's been rendered. >> Yeah. >> And I've I've always had this dream of being able to actually send a component back to the client and and render it **[13:37]** with slots and inversion of control. That inversion of control is so important to me because I don't like to assume that the server knows how to do everything. >> Yeah. >> I want to be able to send it a task to do this thing on the server that only it can do on the server, but then come back to me and let me continue to do things on the client that I want to do. >> Okay. Fill in the little >> Yeah. Fill in fill in the gaps. Yeah. just from what I said there, you can probably put the pieces together what we're working on, but uh it's it's going **[14:09]** to be a a different a different implementation of server components than I think a lot of people have are used to. >> Yeah. >> And it opens up a path to using server components that doesn't require uh the use client directive >> for a majority of use cases. There's still use cases for that, >> but yeah, >> man. Yeah. and and it does feel like there's so much momentum behind you and your projects right now. Does that feel is it is it reaching you in that same **[14:40]** way that there is a lot of heat on what you're doing? Positive heat. >> Yeah. And it's exhausting because a lot of it I mean I know that we've written some blog posts and and we've put some new projects out there, you know, but a lot of it is is feels like it's being thrown at us from social media um and the community. Like I'd say 95% of the stuff that I've been reading on Twitter is just coming from random people that we've never met or anything. They're just they've just decided to use Tanstack as this podium to to speak **[15:14]** their thoughts, which is really cool. You know, in some regards, they're they're doing our marketing work for us. On the other hand, it makes me nervous. You know, I want to make sure that it's a positive spin, that people people are being nice and kind and upholding what I would call like the Tanstack tenets of of, you know, always making sure we're we're being nice and and being positive. >> That's great. I like that. What else, Tanstack? What else would you Is Tanstack CMS one day? What what what are what are the areas that you would love to touch and something that you will **[15:45]** never want to touch? We I don't I do not want to make a CMS or [laughter] or or an OM. I we do not want >> 10ack OM. Okay. >> No, we do have one more library that we are prototyping right now. It's in the very early alpha like pre-alpha stages. >> Okay. >> But I I cannot say anything about it. >> What What area is it in? Me and Scott are going to guess. >> I can't even hint to it. >> Somebody in the comments will know. Please go in the comments below, drop **[16:16]** what you think it is, and then find the ones and upvote the most ones. >> Yeah. But I I will say that we >> icons. >> We are working with a lot of people in the community. So, usually we'll just build something internally first and then we'll just like here we built something new. This project has big scope. A lot of a lot of people are behind it from outside of the Tanstack community. So, we've got a huge working group channel in our Discord with a bunch of people who have been invited to this working group. interesting. >> Yeah. >> Panstack format. Panstack [laughter] **[16:48]** V plus >> but but we think it's we think it's going to be very foundational. Um something that I think people have asked us even saying we would like you to have this, we would like you to build this. And I ask them why. And a lot of it some of it comes down to ownership. They just trust us to do the right thing. >> Uh it's got to feel good >> with with software. And some of it is technical. A lot of is technical where it's just like, hey, we're using this tool and it gets the job done, but it's kind of the only choice we have and it **[17:19]** could be better. And we think that the Tanstack, >> it's a bundler. >> Yeah, >> it's a text editor. We're just going to Yeah. >> Tanstack code. >> I'm just going to say sure to all of that so that there's a bunch >> stack agent. >> So that there's a red herring basically everything. >> It's got to be a a bundler with AI built into it. Stack sparkle. Yeah, it's a it's sparkle. Tensac sparkle is coming. [laughter] >> Cool. Well, I'm really looking forward to that. All right. Well, thank you so much for coming in. Appreciate it. And **[17:50]** we'll have you back on the show uh once you got some more to say. >> You bet. Thanks so much, Tanner. >> Yep.