TanStack Start 1.0 - A New Full Stack Framework for React and Friends

That's my new picture, by the way. I don't look anything like I did about a year ago, which is a good thing. Things are going well. So today marks 18 months that I've been sustainably working full time on open source at Tanstack, which is pretty crazy. I never expected that my full-time job would be this. And I'm not going to lie, I love it. It's a dream come true.

So hopefully you've heard of Tanstack. If you haven't, it is an open-source organization responsible for some of what I would call the greatest libraries, especially for the React ecosystem. And recently we have been building something that we're very excited about. It's called Tanstack Start, obviously, it's the name of the talk. And Tanstack Start is quickly becoming a great way to build all kinds of apps, whether that's dynamic, server-driven websites, full stack, client-side, SPAs, even static sites, and whatever you want to throw at it with vibe coding. It's pretty versatile. And I'm going to do my best today to show you how it works and why we're really excited about it.

So first of all, this new framework, like all of our other libraries, are not just written with TypeScript, but they're designed to be type-safe from the ground up. And it's really painful that I have to keep saying this, but those two things are not the same. To explain this, I would like to briefly help you understand the status quo of writing type-safe code for the web. Even when using like your favorite popular TypeScript libraries out there, this is common syntax to see all over your applications with syntax annotations, basically. And they're just about everywhere in your code. And unfortunately, this experience typically defines learning and using TypeScript for most of us JavaScript engineers.

It's not very fun. Writing and maintaining all these type annotations everywhere, it takes a lot of effort. It's repetitive. It's error-prone because it's optional. It's forgettable because if you decide to give up, you can just not do it and bypass it. And to me, that is a one-way street to bugs, eventually burned-out developers, and eventually a very real strain on your end-users. So I'd like to show you the same code. This is code that works. I redacted some of it. But I want to show you how it can be designed to be fully type-safe.

So believe it or not, this is also TypeScript. And it's even safer than that last version that I showed you, despite there being zero type Zintax in any of the code. So at Tansec, we have spent a long time, years, researching and perfecting our ability to infer the types out of your application code and business logic. And the result is actually less code that we just saw. But it's also safe by default. It doesn't take any effort, no matter what your skill level is. So whether you're an expert or a junior, or you're just learning.

And this makes it foolproof. Because type safety isn't something you want to have to think about. So this ultimately allows you and your team and even your AI agents to actually get back to building stuff, instead of worrying if it's going to run in production. It turns out when you lean into this type-safe first design, it pays dividends, the more that you invest into it. So it makes all of these things easier. Building new features, fixing bugs, refactoring, pivoting everything in your entire application with full type safety and tools that are designed for it.

You have as much reassurance as you possibly can that nothing's going to break. So type safety alone makes Start a very compelling choice of web framework. It makes it extremely different already, out of the box, from everything else you've ever used. And it's really difficult to explain that. You kind of have to experience it. So if you hear people being like, oh, 10-Sec Start and type safety. And you're like, why are you excited about this? Go and try it out and experience it, and you might understand why.

But also, it's uniquely client-first. This is weird because five or six years ago, I wouldn't even have to have said this, but we've been obsessed with the server, very much so, over the last couple of years. So now I have to say, it's a client-first, full-stack framework. What does that actually mean? It means that it behaves like a single-page app. It shouldn't be anything revolutionary, but a single-page app, we've been doing this for the last decade, right? You get to keep reasoning about this really simple mental model. It's SSR on the first request, and after that, it turns into an SPA.

We've been refining this model for the last decade. And only recently have we been doing these big shifts back to the server, which is cool for some aspects. I mean, we just heard Amy talk about how awesome Redwood is, and Next.js, and React Router, and everybody's talking about the server. I've been building apps for the last 10 years that have been SPAs. And I don't necessarily want to leave behind all that hard work that we've done over the last decade. So the idea is that you get to keep the libraries, and the patterns, and the speed of the existing SPA ecosystem that we've been investing into for so long.

But now, with one massive difference. You have this ability to weave in server-side capabilities if and when you need them. And that 'if' is very important. Tanstack Start is able to do this, first of all, because it's based on Tanstack Router. So I'm going to hype Tanstack Router big time right here because it's a majority of the framework itself. Like, 90% of Start is just the router. And there's just not really another router like it out there. I would say it's the first of its kind in the developer experience, the type safety that we just talked about, all the APIs that it comes with on their own. It's a serious upgrade for any web application, across any React meta-framework, or any JavaScript framework hands down.

The experience you get with Tanstack Router is truly unique. And that would just work for a client-side app, if we're not even talking about SSR or server, or full-stack stuff. But Start is based on Tanstack Router. So it inherits all of those things.

Start brings with it the solution to the server. SSR, streaming, API routes, server functions, middleware. And same as Redwood, which is a great attribute, a fully transparent request-response lifecycle. And because of this, it works anywhere that you deploy it.

I think that all this stuff is table stakes. I don't want to get up here and say, hey, we built a framework that does the same thing that everybody else does. I want to show off Tanstack Router and start briefly, really quickly, and show you what it looks like and feels like to use, and then maybe show you some fun things that we're working on that are really going to be unique.

I wish I had prepped more for this demo. It could be interesting. So if you like something you see, you could clap, and I'll be like, oh, let's go that direction. And if it's silent, I'll just be like, OK, let's move on to the next thing.

Hold on. I got to change to mirroring really quick. Entire screen. Yay, demo time. All right. So I'm going to use the Tanstack CLI to create a new project. npm create or pnpm create at tanstack start latest is going to kind of boot up our CLI. Jack Herrington is the one who has been building this CLI, and it's fantastic.

We're just going to name this React Summit. Yes, Tailwind, no, don't care right now. Let's go with CloudFlare in honor of the day. And don't worry, we're not going to deploy right now. We could add on a bunch of add-ons if we wanted. I'm not going to do any of this. There's a ton of them. And all of these add-ons, they'll either integrate right into the system as it builds. Some of them are demos that you can just delete easily.

We're not going to do any of that. We even ship it with a chat demo. We're just going to do AI these days. We're not going to do that. We're just going to go with bare bones. Hopefully, pnpm doesn't mirror through CloudFlare today or something like that. Yay, it worked. Okay. So CD React Summit.

All right. I'm going to bring up my editor really quick. Let's go full screen on that. Bump that thing up like crazy. And then let's start the dev server. And local host. What is this? There we go. All right. Cool.

So we've got this fun little demo site. And it's like, welcome to 10 Stack Start. Here's some documentation. This page is running, it's just running 10 Stack Start. So this page was SSR'd. And I think if we turn off JavaScript, it just keeps working. So yay. SSR checkbox. Now we can move on.

We have server functions. So this timestamp. Wow. It's time. Look at the time. We got that time from the server. And we did it in a server function. And I'll show you that in a minute. I can even show you API requests that don't even have anything to do with server functions. This is just, you know, get, put, post type handlers. I can show you that. And we even have some demos of, hey, this is SPA mode.

So this page is an SPA. We don't do anything during SSR. And you can just kind of say, you know what, for this route, I only want to render on the client. And we can do other things like do full SSR, which the whole site's been this way the entire time. I don't know why we have that example. And then there's data only, which is interesting. All this data, the data was actually fetched on the server and streamed down. But we rendered everything on the client. So you can kind of split. Very unique. You can't really do that with any other framework. It's very fun. Let's dig into the code.

I just want to give you like the brief, the quick tour of kind of what it feels like to use TanStack Start. I have seven minutes. Great. Okay. So we have a router file. This is where we create a TanStack router. What's fun is all the stuff that you learn about TanStack router, if you want to start using Start, none of that has to change. There's no modes. There's no upgrades. There's no syntax changes. Nothing. You can just take your existing routes and you just keep using them the way you've been using them, but now you have all this server side magic that you can use. This is one of the only changes you have to make is you have to put your router inside of this get router function because we create a new router for every request.

After that, everything is basically the same. This route tree is generated because we ship with file-based routing. If you want to use it, you can do code-based routing, too. If you want, you can even do configuration-based routing.

We support all of the flavors. Here's our routes folder over here. This is our root component and this wraps our entire application. We've got head and meta. We've got some link tags that we're putting in there. Here's our root document. We actually control the entire layout with HTML body header. We even have TanStack dev tools in there. That's pretty fun. We're rendering all of our scripts and then we're passing our children and that's where we're going to render the rest of our application.

Here's our index page. What's fun is if we were to create a new route inside of here, just a fun little route, let's do test.tsx, we just fill it for you so you don't have to worry about boilerplate. Some people are like, what is this? Don't worry. This is how we make it all type safe. You just export a single route. Here's a component. Here we can add a loader and this will return this message. This is a core thing that I want to teach.

The only thing that you need to unlearn and learn with TanStack start is that everything is isomorphic by default. Isomorphic is a fancy word. What does that mean? It means all the code that you write and see by default will run during SSR on the server and on the client during future navigations. If you've ever used Remix, you might be thinking, this might run on the server. It doesn't. This runs on the client and the server. The question is, how do I make it run only on the server? We can create a server function. Any of the logic that we put inside of here now is only going to run on the server. We can also run this function from the client, but it's an RPC. It goes back to the server to ensure that we only run it there. That's how we create an isomorphic first framework. There's lots of other utilities that let you isolate your code to only the server or only the client.

It's very cool. Let's be done with this page. Let's go back here to some of these demos. Here is that API request route that we were looking at. I'm not even going to show you that one. That one's not cool.

Here's the data only route. This is fun. If you saw that list of punk songs there, all we did was say SSR data only. What that does is we grab this data on the server and we stream it down, but the component doesn't render until we get to the client. We're using the server and SSR to do some fun things with streaming the data.

We're already on the server doing SSR. Let's get the data while we're there, stream it down. Maybe you have a bunch of stuff on this page that you're like, you know what? We don't need to SSR the actual content. We'll just render it on the client. That's kind of a fun pattern. This full SSR is just the default. There's nothing in here that's special. Or there's SPA mode where you just say SSR false. None of this is going to run or render on the server at all.

We can just actually take this entire demo and delete it, I think. We're just kind of back to the regular stuff. What's cool in here is if we take a new route, and let's just call this about.tsx. Oh cool, we have an about page now. We'll go back to our index. On the home page here, I'm just going to come to the bottom and write a link. It's a link tag, an a tag, that we want to go to a specific page. This is where that type safety comes in if I could import my link component. We specified a link. We don't have a to. We're just complaining. It's like, hey, it needs to be a link to one of these places.

If we go to autocomplete, we'll see that we have about. Links are all type safety. That type safety follows you everywhere. If we were to go to about and actually add a search, validate search, object. Let's say this page required a name. Let's do default world. I think Zod is already in here. I hope it is. No, it's not. We're just going to do this. It'll just be a function with search and that should work just fine. Name, search name, world as string. Obviously we would want to use a validator here, but I don't have Zod installed.

It will infer these types. You know what? Let's just break the rules. I know I talked about, if we get lazy, we can just disable it. Let's just do this. D as string.

No, let's make it better. Name string. Cool. We'll just pretend that we actually use Zod to validate this data.

Then down here, if we want to use the search, we can grab name and it will be a string. You can actually grab this from any other route as well.

Then if we come back to our index page, you'll notice that we have an error now because we declared a required search parameter on that page. This link is now complaining and it says, hey, you're missing params. Okay, let's add params.

I don't know what it is yet. Let's just pretend I'm a junior developer and I have no idea what I'm doing. Okay, it still says search is declared here. It's not params, it's search. I'm sorry. Search is complaining now.

The expected type comes from search because it's not assignable to name dot string. We actually have to pass a name and finally it stops complaining. We can make this as strict as we want.

This is exactly the type of experience I had to build at Nozzle, this huge Sass application because we had dashboards and links going everywhere, saving all that state into the URL, which you should be doing. You can imagine why all this stuff becomes extremely valuable. I have 38 seconds and so much more to show, so I just got to stop demoing.

All right, let's close this. I'm going to go back to my keynote really quick. All right, so much more to demo. There's so many videos. Just come talk to me and I'll show you as much demo as you want. There's just not enough time in the day to show you everything, but I have some last closing thoughts. I'm going to go into my Q&A a little bit.

From my personal perspective, I feel like the last few years our meta-frameworks have been asking a lot from us. They've been asking us for changes to our mental models.

They've been asking us to refactor sometimes our code, sometimes the way our brains work. They've been giving us breaking changes and kind of dancing around solutions. RSCs have kind of thrown everything for a loop. Moving to the server is very tumultuous. All of this movement I feel like has given us very little benefit in return, pragmatically. As somebody who just needs to build an application, deliver something to my users, I don't see a whole lot of benefit.

So for me, it's felt even more difficult at times to do what I used to consider simple and easy just like four or five years ago. This is why I believe that React does deserve a new meta-framework, and we're getting them. We just heard about one before, and I believe that we deserve one like TanSec Start. I believe that Start is a practical, stable, open, very community-based project, and it's ultimately not at the mercy of a product company roadmap or a bottom line.

This is a project that has tons of talented engineers and partners and users already shipping it to production that believe that Start is critical for React's future. We have spent a total of five years developing the technology that went into TanSec Start. I believe that it actually will improve the quality and the speed that we can build for the web in a very meaningful way. I'm here to earn that claim. We're here to earn that, and the only way for us to do that is for you to go and give it a try and let us know what you think. That's it.

Get your questions in, in Slido, and we can start with the first one. Can you do SSG or static site generation with Start? Yes. Yes. Yes you can. Yes. Yes. Cool. How would we integrate type safety logic into a mono repo? I'm not going to lie, the mono repo stuff is difficult. We have people who are building mono repo projects that are really large, and for the most part, it's not a big problem unless you're splitting your front end, like your routes, into multiple packages. If you're doing that, not only you're going to have a hard time doing that with most routers anyway, but especially with the type safety, the way that the type safety works, there's some tricks and hacks that we're working on to make that easier, because the way that the types work is they're kind of omnipresent across your whole project. Packages, if they have separate TS configs, it's difficult to isolate the router types to specific packages. We're working on it, and it's really not that big of a deal. Actually, the person who has been experiencing it the most is Dominik Dorfmeister, TK Dodo, who works at Sentry. He's been using TanStack Router a lot, and he has mono repo ideas for how to make that better. Nice. I heard Sentry's a great place to work. Yeah, I've heard of that.

How would I know? Alright, how does TanStack Start automatically add boilerplate code when you create a new file? TanStack Start is just a Vite plugin. I didn't show that part, but you can just add TanStack Start, the Vite plugin, to a Vite configuration, and that's all it is. At the end of the day, it's really just a request handler, and we use Vite to prep that request handler. Because we're already hooked into Vite, we can actually hook into the dev lifecycle, listen on the file system, and we can watch the files you're creating. When we find a new route that comes in that's blank, we just make some educated decisions for you and write the content, and write it out to disk. It's very performant, too. We can watch hundreds, maybe thousands of route files and keep them up-to-date. In fact, if you saw the path inside of the create file route command, you actually don't even need to manage that. If you change the name of your route or move it to a different path, we just update that path for you in the code. Which can be kind of surprising for some people at first. They're like, what the heck? Why did that string just update in my file? And we're like, oh, we got you. We're queuing on for you. Super useful.

How does trpc play with SSR data-only mode? And once fetched, can you pass data to client.js to Hydrade state? trpc plays great. In fact, all of these other APIs, I'm going to answer Dax's question from Twitter, actually, again, and he's going to shake his head at me. But you can take any of these back-end frameworks like Nest or Hano or whatever you want, trpc, and you can do two things. You can either plug them into 10Stack Start just as a handler. I should have shown you that. You can just do a catch-all handler inside of 10Stack Start on an endpoint and just pass it to Hano. Or you could do the reverse, and you could drive your whole thing with Hano, and then when you get to some route that you want to use 10Stack Start, you just pass the request to the 10Stack Start handler. So it plays nice with trpc, full circle. Once fetched, can you pass the data to client.js to Hydrate state? Yes, absolutely. And then trpc uses react-query, which integrates basically automatically with 10Stack Start, and you don't have to worry about passing or serializing or hydrating anything. That's all just handled for you. Nice.

How difficult is it to migrate an existing application? It depends where you're coming from. If you're coming from Remix or React Router, it's amazingly simple. If you're coming from Next Pages Router, it's pretty simple. If you're coming from Next App Router, you've got to unlearn some things and do a little bit of migration. So you'd be like unwinding all these server component nesting things that you had to do to do data fetching, and then just putting them into loaders. But other than that, conceptually and in practice, it's pretty simple. We have migration guides on the site that are pretty straightforward. And I've even heard of some people taking those migration guides and almost one-shotting migrations through cursor and cloud code.

That's all just handled for you. Nice. How difficult is it to migrate an existing application? It depends where you're coming from. If you're coming from Remix or React Router, it's amazingly simple. If you're coming from Next Pages Router, it's pretty simple. If you're coming from Next App Router, you've got to unlearn some things and do a little bit of migration. So you'd be like unwinding all these server component nesting things that you had to do to do data fetching, and then just putting them into loaders. But other than that, conceptually and in practice, it's pretty simple. We have migration guides on the site that are pretty straightforward. And I've even heard of some people taking those migration guides and almost one-shotting migrations through cursor and cloud code. So it's worth a shot. Nice.

How does 10Stack Start perform on large code bases with thousands of React components? It performs great. And it actually will probably perform better than most other routers because we use fine-grained subscriptions. For every 10Stack library, we use fine-grained stuff. But especially for the router, when you're subscribing to search parameters or re-rendering things or navigating around, we're actually not re-rendering the entire tree of components. We're only re-rendering what needs to change ever. So it actually is really fast. And it's not just thousands of React components, but we've tested 10Stack Start and Router up to tens of thousands of routes. And we even tested it against type safety as well. Can the type safety keep working with 10,000 routes there? And the answer is yes. In fact, it still behaves as if you only have one file open. So props to Chris Hrobin. If anybody knows who Chris Hrobin is, he's a TypeScript performance wizard. Yeah. That's a wild skill set. It is. Yeah. Let's see. So is data-only mode like SPA, but with pre-fetched data? What would the page look like with JS turned off? No, data-only requires a server.

It requires an SSR. The only difference is, imagine SSR and you're doing all the same work, but you're just not rendering the component on the server. You're just waiting to do that on the client. So that question doesn't quite make sense, but that's okay. Yeah.

And another one that might not, is it integrated with Next.js by default? Oh yeah. Yeah. I don't think, I think this person missed the- To be clear, right? It is very separate, right? No, sorry. I was being sarcastic. Yes. Yeah. That doesn't make sense.

How is TanStackRouter different from ReactRouter? TanStackRouter is built from the ground up for type safety. ReactRouter has decent type safety now, but a lot of it was kind of retroactively bolted on, and you can kind of see that in the design of the types. Also there's just like a lot more advanced functionality built into TanStackRouter that you end up either having to kind of write yourself or kind of architect yourself, especially around search parameters.