← Software Engineering Daily
Software Engineering Daily
TanStack and the Future of Frontend with Tanner Linsley
00:54:13
TanStack 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,
Loading summary
Transcript82 lines
- [00:00]
Narrator
Tanstack 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 Nisi to talk about the project, SSG type safety, the Tanstack Start Full Stack, REACT framework, and much more. Nick Nisi 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 Work OS.
- [01:10]
Nick Nisi
Tanner Lindsley welcome to Software Engineering Daily. How's it going?
- [01:14]
Tanner Lindsley
It's going great. How are you?
- [01:16]
Nick Nisi
I'm doing fantastic. Why don't you tell us a little bit about yourself.
- [01:19]
Tanner Lindsley
I make software, primarily open source software now as of about almost, 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.
- [01:49]
Nick Nisi
Yeah, that totally makes sense.
- [01:51]
Tanner Lindsley
Before that I was like an Angular Ionic junkie who was making money off of WordPress. So 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, you know, it's helping people.
- [02:31]
Nick Nisi
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? Was it the first project in the Tanstack?
- [02:48]
Tanner Lindsley
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 like 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. And 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 could 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. So I was like, yeah, you know, I. 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. And they're like, yeah, and we're gonna be dumping everything we have into Gatsby and Next. And I was just like, oh my gosh. Well, I don't really. 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, you know, we're going to 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 to 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. So 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.
- [05:41]
Nick Nisi
Nice. Well, yeah, let's dive into that and talk about 10 stack 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?
- [05:53]
Tanner Lindsley
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, you know, it's doing full SSR and hydration. We're running that server in, you know, on deployed server somewhere, whether that's serverless or, 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 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. But then in design for how you interact with it, all of the routing and all of the like application stuff is very separate. So if you're doing something with server functions that comes from Start. If you're doing something with like 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 remote, 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, cause we're using local storage or something like that. But otherwise everything runs during SSR and on the client by default. And that's a pretty, 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 know, you're, 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 like thrust upon you. Yeah, like a good example of that is loaders. I mean even remix in their, in their, 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 navig. 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.
- [09:28]
Nick Nisi
Nice. And how do you define a server server function? Is it in like a somewhat familiar way, like Use Server, like a pragma, like that? Or like, how do you do it?
- [09:39]
Tanner Lindsley
Yeah, we have kind of two flavors. The, 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 on the server. Do a little RPC that 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? It'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? 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 it get? Could I use super JSON with this? 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 createserver function. And if you've ever used trpc, it probably will feel a lot like creating a TRPC procedure or mutation or query. So you call createserver 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 can start customizing things about how is this going to go back to the back end. You can also start adding middleware to that. So you can chain off of there 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 I O for context. So 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 Century 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, 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. But we wanted some extra security around things, you know. And so we added first class validation support for server function payloads. So what you can do is you can say dot validator and you can pass any standard schema compliant validator. So Zod, archetype, valabot, or you can just write your own if you want. It's just a function that takes input output with types of 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 the client.
- [14:24]
Nick Nisi
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 validator. So, like, if you have something like you're using 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, and then you handle that in a pretty standard way across everything. Yeah.
- [14:45]
Tanner Lindsley
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 rethrow it on the client and you get to respond to that Zodiac error however you want.
- [15:08]
Nick Nisi
Okay, nice. So. And you can respond on both sides too?
- [15:13]
Tanner Lindsley
Yeah, if you. If you wanted to. So on the, on the server side, the val, 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. The default is that if it, if it doesn't validate correctly on the server, it'll just go back to the client. So. 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 Zodiac to the client unless you want to just turn on client side validation too. And then we'll. We'll ship it.
- [16:07]
Nick Nisi
Got it. But then on the client, it's giving you those odd errors or how is that?
- [16:13]
Tanner Lindsley
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.
- [16:20]
Nick Nisi
Okay. So it'll be a different validator.
- [16:22]
Tanner Lindsley
Yeah, well, now it's the same validator. For now 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 very. We want it to be like Anything you can catch on the client, do simply now skip the network I O. Otherwise, just send it to the server.
- [16:51]
Narrator
This episode of Software Engineering Daily is brought to you by Capital One. How does Capital One stack? It starts with applied research and leveraging data to build AI models. Their engineering teams use the power of the cloud and platform standardization and automation to embed AI solutions throughout the business. Real Time data at scale enables these proprietary AI solutions to help Capital One improve the financial lives of its customers. That's technology at Capital One. Learn more about how Capital One's modern tech stack data ecosystem and application of AI ML are central to the business by visiting capitalone.comtech.
- [17:32]
Nick Nisi
Now. Speaking of type safety, one of the big features that I see come across, and this might be more of like a Tanstack router thing and a Tanstack Start thing because, and correct me if I'm wrong, but the big difference obviously is like the server side functionality of Tanstack Start, but then also like there's file based routing within that. Is that true?
- [17:49]
Tanner Lindsley
So the router itself has file based routing even if you don't use Start.
- [17:54]
Nick Nisi
Oh, okay. And that's just part of Tanstack Router.
- [17:57]
Tanner Lindsley
Yeah, just part of Tanstack Router. So the router itself had nothing to do with server side anything, but just the router itself has a Vite plugin and a CLI and in fact it even has an RS pack and webpack plugin as well. So you can run these plugins 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.
- [18:29]
Nick Nisi
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 and to be honest, I haven't dug into it enough yet to fully understand that. So could you explain that to me?
- [18:44]
Tanner Lindsley
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, you know, 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 gotta, you know, make your own function signatures or whatever. But for the most part, like you can just write with Tanstack Router and never need to cast anything or write type code at all or annotations. You never, yeah, you know, you never have to like 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, 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. 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.
- [20:22]
Nick Nisi
Like providing a generic. Something to a generic.
- [20:24]
Tanner Lindsley
Yeah, providing a generic. Or even with React router's new stuff, you have to remember to import the types and then grab the right types off of, you know, that file and put them where they need to go. Or even there's like Next JS and Remix. They both use like a link building utility where, you know, 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. You know, 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. From 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'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 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 safe 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. So 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, how, 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.
- [23:13]
Nick Nisi
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.
- [23:27]
Tanner Lindsley
And 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, you know, crazy, crazy things. And at the end of the day, I found a way. And after we had exhausted every possible avenue of doing this without language service plugins or like, 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? And 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 the hierarchy of your file system. And that's a very important thing if you're doing file based routing.
- [24:46]
Nick Nisi
Yeah. For like sub routes and things.
- [24:48]
Tanner Lindsley
Yeah. Nested routing. And so we had to come up with a way to teach TypeScript about the file system that that was performant and like lazily evaluated and performant enough to scale to tens of thousands of routes that wouldn't crash the TypeScript language service, you know, and we did. Christopher Horobin 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 Tanstack router. I proof of concept at it. And I made it work. And I made it work. Right. He's making it work fast.
- [25:42]
Nick Nisi
Nice, Nice. So you mentioned working on just like pure types for a long time without actual any runtime code. I'm curious, like, did you use any way of like doing automated testing to ensure those types were correct? Or like, how do you, how do you approach that when you're not actually writing runnable code?
- [26:03]
Tanner Lindsley
Well, 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.
- [26:14]
Nick Nisi
Yeah. So TSC is your test.
- [26:17]
Tanner Lindsley
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 vitess typescript stuff to say, you know, expect this type to equal this type. And for the most part, like that. Not for the most part. It works great. Yeah. So we'll go through and we'll change the types or fix bugs or whatever. And it will say, hey, you know, like 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.
- [27:23]
Nick Nisi
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. And so having a way to ensure that this is not just going to give you some weird type or some unknown or any type. It's going to be what it always was.
- [27:42]
Tanner Lindsley
Yeah. We have extensive type testing as well. So just for router, we have over 200 test suites that run just for all the packages in router. It's a lot which is a stark contrast from about a year, 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. Sean Castieri and Manuel Schiller are like. And Chris Christopher Horobin on the type side. But like, they're all much better developers than I am.
- [28:23]
Nick Nisi
Another question I have around Router and Tanstack 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?
- [28:41]
Tanner Lindsley
So I was actually on stream about a week ago with Ryan Carneato. We officially announced Tanstack Solid Router.
- [28:50]
Nick Nisi
Oh, wow, cool.
- [28:52]
Tanner Lindsley
So it's. 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 Brinley. I always knew his screen name is Brynells, but Burke and Brinley from the Solid JS team, they really like Tanstack 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 Tanstack 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, hey, so just so you know, Tanstack Start for Stall. It is pretty much working.
- [29:47]
Nick Nisi
That's amazing.
- [29:47]
Tanner Lindsley
Are you joking? There's still some things to polish up, but it's incredible. We named it Tanstack 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 days ago, Manuel Schiller on my team, he's like, hey, by the way, we're renaming Tanstack Start the package to 10 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 10 sack slash solidstart, which 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, Intense Extart, we are working very, very closely. With the Solid team, they are in the tanstack. Org, we're in their org. We are cranking on some really cool stuff right now. So SolidStart 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.
- [31:15]
Nick Nisi
So it's pretty validating that that abstraction like on top of like server components and things that are more React specific.
- [31:21]
Tanner Lindsley
Yeah, so like, like the Use Server directive there, there's a package called like Tanstack Directive Functions plugin. It has nothing to do with React. It's just like set it up, you can inject your own runtimes into it and that can call into your own code. And 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 Bradley 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 doing something for signals, I'm gonna 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 Tanstack 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 Framework, like a router agnostic Full Stack framework on top of Solid. Check it out, right? 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. So far so good.
- [33:55]
Nick Nisi
I'll say. That's amazing. You've had this ecosystem of Tanstack products for a while, query form table and now a router and a whole framework. Do you see them working together as an ecosystem where developers could maybe pick up and build pieces with these individual pieces and build on top of them to then support these more top level solid or React framework level things?
- [34:22]
Tanner Lindsley
I mean, I'd 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 and 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. Like we want to make sure that it's more like Unix style composable blocks that work good with everything. Like if the right APIs are there, designed with good inversion of control, they should work good with everything. So actually two weeks ago Jack Harrington built a new tool called Create TS router app and it's a drop in replacement for Create React app.
- [35:41]
Nick Nisi
Really?
- [35:42]
Tanner Lindsley
Yeah. Other than some, some differences between webpack and modern vite. So like it won't support, like it doesn't support like old school ES5 output and stuff like that. But for all intents and purposes it is a drop in replacement for, oh, I was going to use cra, I'm going to use. I'm Going to use, you know, cta. What's cool is you can just say npx, you know, Create TS router app drops in and it looks exactly like cra. But then behind the scenes you go to like that main. That main app file. It looks exactly the same. But if you go up a level to like the main entry, you'll see that we've already set up Tanstack Router for you just with a single app, you know, or a single route that's just going to this one component. And you're like, well, what if I didn't want code based routing, which I want file based routing. Well then you can add a file router to the Create TS router app and it will give you file based routing. And then you're like, oh, what if I want to use Solid? You can do Dash Dash Solid now and it will do Create React app essentially, but with Solid instead, using Tanstack router for Solid and then going even beyond that, we have add ons where you can say add ons and it brings up this select list where you're like, oh, I want to add Tailwind Shadcn Century. I want to add Netlify stuff. Like a demo for netlify things. You can just check off a bunch of stuff and we will install them, give you demo pages for them and wire it all up for you. And then we also have templates too, which is Create React app had templates as well. But like we have a template called Tan Chat that's coming out that's like, I think it's an anthropic, you know, hey, here's just like a really demo, fun Tan Chat thing. Sentry has an example that you can trigger. You can manually trigger errors in a couple of different places and watch them come into your Sentry dashboard live. And with full stack observability. It's really cool.
- [38:00]
Nick Nisi
Not that it matters. I'm just kind of like thinking but I know that like with Create React app it was kind of doing like this weird managed thing where it wasn't exposing you directly to webpack. Right. It had like a minimal configuration.
- [38:11]
Tanner Lindsley
Yeah. Like they had their own package called Create React Scripts, I think. React Scripts. Yeah. No, we're not doing that. I think that's dumb. I mentioned to somebody that it's almost like pre ejected in a way, but not in a way that webpack was. Where it's like now you have this huge webpack config to handle. Like really? There's a vite config JS file sitting there and you're like, oh, it just works because we're using the React Vite plugin and it works great. And if you want to go in and add anything or do anything with Vite, you just add the plugin. You do whatever, you know, and it's like you can still upgrade Vite and upgrade your plugins and upgrade the tech, even though you're customizing things. Right. So it gets away from that. Like, you know, you're locked into this. Like, we're gonna fully manage everything for you because we don't trust you. I mean, that's essentially. I mean, with webpack, there was good reason around that. It's like, I wouldn't trust a lot of people to do that either. But with Vite nowadays, like, I trust people with Vite. Like, go ahead. Like, there's only a few things you could probably do that will mess things up terribly and you can always just roll it back or whatever.
- [39:22]
Nick Nisi
No, that sounds definitely like a better approach. And that's kind of why I was asking, because there's such a great ecosystem of tools within Vite itself that hiding that away or making that more difficult to adopt anything else is almost a detriment, but it sounds like you're obviously doing the right thing.
- [39:37]
Tanner Lindsley
What's cool too, is it works with Start. So Start is currently in beta. Right. And for now, for today, still, we use Vinci as like the. As like a little runner. So you say like Vinci Start, Vinci Build, or whatever. I'm actually working on internally we call it DaVinci.
- [39:58]
Nick Nisi
Yeah.
- [39:59]
Tanner Lindsley
Which is D Vinci, but we're working on just using Nitro and Vite directly, like a Vite plugin. We've wanted to do that from the beginning, but we just needed to move fast. So Vinci let us do that. But now we're to the point where we're just getting rid of like superfluous stuff. And we could talk about that. We don't need to. But anyways, if you add Start to that Create TS router app command, you'll get a Start app and it will actually look exactly the same as Create React app, but it's server side rendered, has routing installed already. It's pretty cool. Now, I'm obviously biased, but I think it's the best way to start a new app these days.
- [40:42]
Nick Nisi
Nice. Yeah, I'll definitely have to check that out as I'm constantly creating new apps. You did mention 10 chat and that got me thinking about AI and so I wanted to ask you what AI means to you. Kind of day to day. Like are you using it your day to day development or what does it mean to you?
- [41:01]
Tanner Lindsley
Yes, I pay for ChatGPT and I use that all the time just for personal stuff. And I mean, I basically use it instead of Google now and actually can't remember the last time that I used Google to like research something. I use Google all the time to like search for a site that I need, that I need to go somewhere, you know, so it's, it's more, it's become more like aol, AOL keywords or something.
- [41:29]
Nick Nisi
Yes.
- [41:30]
Tanner Lindsley
Remember those?
- [41:31]
Nick Nisi
Unfortunately, yeah.
- [41:33]
Tanner Lindsley
But Google now is less of like a research tool for me or like question tool. I just send all that to OpenAI ChatGPT and then for programming, sometimes I'll use GPT because it's just options based and it's just kind of there. But I'm using way more cursor lately. Really like cursor. I still think it's better today than what Copilot has and what Windsurf has. They're all really good, but cursor is just amazing. And I don't even use a lot of the agent stuff for the kind of code that I'm writing. There's not a lot of prior art out there. So I don't really trust agents to go and write the kind of library code that I'm writing when I'm building an app or a site or like, you know, templating some tailwind or something like that, like, oh yeah, like sic an agent on that and let them write kind of the grunt work stuff. But for me it's way more of a utility to say to have Cursor sit on top of the tanstack router, repo and see and index all of the patterns and type utilities and things that are inside of our entire code base. And then for me to go and try and write a new feature, it's helping me remember, like, oh yeah, you have this API, I'm gonna use it. You use this pattern here. Let's use the same pattern here. And it's frighteningly smart at auto complete and just like taking my ideas of like, oh, this is how I want to architect this thing. And it just kind of like tries to read my mind. And because it has enough context in my projects, it usually does. And I wouldn't say for me, it's not necessarily coming up with novel ideas for me instead, the two places that I think that it does help is it just helps me go faster, so gets my ideas out faster. I Don't have to type everything. I mean, even Copilot was great at that, even if it was one line at a time. So it just helps me go faster. And also it helps me when I brush up against areas of programming or other like APIs or services that I'm not super familiar with. I'll kind of be like, hey, I think this is what I need. And then it will kind of autocomplete and I'll be like, but that doesn't work. So it's almost like a learning tool as well to like learn fast, to say, hey, you know what, I don't know how this node streaming API thing works, so I'll just be like, command K, write me. You know this logic. But I need you to use node streams and I need you to convert them to web streams. And then I'm watching it go. And then I'm like learning as I use it too.
- [44:27]
Nick Nisi
Yeah, yeah. And I mean, that's a fantastic way to put it. Like we're no longer really in the world where we're staring at a blank, a blank file and like figuring out how to get started. Like you can just throw something out there and you're good enough to know this is close or not close at all and kind of refine it from there, either with AI's help or manually. That's how I'm approaching it as well in my day to day work. It's kind of like a lot of managing context.
- [44:53]
Tanner Lindsley
That's a great way to approach it. And I would also say on top of that, there's always going to be discussion about is AI going to replace me? Or whatever. And I get asked that a lot like private DMs or whatever. Like, are you worried about this? And to that I would say, look at how much code you're writing that the AI is currently unable to do correctly. Right. If that is close to zero percent, then you're going to be replaced soon. If it's 50%, man, you're fine. You know, like if 50% of the code you're writing is impossible for an AI to figure out how to do correctly, you got good job security, you know, and that's for me, like, if I, if I ever get to the point where like, oh, I'm not writing, you know, it's like, oh, AI could write all, you know, design me a type safe router repo to be used by every everyone and everything, you know, in their cat and dog or whatever. As soon as it can do that. Like I've Got to evolve, you know, so that's usually a good measuring stick for me. And you know, when you, I think when you use that measuring stick there are actually very few people who are trained truly just yoloing some AI code out there without even being able to say, oh, I gotta test it and try it and debug it. But it's getting there. It's pretty scary how good some stuff is that can one shot things.
- [46:19]
Nick Nisi
And you mentioned prior art and how it's not super useful for that. There's not a lot of prior art in what you're doing and I think that coming at it from another perspective, you are in a unique position in that you're releasing a framework within the last year where there's not a lot of prior art for these models to be trained on specifically. So I'm just curious. Next and remix. And all of them do have that prior art. The AIs can have a little bit of context to help, but they won't know a lot of the new features. But it's like a feature thing. If I ask an AI about Tanstack Star, I haven't by the way, but if I did, it might not know much of anything. And just as an author of a new framework and paradigm, I'm curious if that's something that's on your mind of how to approach that or how to help developers get over that hump of. My chatgpt is not going to be able to help me create a server function because it doesn't know what that is.
- [47:13]
Tanner Lindsley
Yeah, some of that is just time. Time will heal that to some extent. And I also think that there's entropy that needs to happen for us and I'm willing to be patient for that. There's also atrophy for, you know, outdated and old patterns for other frameworks as well. Like now there's. You can go to Next and say hey or say hey, write me a Next app or write me a, write me a React router 7, whatever. And you're going to get Pages router and you're going to Get React router 6 or Remix or something like that. So there's challenges all around. I would rather have the challenge of hey, you know, they haven't indexed us yet, they haven't been trained on us yet and you can use tools like Cursor to point your stuff towards our documentation or we also. I can't even remember what it was called because that's how new it was. But it's a, it's like a Protocol for AI tool protocol. What's it called? Mcp. Mcp. What's it called? It's called the Model Context Protocol. So we are adding support for Tanstack to be like an MCP service so that you can point your MCP compliant or supported thing at Tanstack and say, okay, Tanstack is now a tool like a utility of knowledge. You know, it can use our database as a way of teaching you how to do better stuff. So we're looking at things like that. I just think I'm not necessarily worried about it, mostly because the same things that I would be doing to teach an AI are the same things I'm going to be doing to teach users. We have to make sure our documentation is outstanding. Plenty of examples. Get more and more people writing projects with it that are open source and public, that use the good patterns, resisting breaking changes, resisting, you know, stuff like that. So it's almost okay that they're not indexing us yet because it's still beta for Start, you know, and some things, some things might change just a little bit, you know. So I'm not worried about that though. It is hard even for me. I get into the source code of like 10 sec router and I'm like, hey, I need to do this thing with AI because there's no prior art. It's like starts bringing in React router APIs and next JS APIs, because that's all it has. And I'm like, okay, you got to stop.
- [49:50]
Nick Nisi
Yeah. And another thing that I've seen people do or I've kind of started to see this on like doc sites and things is like, here's a curse of rules that can help you work with our project. So maybe like something like that too. But I also think the MCP thing, that's so new. I think I only heard about it because I just started playing with Claude code and I think that that can do something with it. But yeah, this is changing so fast and sounds like you're on top of it. So that's awesome too. But also not worrying about it because it's not really needed yet. Cool.
- [50:22]
Tanner Lindsley
I just got to message my wife really quick. Sure.
- [50:27]
Nick Nisi
Yeah. Is there anything else you wanted to bring up or talk about today, Tanner?
- [50:32]
Tanner Lindsley
Let's see. I'm excited about DaVinci. We're going to be using Vite and Nitro directly and a lot of that includes the new environment APIs. So we're going to have in React router. They're experimenting with this now too. It's a hard upgrade path. It's a different world, like the new environment APIs, but they're very valuable because you can run things, you can run like a native deno kind of environment or you can run workerd. If you're going to go to Cloudflare on your machine and kind of replicate that environment that you're going to be deploying to on your own machine, which is really neat. We're working really closely with the Nitro team to make sure that we can support as much of Nitro as possible and it should be almost everything. As soon as we get rid of get rid of Vinci, we're going to have support for deploying to over 30 deployment destinations right out of the gate. And you'll be able to write server side code once and literally just migrate between all of them. Because that's what Nitro is. It's like the server side toolkit that kind of goes everywhere. So as long as you're using the nitro APIs, you could ping pong between like Netlify, Vercel, Cloudflare, whatever, and not have to change really anything. If you do it right, all you have to do is change a string from like, you know, Vercel Edge to netlify Lambda or something like that, and it and Nitro just takes care of the rest. So I'm really excited about that. I'm excited about the SSG stuff. That's big reason I'm doing the Nitro. The move to Nitro and V is because I want more control. I want you to be able to ship spa mode like true spas with Tanstack Start where you actually, you can pre render HTML documents as landing pages that are kind of like ppr, where they're like as much of the page as possible is already rendered out. And then where you want to start your dynamic stuff, you can have these dynamic holes that fill in as soon as you mount. So and then obviously this will probably be after we do 1.0, but we will bring server components to Tanstack Start very soon. They're just going to be a server function that happens to return react code. So yeah, it'll be really simple to use. I think it's going to be refreshingly simple for people to use even more so than like react routers, react server components there, they're doing almost the same thing, but you can only use them inside of a loader. We're going to make it so that you can use them anywhere that you can define a server function which has nothing to do with the router. It's just so. I mean, if literally, if you just wanted to have server functions and react and no router, like, you could if you wanted. Like, that's a weird. It's a weird world. It's almost like what Waku is. But it would be totally possible.
- [53:33]
Nick Nisi
Future looks very bright. I'm very excited about all of this.
- [53:36]
Tanner Lindsley
Yeah, me too.
- [53:38]
Nick Nisi
So where can people find you?
- [53:39]
Tanner Lindsley
I'm usually on Twitter, Enerlinsley, if you want to. If you want to get more personal, you jump in Discord. We can talk in Discord. Share code. Yeah, mostly in those two places. I don't stream a whole lot. I prefer just to work. But, yeah, I mostly hang out on Twitter and in my Discord. Yeah, I'm very open to, like, people who want to DM and chat and whatnot. So if you have cool ideas or feedback or just, you know, as long as you don't want to shout at me, we can chat about whatever you want.
- [54:13]
Nick Nisi
Darn it. Okay. No, thank you so much, and thanks so much for coming on and sharing all of this. I genuinely learned a lot about Tanstack Start. I had no idea about the solid variant of that, so I'm very excited to go look into that.
- [54:27]
Tanner Lindsley
Tanstack Solid Start is probably coming very soon. Like in the next couple weeks.
- [54:32]
Nick Nisi
Awesome. Well, I can't wait.
- [54:34]
Tanner Lindsley
It'll be beta, just like the REACT version.
- [54:36]
Nick Nisi
Yeah. Nice. Well, thanks so much, Tanner, and we'll catch you next time.
- [54:41]
Tanner Lindsley
Thanks.