TanStack and the Future of Frontend with Tanner Linsley

0:00TanStack is an open source collection of high performance libraries for JavaScript and TypeScript applications primarily focused on state management, data fetching, and table utilities. It includes popular libraries like TanStack Query, TanStack Table, and TanStack Router. These libraries emphasize declarative APIs, optimized performance, and developer-friendly features, and they are increasingly popular for modern front-end development. Tanner Lindsley is the creator of TanStack, and he joins the podcast with Nick Neesey to talk about the project, SSG, type safety, the TanStack Start Fullstack React framework, and much more.

0:40Nick Neesey is a conference organizer, speaker, and developer focused on tools across the web ecosystem. He has organized and emceed several conferences and has led Nebraska JS for more than a decade. Nick currently works as a developer experience engineer at WorkOS.

1:10Tanner Lindsley, welcome to Software Engineering Daily. How's it going? It's going great. How are you? I'm doing fantastic. Why don't you tell us a little bit about yourself? I make software, primarily open source software now. As of about almost a year ago, it marks when I went full-time on Tanstack. So it's going really well. Before that, I was running a startup with some friends called Nozzle. I spent 10 years there solving difficult front-end problems, which explains why a lot of the tools I have today exist. Yeah, that totally makes sense. Before that, I was like an Angular, Ionic junkie who was making money off of WordPress.

2:02so I actually it's funny I actually learned how to write javascript kind of through angular 1.x it was a weird experience and then afterwards I was like oh I need to learn javascript so that's kind of where I got my start into js but now yeah I wake up in the morning and I eat, sleep, and breathe TanStack open source and make sure that it's helping people. Nice. Well, anecdotally, I can say that it is because it has helped me a ton and many, many others. My first introduction to the TanStack would have been through React query, now TanStack query. Where did that lie? Was that one of your first projects?

2:46Was it the first project in the TanStack? No, the first project actually was TanStack table. Back then it was called React Table. That was one of the very first ones that I wrote that is still around today. Yeah. So I wrote React Table way back. We needed it at Nozzle. I have a video from React Summit in like 2020 something. I can't remember. But I talked about React Table. That's a good one if you want to go check that out. But from there, after that, I wrote React Static, which I don't maintain anymore. It's unmaintained, I think. But this was back when SSG was really, really hot. And at the time, it was Gatsby and Next.js were really up and coming, and they were doing really cool things.

3:36And I put my hat in the ring, and I started building React Static, which was like this framework, essentially, before server frameworks really took off and it was good. It was fast. So back then everybody was like, how fast can you build your static site? And for a while I was killing Gatsby and Next because I was doing, I think I was one of the first ones to do multi-threaded builds for SSG. So like if you had multiple cores, you you just zoom. And I got pretty good at React static stuff. And then we realized that like, I wasn't using React static at Nozzle very much. We didn't use it. It was just kind of fun.

4:21So I was like, you know, maybe I shouldn't put all my time into this. And then Gatsby raised like $30 million and Next.js raised, I don't know what their first round or two was, but like the next round they raised was like several tens of millions of dollars. And they're like, yeah, and we're going to be dumping everything we have into Gatsby and Next. And I was just like, oh my gosh, well, I don't really have the time or the money to compete with this right now. So I decided to throw in the towel. I gave React Static to a company, a group of people that, you know we're gonna keep maintaining it and then after a while I just switched my SSG to next and then after a while I just stopped doing SSG not really I mean we kept using it through next but then everything started become more hybrid and then it just became like a lot of caching a lot of CDN caching type stuff so it's all server driven now I'm starting to get back into SSG a little bit.

5:26So TanStack Start is going to have already has some like static site generation features to it that are pretty cool, in my opinion. It's kind of like bringing back React Static for me, because it was a lot of fun. Nice. Well, yeah, let's let's dive into that and talk about TanStack Start. So it is more of like a full framework on the level of, would you say, like Next and Remix and kind of like at that level? Absolutely. Yeah. So it's a full stack framework, which just means it has a server first. I mean, it has a server first technical mentality to it. So just like Next.js and Remix, it's doing full SSR and hydration.

6:11We're running that server on deployed servers somewhere, whether that's serverless or long running or whatever. And then it still becomes an SPA, just like many other full stack frameworks. So once you've hydrated and streamed the response down, it becomes an SPA. And most of it is just based on TanStack Router. I would say like 90 % of the APIs that you use or are going to use when you build a TanStack start app, you're just using TanStack Router. start is actually pretty unrelated to a lot of the public API that you touch. There's obviously a lot of dependency on TanStack router and start to do the hydration and the streaming and kind of take care of the black box stuff that nobody really ever wants to touch the implementation details of.

7:07But then in design for how you interact with it, all of the routing and all of the application stuff is very separate. So if you're doing something with server functions, that comes from start. If you're doing something with SSR, you don't have to worry about that. You just use the router. So most of the time, you're just writing an application as if you're writing a good old SPA. And the reason that works is because it's isomorphic. So by default, and this is how Remix is too, we're rendering everything on the client. We're also rendering that on the server during SSR, unless you explicitly say like, hey, don't try and render this because we're using local storage or something like that.

7:54But otherwise, everything runs during SSR and on the client by default. And that's a pretty big departure from Next.js app router, where they're pushing everything kind of like, hey, not everything runs. Well, I mean, I guess client components. What a bad name, client components, because really, they render on the server too. They're isomorphic, right? So the mentality is just in like the difference of developer experience. With a TanStack router and Start app, it's much more like Remix where you feel like you're writing an SPA and you're kind of opting in to server-specific features and server-specific things as you need them instead of kind of having those server features thrust upon you.

8:49Yeah, like a good example of that is loaders. I mean, even Remix in their loader pattern, loaders are server only. They only run on the server, right? For us, that's not the case. Loaders run everywhere. They load on the server. They load on the client before you navigate. But if you do want to run something only on the server, that's where you reach for a server function. So you can create a server function, and then we will guarantee that it only will run on the server during SSR. or if you're on the client, it will make an RPC call back to the server to make sure that it runs that logic there.

9:27Nice. And how do you define a server function? Is it in a somewhat familiar way, like use server, like a pragma like that? Yeah, we have kind of two flavors. The first base layer of support uses the use server directive that you're going to see almost everywhere. Like you'll see that in React because they're trying to make it a standard thing. You know, like it's a bundler feature, like use server. We support that. So if you want to make a function and just put use server inside of it at the top, little string literal directive, that will work. We'll extract it and put it on the server, do a little RPC.

10:10That works. You can do that. But that's not what we recommend. Mostly because it's lacking. It lacks a lot of features, a lot of things, in my opinion. So if you've ever tried to do like validation or middleware, or maybe you have a server function, but you want to wrap it with some client side functionality to, it just becomes unwieldy because it's this function that gets extracted. And the lines between client and server get really blurry sometimes. And it's like the implementation gets a little blurry too. Like, okay, so when I call this function on the client, what is exactly happening, right?

10:50It's okay, it's creating a fetch. It's doing a fetch call to my server. What kind of fetch call? Are there headers involved? Can I modify those? Is it a get or a post? You know, is it just sending raw response back and forth? Is it doing serialization? Because there's a lot of questions around like, well, can I send maps and sets and dates and things like that? And will they get, could I use super JSON with this, right? And when you talk about those features, like the use server directive kind of is unwieldy. It's not fun to use. So we created a primitive for Tanstack start called create server function.

11:32and if you've ever used trpc it probably will feel a lot like creating a trpc procedure or or mutation or query so you call create server function and already inside of there you can start customizing to say this is a this server function should use the method get or method post so you You can start customizing things about how is this going to go back to the backend. You can also start adding middleware to that. So you can chain off of their.middleware and pass an array of type safe middleware functions. And middleware can not only change and read the payload and the result that you're getting back with a server function, But there's secondary channels on top of that network IO for context.

12:29So middleware can even send context between the client execution and the server execution and back again to the client without you needing to worry about passing any of that information at the call site. So for instance, we helped Sentry create a middleware for server functions that does full observability from client to server and back to client again. And all you do is add a global middleware and every single server function now has observability in it, which is way cool. You can use it for authentication and things like that. and then there's also validation which is where trpc is a really big one like trpc we're very type safe first right and type safety as soon as you cross the network type safety is kind of fake unless you control it end to end which i mean if you're doing full stack you could pretty much guarantee like that most of the time it's going to be like if you just share the types, you're going to be okay.

13:41But we wanted some extra security around things, and so we added first-class validation support for server function payloads. So what you can do is you can say.validator, and you can pass any standard schema-compliant validator. So Zod, archetype, valibot, or you can just write your own if you want. It's just a function that takes input output with types and you can actually do runtime validation and you can also say so validation by default only runs on the server but if you wanted to you could turn it on for the client too and get early early errors from from the client that's what i was going to ask is if it was just on the server or if it could be on both and that sounds amazing a question i have on that with the the validator so like if you have something like you're using you know the zod validator and passing in your schema, I assume it's giving you some kind of like standard, like it's going to throw some kind of standard error then.

14:41And then you handle that in a pretty standard way across everything. Yeah. If you use Zod and it throws, so if it's server only, we have a serialization utility behind the scenes that's making it so that we can serialize basically anything from the server back to the client. So when it throws on the server, we'll take that error, we'll package it up, we ship it back to the client and we'll re-throw it on the client and you get to respond to that ZOD error however you want. Okay, nice. And you can respond on both sides too? Yeah, if you wanted to. So on the server side, the base validator can throw and you can kind of wrap that in a catch if you want and say, oh, we'll do some extra server side logic here if we want.

15:27The default is that if it doesn't validate correctly on the server, it'll just go back to the client. And what's cool about that is validators by default are server only. So if you use Zod in a validator or something like that, we actually rip Zod away from the client package. So even though you're defining these functions right inside of your SPA kind of isomorphic code, the packages that you use inside of the server handler or like the validator, they get ripped out of the client so that you're not shipping Zod to the client, unless you want to. You can just turn on client-side validation too, and then we'll ship it.

16:07Got it. But then on the client, it's giving you those Zod errors or how is that? Yeah. So on the client, what happens then is we will run your validator client-side before we send the fetch request out on your payload. Okay. So it'd be a different validator. Yeah. Well, no, it's the same validator for now. we we have a to-do item to make it so that you can customize and say here's a client validator if you want to do that we haven't had anybody ask for it yet but it would be a pretty simple change but yeah that's the idea it's it's very we want it to be like anything you can catch on the client do simply now you know skip the network io otherwise just send it to the server so now speaking of type safety one of the big features that i see come across and this might be more of like a 10 stack router thing and a 10 stack start thing because, and correct me if I'm wrong, but the big difference obviously is like the server side functionality of 10 stack start, but then also like there's file-based routing within that.

17:06Is that true? So the router itself has file-based routing. If you, even if you don't use start. Oh, okay. Yeah. And that's just part of 10 stack router. Yeah. Just part of 10 stack router. So the router itself had nothing to do with server side, anything, but just the router itself has a VEAT plugin and a CLI. and in fact it even has an rs pack and web pack plug-in as well so you can run these plugins and and we support file-based routing and those plugins are there to give you like the full breadth of type safety that we can offer file-based routing is actually the best way to get that otherwise you end up wiring a lot of things together if you use code-based routing yeah for sure now i want to dig into that a little bit just like what does it mean to be a type safe router because I see that touted as like a huge feature.

17:55And to be honest, I haven't dug into it enough yet to fully understand that. So could you explain that to me? I think the best illustration of what we mean by that is if you go to any example or pretty much any application that's built with TanStack Router and go look at the route definitions, go look at creating a route and using route APIs. and you tell me how much TypeScript you see in those files. And I'll answer that for you. It's probably none or maybe just a little bit. If you have decided to abstract some things on your own, you got to make your own function signatures or whatever. But for the most part, you can just write with TanStack Router and never need to cast anything or write type code at all or annotations.

18:51You never have to narrow manually. So it honestly looks like you're just using JavaScript, but it is 100 % type safe behind the scenes because everything is inferred. And what we mean by that is there's a big difference between libraries like Next.js and React Router that they're written with TypeScript and they do have types, but most of the time you need to remember to put those in there. You need, you know, there's some step involved where you need to get involved to some level to make sure that things are going to be type safe. Like providing a generic, something to a generic. Yeah. Providing a generic or even with React routers new stuff, you have to remember to import the types and then grab the right types off of that file and put them where they need to go.

19:55Or even there's like Next.js and Remix, they both use like a link building utility where you have to remember to use the utility. And the bottom line is that these other routers that aren't type safe, they will allow you to write unsafe code. And I mean, that's fine. They've been around longer than us. They need to support that. We could have done that too. I wrote a router called React Location that allowed you to write unsafe code. But I didn't want that. So not only do we make it really, really easy to just write type safe code, but we also make it somewhat difficult to write code that's not safe because it's just inherently built into the entire architecture of the router.

20:47from the minute that you define your router and your routes and start going down into, you know, components and loaders and things like that, search parameters, everything is fully inferred. And all of those generics, I mean, if you just want to see how many generics we have in TanStack router, go look at the source code for TanStack router. And you'll see some of our functions have 20 or 30 generics being passed around, which is fine. You know, we we're taking on that complexity so that you don't have to. And what you get is a system that even for junior developer or somebody who's new can come in and, and get the docs and, you know, use autocomplete and write code that essentially guides you to the happy path, discourages you from making mistakes without you needing to even remember, oh, I need to make sure that I cast this as type save, or I need to make sure I remember this generic, or I hope I'm importing the right file here, or something like that, you know?

21:56So I gave a talk at Utah JS last year that was around TanStack router. And it kind of went over all of the different ways, kind of a long form answer to what you asked. And like, what is the difference between writing something with TypeScript and writing a type safe system? And it shows you firsthand like, oh, this looks type safe, but it's actually not. And let's show you why. So I would recommend going and watching that video if you're interested on that topic some more. Yeah, for sure. And this is why the type system in TypeScript can be so complex is so that you can hide away a lot of that advanced type safety from end users and they can just benefit from it.

22:44And I won't lie, it's really grueling work. I started the adventure of type safe routing four years ago now. In the first two years, I didn't even write any runtime code. I was just messing with types and trying to figure out how could I even architect this in a way that wouldn't require crazy, crazy things. At the end of the day, I found a way. After we had exhausted every possible avenue of doing this without language service plugins or massive amounts of code generation, we had done everything we could with the native TypeScript features. Then we went in and said, okay, how can we make it a little bit better now?

23:28And that's when we added one file that does some code generation, right? And that's it. That's what the plugin does. It generates one file that's just creating some shortcuts for TypeScript. One of the most interesting things about type safety is that TypeScript has no idea what a file is like in a file system. It has no idea about what file you're in or, you know, like the hierarchy of your file system. And that's a very important thing if you're doing file-based routing. Yeah. For like sub routes and things. Yeah. Nested routing. And so we had to come up with a way to teach TypeScript about the file system that was performant and lazily evaluated and performant enough to scale to tens of thousands of routes that wouldn't crash the TypeScript language service.

24:31Christopher Herobin is really the TypeScript junkie who's behind a lot of those performance hacks. He's a very, very smart person. We got really far, but he's the one who came in and has really put on like the last buffed out polishes on the type system for tan stack router. Like I proof of concepted it and I, I made it work and I made it work, right? He's making it work fast. So nice. Nice. So you mentioned working on just like pure types for a long time without actual any runtime code. I'm curious, did you use any way of doing automated testing to ensure those types were correct? Or how do you approach that when you're not actually writing runnable code?

25:20Well, I mean, if you're just writing just pure types, you can go really, really far without needing testing because something will just not compile or break if you're doing it wrong. Yeah. So TSC is your test? Yeah. And at some point though, it gets to be big enough to where you need to guard against regression. So when we were just building fresh, it was just like, yeah, TSC is good enough to like get this to check ourselves. But then when we say, okay, we figured it out, solidified it, we needed the tests are more for like regression catching. We just use the test and we write our own.d.ts files and we use the tests TypeScript stuff to say, you know, expect this type to equal this type.

26:09And for the most part like that, not for the most part, it works great. Yeah. So we'll go through and we'll, we'll change the types or fix bugs or whatever. And it will say, Hey, you know, like you're, you're, you have a public type contract that you're breaking. We don't do that for like private internal types. We only test public types so that we can go in and mess things around and re-architect the types if we need to, as long as we have those outer contracts, we're good. Yeah. And that's exactly why I was asking about that is like, I'm kind of in the mindset of thinking about the developer experience and specifically, like you said, not regressing it.

26:49And so having like a way to ensure that, you know, this is not just going to give you some weird type or some like unknown or any type, like it's going to be what it always was. Yeah, we have extensive type testing as well. So just for router, we have over 200 test suites that run just for like all the packages in router. It's a lot, which is a stark contrast from about a year and a half ago, we had zero. So big props to my team. They're much better at writing tests than I am. so sean cassieri and manuel schiller are like and and chris christopher robin on the type side but like they're all much better developers than i am another question i have around router and tan stack start those are both in the react ecosystem right are there plans for them to kind of follow other Tanstack projects and kind of abstract themselves from React and be more multi-framework supported?

27:58So I was actually on stream about a week ago with Ryan Carniato. We officially announced Tanstack Solid Router. Oh, wow. Cool. So that's already out. Fully tested, passes all the tests. got the sign of approval from, you know, a lot of the solid team. In fact, the Burke and I think Burke and his name's Brenly. I always knew his screen name is Brennell's, but Burke and Brenly from the solid JS team, they really liked 10 stack router and start. And they only started on it like three and a half weeks ago. They're like, Hey, let's write an adapter for solid. they threw in the test suite and they just started cranking away passing tests and then like we're done i was like what the heck so so we launched tan stack router for solid last week and it works great and then i just got a message this morning from let's see i want to double check who it was it was from brinley he's like uh hey so just so you know tan stack start for solid is pretty it's pretty much working that's amazing are you joking so i mean there's some there's still some things to like polish up, but it's incredible.

29:12So we actually, we named it tan stack start because I knew that router was probably going to go to other frameworks, but I didn't know if start would. Well, just a couple of days ago, Manuel Schiller on my team, he's like, Hey, by the way, we're renaming tan stack start the package to tan stack react start. And I was like, Oh, Oh, oh and he's like yeah it's so there's going to be there already is an internal package for at tan stack slash solid start which is can be confusing because there's also solid start but it's a work in progress on in terms of like how we're managing those two projects like solid start and Tanstack Start, we are working very, very closely with the Solid team.

30:02They are in the Tanstack org. We're in their org. We are cranking on some really cool stuff right now. So Solid Start is actually already using a lot of the new plugins that we built for things like server functions. So the stuff that I told you 10 minutes ago about server functions, 15 minutes ago, we built our own plugins to do that in a way that's like framework agnostic so you could do it across react or solid or whatever and it's pretty validating that that abstraction like on top of like server components and things that are more react specific yes like like the use server directive there's a package called like tan stack directive functions plug it it has nothing to do with react it's just like set it up you can inject your own runtimes into it that can call into your own code.

30:55And we made it like, I mean, in TanStack fashion, I made it extremely like inverted on control. So we put it in and then solid, the solid team Burke and Brennan were like, oh, let's replace the one in solid start with this. So they swapped it out. And then even Brandon who made analog JS, he was like, oh, I'm going to swap mine out too. And so he swapped his out to use this server function plugin and then dev agrawal he's like oh i'm i'm doing something for signals i'm going to use this for signals too so like he swapped it out for signals because it's a directive plugin not a use server plugin so you can actually support other function directives if you want to extract them out which is kind of nuts i think he's playing with something like use socket and then it like it extracts it out and you can do like custom socket logic on client and server like it's cool stuff so needless to say we're working together very closely i don't know if solid start and tan stack solid start are going to merge someday i'd say it's a possibility but it's more likely that they just kind of take on different roles where solid start might be just kind of the example framework to say, hey, this is how you can do a router agnostic full stack framework on top of solid.

32:26Check it out. And it's scoped down a little more, kind of like this is a good way to learn about it or just you do something simple. And then Tanstack Solid Start will be more of like a full-fledged product that you'll say, okay, we really want to use solid and we really want to have like a full-fledged like meta framework that's going to, you know, benefit from extra stuff. So maybe we'll use like Tanstack Solid Start. So that's probably where it's going, but we'll just have to see. We're all just kind of playing it by ear. It's just like, let's, let's just go out there and build cool stuff that we can share and see what happens.

33:10So, so far so good. I'll say that's amazing. You've had this ecosystem of tan stack products for a while, right? Query form table, and now a router and, and a whole like framework. Do you see them working together as like an ecosystem where developers could be like pick up and build pieces with like with these individual pieces and build on top of them? to then support like these more top level solid or react framework level things. I mean, I can say that's already happening. It's already happened. Yeah. Because we have framework adapters for all of the other libraries already. Some of them are more mature than others.

33:51And a lot of that is just based on the popularity of the framework and how many people use it, right? Like Svelte table needs some love, but there's not a lot of Svelte devs out there who are also like, Oh, I'm going to use Tanstack table and let's, and then let's, let's make it better. Right. I mean, so some of it is just talent there, but the adapters are there and they work. You can wire them together if you want, or you don't have to. I definitely like our goal is to stay away from some kind of like monolithic structure where everything only works well together. And they only like they have better support for each other than they do for other things.