Next Gen Fullstack React with TanStack

Welcome to Syntax. Today, we have Tanner Lindsley on. He is the dev behind 10stack Everything.

You probably know 10stack Query, 10stack Router, 10stack Table. We're here to talk to him today about what's going on. Specifically, I really wanna know, like, what's going on with the router and Tanstack Scott. I wanna know his thoughts on server components and and where that's at. So the Tanstack stuff has just been ripping through the React ecosystem the last couple years, and it seems like it just getting, like, what, ChatGPT uses TanStack Query. Is that right?

Yeah. I just found that out. When everybody's making a big deal about switching over to Remix, I was like, well, I wonder if they use query. And and it turns out that they've been using it for a while, and they kept ESLint the transition. So I'm like, hey. That's that's pretty cool.

You and Tailwind are the only ones that didn't get the ax on that move. Yeah. Hey. That's good. A better indication than the switch, right, that they, have a good day about yeah.

Wes, so good it didn't get ripped out. Yeah.

Can you give us just a quick rundown of, who you are and and what you do with all your your packages for anyone who hasn't listened to the past episodes?

Yeah. So I I started TANstack officially, I don't know, maybe, like, 8 years ago. But, really, it's been an outlet for all my open source work that I've been doing over the last 10 years. So I've I've had a startup called Nozzle over the last 10 years, and most of these packages were built to solve problems there, whether they were like, we looked in the ecosystem and there's nothing there, or we looked in the ecosystem and used things for a while and then outgrew them and thought we could do it better. So that's basically where all the packages in TanStack came from. And, as of 6 months ago well, almost 6 months ago, I went full time on TanStack.

So

Wow. Yeah. Wow. That's all because you were working at Nozzle, or that was your your company. Right? Mhmm. And that was some pretty heavy like, data heavy,

UIs. Right? Yeah. Tons of data heavy everything. Admin and management screens were were basically very app like just for, like, 1 screen. So lots of tables, lots of charty. We had data visualization for our admin screens, if that gives you any idea.

Like, hey. This is pretty intense stuff. Yeah. It was crazy.

Wes, that's awesome. So I didn't realize that you were were full time on it. I thought maybe you you were because I've I've seen everything new come out, but, that's great to hear that you are full time on this. Let's talk about, like, React in general. Like, the whole ecosystem in the last, I don't know, maybe 6 months, a year has been kinda thrashy, I Wes. It's just like like, obviously, next move to to server components, and some people are stoked about that. Some people are not stoked about that. And, people are moving over to Remix, and then Remix is moving to React Router. You know? Yeah. And then there's there's the 10 stack stuff, which is you're working on a, like, a a whole framework called 10 stack start. Is that true? That is true. So what is it?

In technical terms, 10 stack start is, like, 95% tanstack router and then this little layer around it for server side stuff. So it's powered by Vinci, which is built by Nikhil Sarraf, which is powered by Nitro.

So if you if you go all the way down, it's kind of Nitro and Vite at the bottom. Okay. But up where we're we're exposing it, so you get an SSR entry point for your app that's very convenient and very automatic. You really don't need to do anything with it at all. And then you get server functions, like RPCs, API routes, that kind of stuff around it, so the ability to do server only things. And other than that and, like, the bundling and deployment stuff that you get with Nitro, everything else is just isomorphic TANSTACK router unless you're doing something server side only.

And what is Nitro?

I don't even know that much about Nitro, to be honest, because it's proxied by Vinci. But Nitro is, the utility that powers Nuxt, and it was built by the NGS team.

And, basically, they handle all of the server side stuff for you. So they have a package called h three, which does, request response normalization between all of the different deployment targets.

They have bundling things for, you know, targeting Vite and special plug ins to help you do things like like server functions and extraction, API routes, bunch of cool tools.

But the one thing that was lacking was, that environments API that Vite has been working on, which VINCI kind of stepped in much earlier and said, hey. We're going to simulate this environment's setup using Nitro.

And VINCI will probably still stick around even though the environments API is coming out, but that that's kind of how it all came together.

So to to explain how easy it is with Nitro, like, if I wanted to change where I was deploying my apps, I could just go into my config and change 1 string from, like,

Cloudflare to Vercel, and then everything just builds and deploys differently. You don't have to import and change anything. It's pretty cool. The the SvelteKit adapter pattern that, JS one of my favorite things about using platforms like that is you don't you don't always know what your application's gonna be when you you start working on it. Yeah. I I wonder, like, this, you know, the Un. Js and the Nitro stuff and then VINCI. VINCI. Yeah. Even though it's VINCI I think it's x, v I n x I.

Yeah. All this stuff is so criminally underlooked in the React ecosystem.

Why do you think that is? Because I know it's big in in Vue land with Nuxt.

The React ecosystem JS just dominated right now by Next. And then anything that's left over, like the shavings from the Next Feast, go to Remix or maybe Redwood or something like that. I don't know. Like, ever since create React app was deprecated, it just feels like everyone just stopped caring about, like, how do I abstract? How do I do all that stuff? They just want somebody to do it for them, and Next. Js just, like, expanded into that role very quickly.

And this Vite environment's API, does this mean I've I've not heard of this before. Does this mean that we have Vite for the server then, like Vercel side?

Kind of. The environment's API is, it has a lot of things, but one of the more impressive things is that it can actually simulate the right cloud environment that you're gonna deploy to in development.

So, like, it will run with WorkerD from CloudFlare in dev mode if it thinks you're going to dev. So it it was just kinda that missing piece of like, oh, yeah. You can bundle with Vite, but it was very unaware of, like, where you were putting things.

Oh. But now it's becoming a little more aware of your, like, deployment targets.

Oh, interesting. And it will it'll literally run on Node, BUN, Deno, WorkerD,

all the 11 o I don't even know. I have a whole talk on these different runtimes, and I don't know which ones specifically, but I know that many of those are are Yeah. Included or on their road map. So Okay. So when you were when you were planning on doing something like this, was Vite always going to be the plan, or or did you have any other options in mind?

Yeah. As far as as long as I've been doing it, Vite was always the plan because I've been using Vite for for years. Like, I got off Create React app a long, long, long time ago, and I was like, Vite's where it's at. As soon as the Vite React plug in came out, I was like, k. I'm moving over. And since we were doing just client side SPA stuff, it was a really easy lift. It was just like, ditch all this webpack stuff and use all the Vite stuff. There warp some things with, like, CSS modules and things like that that we had to little bit of growing pains. But once it was done, it was done. So I've been using Vee for a long time, and and that's always kind of been the intention, JS moving to Vee.

Okay. So we have to ask. The 10 sec start stuff is gonna be doing server side. Is that React server components, or is it your own server implementation?

Yes.

What is it? What are your thoughts on server components?

So my thoughts are very cool for specific use cases. If you have a component bundle that can get out of control really quickly with, like, all the permutations and, like, all the different variations of the client bundle that you can ship. If that starts getting out of control and you start shipping way too much client to the users and they're using, like, a tiny, tiny portion, that's a great, you know, use case for it. And Wes we're talking about, like, you know, meta Facebook timeline stuff, like, some of the reasons why they why they built it in the 1st place.

Or, like, you know, what a lot of people would love to do JS, I think, ditch all of that bundle that you have to ship to the client for things like markdown and and parsing and ASTs and doing and just do that on the server, ship down the HTML. Mhmm. Yeah. But I do think that there's been way too much overprescription and and, like, over Node mapping and overselling RSCs JS, like, the total future.

I think part of that is Next. Js's interpretation of React Vercel Components in the app router, and I think some of that is also React itself because I, for 1, don't think that I would move things to be, like, React Vercel component first model.

I have plans for them. So but we should definitely get into how I how we're going to support them and how, I interpret them. So Let's do that. Alright. Okay. Let's just do it. Yeah. Let's do it. I said before that, most of Scott is 10 stack router.

And I think the thing that makes 10 stack router stand out among kind of other routing solutions is that Next. Js is just server first. Like, that's just what it is. They're approaching things server first, and the client side SPA stuff routing is just kind of all controlled by the framework. But it's very it it I think it would be very weird to use Next. Js if all you were doing is doing, like, a client side application.

I tried that, and it was hard. It was it was, like, hard. Painful. Yeah. I think you would end up basically just bailing out into something like React Router or 10 Stack Router if you're gonna do that. So I I feel I feel like that's out, for client side apps. And then there's React router, which has been really great over the Yarn. Just kind of a stone in the arch of React. But me, personally, I just wanted something better for a really long time. So that's why I built my router. And it does a lot of similar things, but it also does some really cool things that it doesn't do. But one of the things is that, I built Tansac router to be client side only first.

I wanted it to be isomorphic. And you could, even before we started working on start, you could do SSR with 10 stack router. You just render your app on the server and ship the HTML down, just like what we've been doing for a long time. And 10 stack start doesn't really change that notion. It it just adds in the ability to do server only things. So when we talk about the ability to do streaming, stream hydration, when we talk about, being able to do, like, deferred promise streaming from the server down to the ESLint. Like, that's all just 10 Stack Router. Wes don't need Scott to do that. Start's really just kind of that. How do we do things only on the server and how do we deploy, essentially? That makes 10 Stack Scott and router very client side first.

And and not just like Wes can do it, like React Router and Remix. They're like, oh, we have clients client loaders, right, like an SPA mode. No. 10 Stack stuff JS, like, client side out of the gate, and then you instead of being server side first and, like, opting into the client with, like, use ESLint, like, that's kind of where Nextiva is like, oh, we have it's all server first, then you opt ESLint to the client where you need it. This is more like, no. We Yarn running we are running an SPA. We're running client side routing. We're doing full hydration, and that's gonna be what it is out of the box. And then if you wanna opt in to these server side things, including server components, you opt into them from a client side first approach.

So I think that sets it apart pretty well from the other routers, and Remix kinda sits in the middle a little bit. And I think that paints that that's kinda like the the base for explaining how we're gonna interpret server components.

Do you have any questions so far?

I think, like, that will probably solve a lot of the pain that people are having, because I I feel like a lot of the hate against server components is simply because you try them out, and then it's just nothing but the red errors of what you can and cannot do. And people are are frustrated because all of a sudden you move to next, and everything is server by default. And then you I I can't put this and this, but you're allowed to put this and this. And Right. It's hard, especially when people have large apps that are many, many thousands of lines of code. The the reality is that most successful apps

in the React ecosystem today have already have already existed for a long time.

Mhmm. There's a lot of new greenfield apps being built every day as well, and some of them will graduate to, you know, large production scale applications that live on for a long time. But the bulk of enterprise applications and applications that are surviving well are coming from existing code bases.

So telling everybody they need to just totally turn their application upside down is a really hard pill to swallow.

And they just said, you know what? There's PagesRouter, and then there's AppRouter, and it's just like a total migration.

And and there's gimmicky things where they're like, oh, you know what? You can just do use client at the top, and you're back to page. It you but you're not back to page's router. It's not the same. So there it's really like all roads lead to migrations, and I think that's where Right. Everybody's a little uneasy about the React ecosystem right Node. It just seems like every corner you go, everywhere you go, it's like, oh, you gotta migrate to get here, or you know you're gonna have to migrate soon. Anyway, that's scary. So I wanted to build something that felt like I could take most most, if not all, of my existing, you know, client side only apps or even server side stuff too and move it into this new framework and really not have to change much.

I'm still going to do waterfall client side data fetching and, you know, preload some things here and there. And it's gonna be great because it'll be client side only. But then you can also opt into server side stuff and say, okay. I'm gonna build this very progressively enhanced, you know, HTML driven experience.

And the whole goal was to be able to give something that's very familiar, very tried and true JS far as patterns go, with the most powerful router that I can design, with the best data fetching primitives, like React Query, that I think are out there, and then contain the blast radius of server components to these little boxes. Right? And just say, k. If you wanna opt in, here is your blast radius, and the rest of your app will still function normally. But once you go in there, just know that there'd be dragons. Right? Yeah.

Why why focus on client side if if if everyone's doing server side? You gotta do server side now. Yeah. Didn't you hear Laravel's is it now? Yeah. Yeah. I heard.

HD. It's hot. So Yeah.

It's okay. I I just I I love building applications this way, to be honest.

Yeah. Yeah. So much fun. And there's a reason that I've really enjoyed the last 10 years of developing with React because it's been so highly interactive, and it's easy to build very interactive UIs when you're on the client.

You know? I'm not I'm not targeting 0 JS, experiences.

Like, I wanna do fancy applications that do fun things. So Mhmm. That's kind of the niche I'm trying to carve out for TenStack Router. I love that. Yeah.

If you don't have any questions, I'd love to tell you how they actually are going to work.

Yes. Please keep going. This is this is why we want you on.

People don't wanna hear us.

Use server, the directive. Yeah.

Very cool.

I hate it. I just absolutely despise it because it's just so it it's it's like a a wooden club. It's just so blunt.

Mhmm. Yeah. And and it's inflexible. So you call user Vercel, and it's like so much magic is happening. I mean, there's going to be magic, but there is a lot of magic and, like, opinion behind this directive that you put in your functions.

You have no idea how that thing is getting extracted and called behind the scenes. Yeah. It turns into an RPC. But, I mean, eventually, if you unwrap things hard and like, long enough and deep enough, you'll have some enterprise client that's like, how do I modify headers? What what is it sending a post? Is it sending a get, a put, you know, a patch? Can I do deletes? How can I do all these things? So I just knew that use server as a cool primitive, very cool. We don't use it. I don't recommend using it. Yeah. I support it. If you wanna do that, go ahead. Use a club. But I would rather supply people with better tools. So we have something called create server function.

And it it's a high order function that you you call, and it it's very much like use query in a way where you pass it a function that you wanna wrap up in the server.

But then you can also pass it some other things as well. So if you don't pass anything else, you just give it a function. It's gonna do the same thing as use server. It's gonna extract that function out. It's single argument, So it doesn't do you know, we can't pass as many arguments as you want.

The reason being that we wanna reserve slots for options for, like, meta options to send through. So it's single argument. It's fully type safe.

And it also gives us a position to get in the middle with, like, middleware and also middleware that might adjust types.

A a good one that I'm gonna throw out maybe a little earlier in this discussion is if you return so here here's the thing. I'm just gonna give it away. Yeah. Yeah. You call a server function. So so then it gives you back this function. Right? And if you're on the server and you call it, it's just like an identity thing. It just calls it. But we normalize things like middleware and all this other stuff. And we actually create fake request responses on the server so that we know that you're getting the same experience between client and server. And then what we do is if you return JSON, you get JSON. You return a request and response, you get a request and response.

You can return readable streams too. You can return a lot of cool things in the server functions. But what's cool is if you want to have a React server component, all you do is return React elements or JSX.

Oh. Yeah. That makes so much sense. Yeah. Right. And and, you know, hats off to, like, the the Remix team. Like, when, when Ryan was demoing at React conf, and he's like, you just move it to the loader. And I'm like, this is great. This is a wonderful way to prove out what we were what we believed was gonna be the way to do it. But the difference is that we don't just have 1 loader location where you can do this. You can create as many server functions as you want, and they're just functions. Because at the heart of it, I believe that server components are no different than any other async data source.

They just happen to be a readable stream instead of a promise because you could do some cool suspense y things. Oh. K? So there's in your mind, there's no difference

between, like, an API endpoint that returns a bunch of data and a a URL that returns a Correct. Server rendered component?

What what is the difference? The difference is that the data is something that is a little more granular that you have to put together on your own, and the RSC payload is just something that's been put together for you already.

Some of the work has been partially applied, and then you're just kinda finishing it out on the client.

I I it's still data, though. Now this is where I like to to tell people to say, you know what? React server components ESLint Next. Js, what happens when something changes from a mutation? What do you have to do? Everybody knows this. You have to revalidate. You have to revalidate.

Well Yeah. Where's another place that talks about revalidation?

Yeah. Oh, your 10 stack query.

Oh, boys. He's in it. He's he's got the whole thing.

So so listen listen to this. It's asynchronous data, which means it's asynchronous state. You're put you're capturing in one moment on the server. You're capturing some state.

You're partially applying it to some components, to some elements, and then you're shipping that partially applied JSX down to the down client to finish out the job. Right? It is no different than managing any other asynchronous state. You're still going to have to worry about every single one of those bullet points that's on the front page of React Query.

Stale data.

It when when could it be invalidated? How should we cache it? How are we gonna do, stale while revalidate? And I'm even guys, I'm even getting into stuff like, how can I how can I cache it locally? That's what I want. Yes. Yes. That's what I want. Yes. Local storage or IndexedDB or something like that. And we Sanity run it. Like, I I have done experimental versions of router and query where we can understand readable streams.

And, I mean, because at the end of the day, if if you get the readable stream itself instead of the element, it's just a stream of payload text. You know? You can do whatever you want with that. So that that's a big tangent, but just I feel like when I realized all of that, it unlocked a lot for me on how to approach server components. All of a sudden, I realized that I already have some of the best tools at my disposal to manage asynchronous state.

Why reinvent all of this? Let's just make our stuff understand readable streams and be done.

Wow. That's

incredibly refreshing. Like, I I feel like my mind is blown here. I have one more. Everybody's always talking like, oh, you have to reinvalidate reinvalidate everything with Next. Js. Right? That's because the root is an RSC. And that's why I just think the rooted r RSC approach is not the right one. You what you what you wanna have is leaf nodes and composable RSCs that you can you can say, you know what? We've matched all of our routes. We maybe we're doing nested routes, so we have, like, 3 or 4 nested routes that we've matched. Each one of those could go off and trigger an RSC in the you know, at the same time, in parallel, all 4 of them, and then come back.

And then if inside of those RSCs, you're using something like Outlet, then you can just compose those RSCs inside of each other. And what's cool is if you manage them with something that can do granular invalidation, like React Query, then you can set stale times. And you can say, hey. You know what? This RFC is just always gonna be out of date. So let's always do stale while we validate. Just always get it from the server. Or, you know, we only wanna do this RFC every 10 minutes or something like that. You you get all those granular invalidation controls and even for mutations.

So now your mutation keys apply to your RSCs as well. So you can say, oh, you know what? This RSC consumes variables for, this post ID and this user ID or something like that. Right? Holy smokes. I know. Yeah. I'm just not I'm nodding so hard over here. Yeah. So just continue your path. Any of those variables change, your query is going to reexecute, and it's gonna call the server function and and give you some new data.

Or you do an invalidation, and you're like, hey. Instead of blowing away our entire react you know, tree of the app, let's just invalidate things that have to do with invoices.

So you invalidate invoices, and any RSCs that have to do with invoices go and revalidate and come back instead of your entire application.

So you're saying that TanStack Query will be able to invalidate based on the server headers that come from the server and the other way around Wes you could refetch a server resource if Transact Query deems that it like, whatever rules you have in Transact Query to to refetch that data. Yeah. I mean, you've been able to do you've been able to do headers for a while now.

It's nothing there's nothing new there.

Oh, okay. So ready can do so so for anyone anyone maybe a bit lost is, like, when you send a response from the server, you can set expires headers on it or or stale wire validate or any of those. We have a bunch of shows on them, and 10 sec query will be able to to track those and and refetch them as needed.

Right.

And here and there there is a catch. There's always a catch. Right? And the catch is that, you have to move the utilities for doing create from fetch away from your APIs and towards your rendering because you'll be getting readable streams back and passing readable streams around.

But then when it comes time to render the actual elements, that's when you want to apply the create from fetch. Right? Because as soon as you apply create from fetch, you've got weird element syntax, all the stuff, nothing that is portable, nothing that's cacheable.

So it for me, I'm always like, let's let's keep these readable streams JS just plain, readable stream with text as long as we possibly can until we need to turn them into something that's not portable.

Node, and this is just a random thought, but does that mean we could potentially have, like, server state that is synced to the client.

Yeah.

Yeah. Like like, if if I mean I mean, you can do that right now with with just JSON.

So Yeah. Yeah. That's true. Cool. Man, I I'm really excited about this. Here here's another fun here's another fun one. And, you know, that's React Query. People like, well, what does React Query have to do a 10 sec router and start? Well, we built this so that it integrates seamlessly.

So you you you pass Node little bridge function at the top. You take your router, and you take your query client. You marry them together, and you're done.

But even if you don't do that, even if you just use the router, 10 people forget easily that Tansac router has a built in miniaturized version of 10 step query inside of it. So it can do basically all this all most of the same things that React Query can do, but not everything. Right? It doesn't have, like, infinite queries and pagination, all this other stuff. But it does have a cache.

And, like, Remix and Next. Js, they kind of have these ideas of a cache in their routers, but they really don't. Like, Remix just holds on to whatever you have until you get the new thing, and then it's gone. It just, like, disappears.

You load a new page, you gotta go load it again from the server. So we're caching things with Tansac router just like query is. And then when when you outgrow it, you can just, you know, move over to query. But it'll it'll do all the same stuff just without query if you warp it to.

Jeez. And and, like, if somebody wanted to move to this, they've got a like, a create React app, you know, from 6 years ago. You could move over and opt in fairly easily as as you move through it. Right?

Yeah. I think so. Because we we have code based routing, which I don't suggest anybody uses, to be honest.

It's difficult to hook up the same developer experience with code based routing and, like, keep things hooked up well, which is why I say, like, file based routing is more than just a way to manage your routes with files. It's actually just a really good way to let a framework do a lot of magical things for you, like code splitting and type Yeah. Type splitting and, like, type stuff.

Yeah. I occasionally get nostalgic over the the code based routing, and then I remember these those things that you're referring to. Right? When Wes when you find yourself writing,

React Scott lazy import everywhere Right. Yeah. Yeah. And then you realize there's no built in way to prefetch those unless you have wrappers around it. And then it really takes, like, 5 minutes to be like, oh, I need a framework.

Yeah. For real. When I posted that, a video about ChatGpT moving over to Remix, like, half the comments were, like, why didn't they just use React Router? And it's people don't realize if you're building this yourself, it's it's hard. You gotta do a lot yourself, and Right.

It's not fun.

Yeah. So on top of that, I I think I think it's worth mentioning for anybody who doesn't know what 10 sec router is all about. It's a client side router, but it's been rebuilt from the ground up to be completely type safe. And I know that type safety is gonna be coming to, you know, React Router 7 and Next. Js probably soon.

The best way that I can describe it is that these these are going to be, imitations or semi semi close reproductions of of what Sanity router actually is. It's a it's a fully inferred type safe system that lets you define your routes either via files or code, and it knows everything about all of your routes. It knows every path, every path parameter, every search param.

It knows about nesting.

It will literally not let you do something stupid, and it has the best developer experience you can imagine. And that's a really hard thing to, like, advertise and sell to people. They're like, hey. This has an amazing developer experience.

But, literally, go go on Twitter and search Sanity router and just look at what everybody is saying, and everybody's like, this is amazing. I can't live without it anymore. So it it has great types, and and it has a lot of really great state management and, like, enterprise app things that you might not think you need right now. But later on, you'll be grateful you have, like, search validations for your search parameters using Node and and great APIs for updating search parameters that feel like you're using something like use state or ESLint. Like, just making it stupid simple to put state in the URL.

So this is this is coming from many, many years of building applications like like Nozzle.

And if you want to see all of the errors in your application, you'll want to check out Sanity at sentry.i0forward/syntax.

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 to reduce ESLint dot I o forward slash syntax. Again, we've been using this tool for a long time, and it totally rules. Alright.

So you have, obviously, all these different 10 stack packages. I think, you know, Node stack query supports, you know, a whole bunch of different frameworks.

Is there ever a future where 10 stack router supports multiple frameworks other than React? 100%.

That's very exciting to me. I built it most mostly in an agnostic way. So we don't use just like all the other libraries, we're not using React for state management.

We're not like, most of the package is just TypeScript, and then we have this layer of components and hooks that live on top of it.

And we try to keep as much of a logic in the core as possible.

For a while, I was working on, like, a solid version of it. I decided that I just needed to focus on 1 framework and get everything out the door, get, you know, 10 pnpm start out the door, and then we can go back and say, okay. How how can we make sure that all of this is gonna run-in an agnostic way? But we're we're using all the utilities that we've developed internally at TandStack already to do that. Like, we have we have a TandStack store package.

It's kind of a stealthy package, but we use TanStack store as our state manager for all of the different libraries we build because we have an agnostic core for state management and then a bunch of adapters that we've built that translate that state management into immutability for React or signals for Solid or, you know, observe observables for Vue. It's it's really,

really pretty cool. Jeez. Yeah. Yeah. We had Corbin Crutchley on, on the podcast a couple of months ago, and we asked him, like, how are you building these things? Like like, what's the tip for building Scott the React version of something, but how do you build something that's 90% just JavaScript and then filter it out? And he said, yeah. The state management is a major key behind that.

Corbin has been involved in that project in a very like, he is TANsec's store now in a way. Oh, wow. Like, he's been working on ways to do like, he he built derived stores because we're gonna have things like like Tansac Table is gonna start using derived stores to power individual cells inside of the data grid. Man, that rules. It uses kind of a poll Bos, signally type implementation, but in an agnostic way so that we can translate it into all the different frameworks. It's really interesting. It's not like the most performant state manager, but Yeah. It's it's good enough and and pretty dang fast.

But it it has all those attributes where we can we can just push it out to all the other frameworks. So it's all about flexibility.

And what's the plan for, like, form actions or submitting forms to you submit to the server, it does a bunch of stuff, and then send some data back. Is Tansac Scott gonna have that?

Yeah. We will support all the new React 19 things. When they when it launches, we are going to investigate all those and support them really well. I don't really wanna build my framework around that because not every other framework has those things. And, honestly, other than, like, you know, some some of the things around deep transition support, with React, you can do a lot of those things already. You just don't have, like, that transition support in a way. I don't necessarily agree with all of the API decisions that they've made around things like, you know, use action state and and server actions in general, especially when they're interpreted in a way like like Next. Js can only do serial actions and and Remix. You Node, there's something that came out recently about how Remix is doing parallel actions and versus Next. Js's serial actions. Like, I don't wanna ship APIs that are that are just underpowered. Like, I I would never be okay with, like, a a serially executed server action pattern. No way.

But but as far as I know, like, tools like Canstack Query and just having, like, a holistic invalidation strategy for your caching can solve a lot of that. So, yes, I believe in all these new React APIs if people wanna use them, but I also don't think that we should be, you know, up a creek right now because we don't have them yet. So I'm not I'm not relying on them to ship a framework or ship a great experience.

We'll just kinda have to see how that evolves.

I'm also curious if we for anyone who hasn't seen the website, there's Tansac Store, Ranger, which is a headless UI library, virtual, which is like a virtual eye virtual scrolling. If you've got a ton of DOM elements, you can't just scroll those smoothly. So you have Wes headless too, which is kind of a mind bending. Yeah. Yes. That's it's like virtual. That's what we asked Corbin when he came on. We're like, how is it virtual scrolling, which is like, it literally depends on what it looks like, and and how it renders on the page, but it's also headless, which means it doesn't render anything.

You render it. I don't know. Do you wanna talk about that? Yeah. I mean, it's it's basically it's that partial application concept where we're handling literally everything except for the rendering. So we just give you all the building blocks, and then you get to render it how you want, which if if you look at a lot of virtualization libraries, that's one of the major complaints about a lot of them that just serve up components for you JS that you have to have ways to override the component that you're rendering, and then you get into memoization problems.

We I just really wanted to get away from a lot of that, and I wanted a way to be able to throw the idea of a virtualizer onto any DOM element that I wanted.

So you can take 1 virtualizer and use it kind of how you would expect with a parent div that contains, the view and then a sub div that contains the total height of the content that is then translating up and down through you know, revealing only what's visible inside of that parent window.

But you could take that same concept, so the same state, the same methods, the same core API, and you could use that to do a table instead, like an actual table element, which you can't do the same thing with a table because you can't nest a div inside of a table element. Mhmm. So what do you do? You take a table element, and you create fake headers and fake footer rows.

And then you you split up the distance between the viewport on the top and the bottom and the upper and lower bounds of the all the content, and you take that padding area that you can't see, and you apply that height to the fake row in the table that makes it appear as if you have this huge scrollable area, but, really, it's just a 50,000 pixel tall t h or a, you know, a 20 and and that that width is changing as you're going as you're moving that window up and down. And then the items that are visible in the viewport, we're just kind of swapping in and out as they enter or exit.

It's absurdly clever. How do you come up with this stuff? Yeah. Even I I didn't come up with that one. I saw that one from a different table library.

So okay. That's wild. Yeah. Yeah. And then what's cool too is is, a virtualizer does not have any notion if it I mean, it has a small notion if it's vertical or horizontal. So you can actually create 2 virtualizers and stack them on top of each other, 1 on different axes, and now you have a grid.

Using the same primitive, one of them is set horizontally, one of them is set vertically. So

Wild. But do you pnpm do you spend your day, like, thinking? Like, do you have a thinking chair you sit down with on a pipe?

Node, I mean, I'm sitting there right now. It's just my I have my office, but no. I mean, I'm I'm a I'm a space case. Like, I spend a lot of time with my family and kids and my wife.

Usually, I'm I'm engaged, but I zone off quite a bit. I'm like, oh, it'd be cool, you know, if we did that. Oh, yeah. Like that. So, my wife calls me the absent minded professor a lot. Yeah.

My wife calls me mister Magoo because I'm always running into things.

I'm kidding her.

And at what point do we get the rest of the stack and get 10 stack database or 10 stack CMS? Like, is is that your end goal here JS to like, we've been asking for a Rails or Laravel in in JavaScript land, and nothing's really stuck.

Are we are you gonna save us?

No. Probably not.

I mean, here's here's what's cool. I I think that given the right primitives, people will build those on their own. And when those ideas start to win out, then, hopefully, they would want more of a solid platform to push some of those, ideas and integrations.

I think, you know, they're they're just at a certain point, you get into you know, the permutations explode into a lot of different directions you can go. Right? As far as which framework you should choose, there's like, you know, maybe 4 or 5 React frameworks. You know, what hosting provider should you use? There's a lot more of those.

What database should you use from what service or from what you know, the permutations explode really quickly.

And at some point, you kinda have to say, we're gonna leave some of that to the users. And if they have good primitives, then they should be able to use whatever they want. So I believe it's more about having great primitives, and not just great primitives, but good abstractions to let people apply those primitives in JS many places as possible.

Yeah. Well, I mean, the reason what v vinix v what was it called? Vinci. Vixie? Vinci.

Oh, yeah. Vinci, v, all of these, micros.

You Node? Those are good primitives. Right? And then you're able to come and build on top of that, some of these amazing things. A great example is,

Convex. Convex is one of my is one of Tansact's partners. They're one of the reasons I can go full time. But Convex, they have built this real time, you know, database, that's relational, and then they have this React Query adapter on top of it that just works.

It's really mind boggling. Like, all you do is create this query client from Convex and kind of, again, marry it to the normal query client, and you don't do anything different. You just pass your queries to use query, and Convex takes care of the rest of it. So it's real time socket based queries. It's it's pretty mind mind blowing. So that's, I think, is a great example. Like, oh, could could we get into real time, and could we get into databases? Yeah. Of course. We could Mhmm. We could spend as so much time there. But with that really great primitive, Convex was like, yeah. It was not that difficult to build this, and it's so cool. And because it it works so well with the system, like, we already have as an example where you can use tanstack start with router, with Convex, with query. So you can have this SSR'd application deploying to wherever you want that has live queries in it. Yeah. It's pretty cool.

Man, that's great. Oh, one thing I really love and admire about your work is the docs.

The documentation for all of your your projects are incredible. What are you using for that? Is that all bespoke? Yeah. I mean, I heard this yesterday. I'm gonna be honest. I I was on a I was on a different podcast, 2 days ago, and they're like, we just love your docs. I don't really understand that. I I think it's gotta be, it's probably a hidden talent that I have. I enjoy writing quite a bit. I'm not gonna say I enjoy writing documentation, but I try and make it enjoyable for myself so that I can get through it. And maybe some of that enjoyment rubs off onto the onto the readers. You know? Yeah. But I I wouldn't say that I'm, like, studying and really going out of my way to be like, these docs have to be amazing. Most of the time, I'm just like, you know what? I really wanna launch this thing, and I can't launch without docs. So it's just a boulder that I have to get over, and then I can launch it. So I do it, and I launch it, and then it's just a work in progress after that.

Nice. I appreciate that there's so many code examples, and it's not just, like, paragraphs of text. I think there's a fine line between people writing too much text, not showing enough of the, like, the general API reference, but also code examples. I mean, it's a balance, and and that's what I like about it. Yeah. Well and and I explained it this way the other day JS that I like to write documentation that can be approached by a bunch of different personality TypeScript

the person who comes in and does a quick start, and then they're just out, like, they they'll learn the rest using TypeScript, and maybe they'll drop ESLint command k to a topic every once in a while.

So you just have to have good searchable docs. And then there's the person that's, like, wants they love to read, so they're like, give me the guide. Give me the story. Right? And that's why every every TANFAC library has, like, a guide section where it's like, we're gonna take you from 0 to hero, hopefully, from primitives to abstractions, right, which is the same way that UI dot dev does their education in their courses as well.

So the we have that approach. And then there's just, like, the API reference person where they're like, I don't wanna know. Don't teach me how to use this. I just need the just give me the encyclopedia.

Yeah. And I and I'll Yes. And I'll figure it out. Right? And I don't understand those people, but I'm good for them. You know? So I wanna make sure that there's it can be attacked from, like, several different angles. And I think there's also something to be said about trying to be a little too fun with your docs. Sometimes it's fun to come in the docs. Oh, it's super quirky and, you know, there's banter.

But when you're in the middle of, like, a bug or you're at work and something like, you're on call for something and you gotta fix something, and you come into the docs and it's like, oh, man. Remember that one time when your grandma did this, and and then your and then your dad used the website, and then it sucked.

And it's like, Kate, cut the garbage. I don't even know how to use this thing. So I think there's a I think there's a good balance between, hey. You can have fun reading these docs because the voice of the company and the culture or the person can come through it Vercel I'm taking you for a ride and trying to be, like, trying to be a little bit too much of a of a jokester.

Yeah. I get that. Yeah. For sure. Didn't you say I think I you said to me once that you use the AI to write a docs for one of your projects.

Was that true? I I tried.

For the early docs of Tansac router, I tried using and this was a while ago. So it was, like, GPT 33.

35, probably. Yeah. 35, something like that. It was it was old, like, sucked, And it was Oh, yeah. It was really difficult. Like, I I didn't get very far with it. It it was mostly for, like, writing, like, code examples because it it could not write with my vocal style at all in the docs, and I just said, this reads funny. You know? It was saying things that it thought I would say JS, like I was like, you know, I'm Tanner Lindsley. And it's like, oh, okay. I'm gonna write these docs how I think you write, and it's, like, so dumb. So it was hallucinating my personality big time.

AI thinks my personality says dog a lot. Like, what's up dog? I'm like, I don't know if I say that, but yeah. Thank you.

Yeah. My my personality has it's like it definitely it's like, okay. He's a goober. He's definitely a Mormon. He's definitely from Utah, and he's just, like, overly, like, overtly friendly and and trying to you know? I'm like, k. I don't I'm not that friendly. Right? I'm not trying to suck up. Like, that's what it sounded like. I'm like, this AI is a brownnoser.

I look forward to the day that the AI will be able to assume your personality based on things you said. Like, I've we have I don't know. I have, like, many thousands of hours of myself speaking into this microphone. Yeah. I just would love the day that I can just feed all of that into my own model and have a little Wes.

But, yeah, it always goes overboard. You know? Too many emojis.

You know? Who needs who needs children? You can have your little have that little Wes. Yes. Exactly.

You just want a little less. Yeah. Oh my god. Oh, man.

I can tell you something that I've been excited about lately Yeah. Is, this create server function primitive that I'm building.

We're rewriting it to allow you to incrementally adopt into API routes.

So if you start with a function, that's all you need, and it'll get extracted.

But if you wanna change the method, you just pass method, colon, post, or put, or whatever. And when you call that server function on the client, it will do it as a get. So then you get caching, like browser level caching.

Ah. And then the step after that is like, oh, you know what? What if I wanna validate this? We're building validation into the API so you can pass a zod schema or a yep schema, and you'll get client side and service side validation through that function. Man. And here's the cool part, I think, is now it's like, oh, you know what? I really wish I could use this same function in my React Native app or or somewhere externally.

All you do is pass a path with your with the API route that you wanna expose it in.

That solves so many problems for me. Yeah. You have your path, your method, your validation. You have everything, but but you do it through a server function.

It it's a sliding scale. You know? You can be totally in line, and I don't care about the external world, or you can be all the way over to the other side and say, externalize this and make it completely safe.

That that's kind of the that's the route that we're going.

And on that same idea, you said earlier that a middleware like, a middleware can modify data. And with TypeScript, that's sometimes a bit funky because you don't Weigh ahead of your ESLint. Yeah. Tell me about middleware and modifying types.

So middleware's fun with, like, types because middleware is usually very magical.

It's just grabbing something, setting some magical property, and then just ditching out, right, or doing some logging or whatever or transforming.

And there's some middleware that that doesn't need to, like, transfer type information through to the rest of the system, and that can just keep working as is. But there is middleware that you would wanna write to just not repeat yourself or to, like, enforce things all the time for something. So the 2 good use cases I I always bring up is authentication is one of them. Yeah. JS the user set? Yeah. You you never want to just let your junior developers have to remember to put so the way I say it, type safety doesn't just involve types, but it also involves forgetability.

Right? And adding middleware, to authenticate a request is forgettable for a lot of people, even myself. Right? You get it caught up in the moment. You're just like, man, whatever.

You just assume that this user object is there, and then everything breaks.

So the way that we've designed middleware is that, we can use kind of the same system that we're using for 10 Stack Router that can carry types throughout an entire system.

You can create a single auth middleware at the top and say assign this middleware to all these functions under this path, or you can compose them and, like, import them and compose them together with, like, a middleware array list.

Nice. Yeah. And once you do that, all of a sudden, you have this context object that comes through in every single middleware like, every single middleware underneath it and every server function that consumes it will now have this context dot whatever you return, user, user ID, email, whatever. And it's type safe. It's there. So if you try and reference it without the middleware, you'll get an error. Add the middleware ESLint. You're good to go. That's one of those that's, like, very magical. Like, you just wanna set it in one place, and you don't want you just have to remember to import it and and remember to put it in there. But then there's the other approach where it's like, okay.

You might create middleware for doing common tasks and operations.

So within endpoints that manage things for it for teams, you might want to include a workspace in teams middleware that you just don't have to think about. Right? But the workspace can just always provide you with a workspace context.

The team can always provide you a team context, and they can handle permissions and all that stuff. You need to be able to compose those things in at the site of the server function. So you kinda have to have both. You have to have the primitive of composition, but you also have to have the abstraction of automatic wizardry so that, you know, each type of developer, be it super junior early dev, can do his little functional composition, and staff engineer can make sure he's enforcing things across the board. But that's the idea for middlewares that we're gonna do all of it. And middleware, commonly, you'll see it split up into, you have a next function passed to you. You await it. You get the result, and then you do something with it. So very common to see kind of the next function, approach. But to do to do inferred type safety well, you need to be able to have a return type that you can infer.

You can't infer what some next function is called with. So what we do is we split that phase up, and we say we have a before, and we have an after. Before is everything that you would do before you call next, and what you return will be the arguments into next. And then after, you'll have everything that you would do after next, including the result and anything that you returned. That way, we can infer the types for all of the middlewares going down the chain and compose them together and make sure that they are all compatible.

Yeah. That's how we do it in in SvelteKit with hooks in the same sort of way. And that, like, that's it for me. That's the promised land. That's how I I like it. That's how I want it to be. Yeah. It's very I think it's it's very similar in spirit. I have a very large Express app, and it's it's very heavy on the middleware.

And every time something new comes out, I look at what their middleware implementation looks like so much that I haven't found anything I like. I've started moving a lot of my middleware over to a sync local storage, so it Scott just goes up into the ether, and then you can access it. But I haven't figured out the type safety thing yet. Yeah. So I'm really happy to hear that. Well, VINCI

and h three and all the utilities we're using, like, they require, async local storage. And what's cool is you you don't have to use the magical functions like, set headers and whatnot. If you wanna use the raw primitives of of request and response, you can. But you also have access to all of those great abstractions from something like h three. So it's kind of like you have all the great primitive approach of something like like Remix, but then you have some of the abstraction utilities that Next. Js is all about. Right? So it kind of sits in the middle. But then the things that you need type safety for, we just say, you know what? If you wanna do type safe things, this is the way to do it. Make those 1st class citizens JS part of the API.

Beautiful. I'm excited for that. Me too. So what JS the what is the timeline look for getting Sanity Scott to to at least a beta?

It's in alpha right now. Right? In alpha right Node, and and tan so tanstack Scott has been running. So we migrated from Remix to Tansac start 8 months ago.

Nice. So we've been using it for quite a while. And tanstack.com serves a lot of traffic, so I'm very I'm pretty confident in TANSTACK Start's ability already. So beyond that, I wanna move to beta, hopefully, in October.

Okay. I wanna get this middleware, server function API really, really nice. In fact, I wanna get it good enough to where we can deprecate API routes as a thing. Like, you'll just use the server function API to do both server functions and API routes. Just 1 unified API to do it all. And when we can figure that out, I'll launch beta.

After that, I'm gonna feel very good about just saying, okay. Everybody everybody go use this and try it out.

And as long as we don't encounter any big bugs or, like, architectural problems or architectural feedback, then I I think my plan is to try and get an RC or maybe even a release out before Thanksgiving. I want people to be able to play with this before the holidays or just over the holidays.

People tend to just kind of take projects and things, and then they go on vacation. They just kinda tinker. So Yeah. I I wanna get it out by then.

Sick.

Awesome. Well, I'm very much looking forward to it. I've been, my own personal website and my course platform, I've been thinking, what do I move it to? You know? And I haven't been, like, stoked about anything yet. I mow I moved my own personal website over to to Next. Js and server components almost entirely, but there's, I don't know, some pain pain in my butts in a couple of places. So Yeah. Well curious to see when this comes out. I'm gonna try it like crazy.

I've I've been in all those places too.

Wes used to serve 10stack Scott and Next. We we used Remix.

I mean, I I feel like we've got a lot of experience under our belt with things that we've tried ourselves.

This is definitely not a framework that's been born out of curiosity. It's yeah. We're we're building it how we want it because of the of the things that we've experienced. So

Beautiful.

Scott, you wanna wrap up with the last sections? Yeah. So this is the part of the show where we talk about sick picks and the shameless plugs. Tanner, you've been on before. Did you come with a sick pick for us today?

I have I have some sick picks. I'll just tell you the things I'm in I'm into lately. So Sick. I recently was shopping for a new television for my for my basement, and I did a lot of research into, like, something that's affordable, but also just really, really good quality.

And and it's hard because up in my main floor, I have a I have a frame, a Samsung frame.

And, in the end, it looks so good, like, as a as an item, and it just makes our you Node, it's art. It's so cool. Yeah. And I I almost got sucked into that again in my basement, and I almost bought an 85 inch frame. And then I I I stepped back, and I was like, dude, this is not this is not what you want. This is not what you need. This is for watching films. This is for, like, you know, being immersed.

And I ended up with an LG Z4. It's a 77 inch C4, and I could not be happier. That thing is amazing. So sick pick. Like, I think that it's probably one of the best bang for your buck OLED TVs. Like, yeah, it's it's an OLED TV, so you're up in that range of price.

But it's not insane for, like, the size that it is. So that's that's one of my sick picks.

Awesome. That's a good one. Sorry. That was the LG c four.

C four. My phones went low battery for a second. Yeah. The c four. I I've been looking at at TVs as well. Not that, I'm going to buy 1, but Right. Just because I'm interested in it. And, like, yeah, that OLED I'm I'm probably gonna go OLED for the next one no matter what, and the C4 caught my eye for sure. So

I also found these, like, super slim wall mounts. They're they're called they're from a company called Sup Klein or Sup Klein, and they look just like the mounts that come with the Frame TV, like Samsung Frame, that you can use it on anything. And they have these big metal hooks that hook onto a a latch, and then they they it folds down in magnets against the wall. So I'm really excited to I just got that in from Amazon today, and I'm I'm kind of itching to go install it. So That looks cool. Wow. Oh, yeah. Yeah. That's exactly like the frame. I had a I hung our frame TV in our living room, and I it was Yeah. It looks exactly like the frame stuff. I'm like, did they sub did they design and supply those to Samsung? Because they look exactly the same. So

Cool.

Cool.

Alright. And, Seamus plugs, what would you like to plug to our audience? I wanna plug my maintainers, to be honest. Like, so they're so so cool.

TanStack JS sure. It has it's got some name play from my name. Right? But, like, my maintainers are some of the smartest, coolest people in the world. We've already talked about Corbin. TKDodo goes without mentioning. Right? Kevin Vandy is doing things with with TansacTable that would blow a lot of people's minds. It's gonna be really impressive, the next version. Like, the smallest kilobyte version of Tansac table JS gonna be, like, 4 kilobytes, which is insane Wes you think that AG Grid, who we love them. I'm a partner with AG Grid, but, like, their base size is is just massive. But also some newcomers.

So Sean Casieri, and Manuel Schiller and Chris Roben are, like, really pushing things on 10 stack router and start. These guys are TypeScript wizards. They understand users and developers. Like, they're so cool.

So we need to give them some love. I'm trying to I'm trying to get them like, give them their their moment in the spotlight because they deserve it big time.

Awesome. Well, send us send us links to all their websites, their socials, whatever, and we'll put them in the show notes because often, those are the best follows of of people that are Yeah. Sharing nuggets.

Chris Harobin just launched a blog post on 10 Stack blog, which we don't have a lot of blog Bos, but it JS, like, the coolest deep dive on TypeScript performance you've you've you'll ever read. It is so cool Ian shows a little bit why, like, 10 stack routers type safety is gonna be difficult to match.

Man, you guys are doing big things. And, Tanner, I think my my head was nodding this entire episode. So, man, I'm just so stoked about all the stuff you guys are working on. So Yeah. Wes. Yeah. Thanks so much for coming on. Yeah. Absolutely. I'm yeah. I'm stoked about this. You're,

you're great at explaining the benefits as well. I think, like, that's a a skill on its own. It's like, you're obviously smart at thinking about how to approach these problems, but also being able to explain them to just regular folk like Scott and I and get us excited about it is a is a huge skill. Skill. Regular folk? Come on. Yeah. Damn.

But, no, that that's that's me and Scott's whole thing is that, like, we hope to represent the normies. You know? Like, we wanna talk to the the really smart people, but, like, most developers are are regular folk, and, we wanna be able to translate it to them.

For sure. Yeah. I just want everybody to be productive. You know? Yeah. Everybody deserves to be,

an MVP at their job or whatever they're doing. So Alright. Well, thank you so much, Tanner. Appreciate all your time, and, we hope to have you on, again soon.

Count on it.