Tanstack Start - A Client-Side First Full-Stack React Framework

We surveyed thousands of developers, and it was proven that the louder an audience is, the better the presentation is. So I'd like to hear how loud you're going to be during my presentation. Thank you, and it helps keep me motivated.

All right, here we go. So over the past few years, there's been a noticeable shift in web app development. We've gone from a long season of prosperity for client-side rendered apps to this hyper-focus on server-first architectures. This has no doubt drastically improved our full-stack capabilities as web developers, but has come at a bit of a price to the ecosystem. Because on one end, there are wonderful tools that are pushing the limits, but are significantly increasing complexity. There's larger cognitive overhead, and there's been a bit of a divergence from the traditional client-centric architecture that we've grown to love and use.

On the other end, there are tools that are trying to embrace this new world, focusing on standards and primitives, but in my opinion, are still falling short on power and control and safety and overall developer experience. But worst of all, I'm afraid of this new obsession we have with the server, because it feels like we're leaving the client in decay. That makes me very scared. Because the client is so important. It's critical, and it's powerful. It's one of my favorite parts of building web applications. It's where I started. With this big shift, I have felt over the last couple of years that I'm losing something special to me, and critical for what I would consider critical for delivering what my users need.

So I decided to take a big risk and build my own meta-framework called Tanstec Start. It's a new meta-framework for React, and it's drawing on over ten years of experience I've had building data-intensive, client-rendered SaaS ad nozzle, and also building open source tools that made that possible along the way. So Tansec Start might sound familiar. It's based on the same framework toolkit that powers our cousin framework, Solid Start. But its goals are very similar, and its mission is simple. We want to deliver the best client-side authoring experience possible, and then layer on powerful and flexible server-side primitives that don't sacrifice performance or developer experience. So I would say it's unapologetically focused on providing the best routing, caching, and type safety that I can fathom. Three very important features that historically have been deprioritized or under-invested in our industry, but are crucial if you want to deliver the best developer and user experience. To accomplish this, I started Start by building on top of Tansec Router. Routing is the heart of any framework, and also where a bulk of the client's state management should happen. Tansec Router is perfectly suited to this task. So it's 100% type safe, takes everything to a new level, unmatched type safety. It also has URL state management built in, which I'll explain in a moment.

And it has deeply integrated data fetching and caching primitives, not just the router itself, but with some other things that we'll get to as well. But let's start with the type safety. So everything is fully type safe. And when I say type safe, I don't mean it was written with TypeScript. I mean it's fully inferred. You can actually write a completely type safe Tansec Router application and not ever see any TypeScript in your code. There's no second guessing if your routing is going to break when it hits production. There's no more shooting yourself in the foot with bad links or missing search parameters. And this applies to the entire navigation API, essentially.

Beyond these basics, we've gone the extra mile to support things like strict relative navigation, nested search parameters, type safe route middleware, and there's a lot of other next gen routing features that you just won't find in other existing solutions. And we've made sure that this experience with the TypeScript language service provider, that's a big word, can scale with the most complex of types. Thousands of routes using very complex Zod schemas and inference, we can scale that to basically as much as we want without compromising any IDE performance at all. It's a big feat. And I need to put my hats off to some of my maintainers out there. You know who you are. Chris Arobin, also. He deserves some applause. Can I get some applause for Chris? He's the smartest TypeScript person that I know. And he is what has made a lot of this possible. So whether you're building ten routes in your app or 10,000, you're not going to notice a difference.

It also has URL state management. We take it very seriously. Because not only should you be storing more of our client state in the URL so that it can be shareable, bookmarkable, it's also, by the way, it's built in undo and redo right in the browser, just so you know. It's very cool. But we deserve better tools for managing this state in the URL. To make this possible, router ships with deeply integrated search param validation. This allows nested routes to stack validation schemas for only the search parameters that they need. And then you can get this bulletproof reliability that that magic input box at the top of the browser is actually producing usable state in your application. And yes, it's JSON. You can store JSON in the URL.

I don't suggest doing it without thinking about it first. But you can do it. And it's amazing. Which also means we need more powerful navigation APIs that can handle it.

So we built state management right into the navigation API. This is a type save link component that can update search parameters. Here's another one using a reducer function that keeps existing search parameters while updating some of the other ones. There's also imperative versions, obviously.

What I think is really awesome, though, is that you can update everything about the URL with full validated type save JSON support in a single transaction. And this keeps your history stack really nice and clean. But honestly, storing application state in the URL is way harder than it sounds. There's so many edge cases. You don't see them coming. But you don't need to worry about a lot of this stuff because we've managed to solve it all for you.

Things like referential stability, immutable updates between renders and serialization and parsing, and tons of performance optimizations that go all the way down to the low-level adapters that actually write to the URL. And then there's the holy grail of fine-grained state subscriptions, where components and hooks will only re-render when the part of the URL state they rely on changes. Only the pieces you use. It's amazing. And it empowers very high-performance applications. You can store state in the URL that you can update as fast as you want. It's incredible.

So that's all just TanStack Router. And on the client. I could stop here, and it would be a great client-side-only framework. And it is. There's already a lot of developers using TanStack Router just by itself for client-rendered apps. But the real fun starts when we bring in the server. So to go full stack, TanStack Start needed to support extremely simple server-side rendering, which is no easy feat. But this essentially means we needed to be able to hoist render-critical data outside of React and into the router. We took inspiration from Remix.

Let's hear it for Remix. We built a high-performance loader API, very similar, right into the router, which allows you to ensure that data is ready, or at least getting ready, before any code from React is ever executed. In TanStack Router, however, loaders are isomorphic. They run on both the server during SSR and on the client before each navigation. They can prime caches, fetch assets, and even return their own data, which is then serialized to the client during SSR and rehydrated with your app.

This loader pattern is fantastic, and I've enjoyed using it over the years through Remix. But on its own, I believe it comes with some major drawbacks. One of them is most obvious. Say you were to leave this page and come back later. Are you really going to make your users wait for that loader again? I sure hope you wouldn't. So to solve this problem, our router needs to start understanding more about our data, and primarily how to cache it. At this point, I hope you're thinking what I'm thinking. Well, that sounds like a perfect job for TanStack Query. Woo! No. It would be great, and it will be. Just wait, though. Because normally, you would be right. It just felt wrong, though, to force you to use TanStack Query if you wanted to use Start, even though it's great. It also didn't feel right leaving TanStack Router in the dust on caching. If something simpler can do the trick, why not? So I did something really cool. I built a miniature version of TanStack Query right into the router. That's very cool. It's 5% of the size actually, and it's 5% the size of React Query. It's got built-in caching that's keyed on a combination of the path name and selected search parameters just like a query key. And with this tiny addition, the router now all on its own supports stale while we validate patterns, persistent pre-loading, granular validation, which means for your users, again, you'll have instant navigation, very few spinners, if any at all, and potentially even less bandwidth, depending on how you configure it.

So where does that leave TanStack Query? What if you want to use it? Well, we did more cool stuff. If you add TanStack Query, you'll get things like the polling, the infinite queries, offline support, optimistic updates, just naturally by using TanStack Query. It's great. But what I'm really excited about is how the UseSuspenseQuery integrates with router magically. It gives you isomorphic data fetching with a single hook.

What does that mean? So during SSR, UseSuspenseQuery can request data. And if it's not ready, it'll suspend so that React can render the rest of our app, send it to the client. And when the query resolves that data on the server, it will stream that data and the remaining HTML to the client. Pretty simple. You can do all of that with just this one hassle-free hook.

So that's great. And you can do that in other frameworks. But once it gets to the client, it picks right back up. And now you already have the best-in-class client-side data synchronization engine with one single primitive. It's very flexible and powerful.

So what about critical data? You need your data, and you don't want to wait for it to stream down. You just need it there right now. How do we get into the initial response? Well, we can wait for the query data in our loader. And we can use it in a UseQuery, and the data will automatically be sent to the client. You don't have to deserialize and serialize or transfer anything for you. It just happens automatically. Or you can do the same thing without ReactQuery using just the router, which is pretty cool.

You just await the data, use it right in your component. If you've used Remix, this probably feels pretty familiar. If you need to render as soon as possible and stream data down later, you can do that, too. So you can just remove the await from the loader, and the data will stream down when it's ready. And again, you can do this without ReactQuery, just using the router. Take the await out, use our little await component, or in React 19, use the use hook, and it'll work exactly the same.

Oh, but Tanner, what if I don't want to hoist my data into the loader? Yeah, some of us still don't want to do that. That's fine. So to get fully dynamic streaming, you can just use SuspenseQuery. You don't need to hoist anything. That's all you need. And the data will be fetched as soon as possible on the server. It'll get automatically streamed down to the client when it's ready, and you don't have to configure anything.

And nothing has changed if you want to use client-only data fetching. Just use query like you've been doing. So I hope by now you're thinking, start looks pretty good. Does it look pretty good? All right.

So what's crazy is that we've only talked about router and query. I haven't even started talking about start. Which really speaks to the power of these primitives. Don't worry. Christmas is coming early. Let's finally talk about Tansec Start.

So now that we've learned that start is basically 90% Tansec router and some optional Tansec query, the only thing left is to talk about the server. I know you've missed talking about it. It's here. You don't need to have any withdrawals, OK?

So Tansec Start's server side features are built on top of Benchy, a full stack framework toolkit that is based on Nitro, a universally deployable server toolkit based on Vite, the inevitable awesome bundler and dev server. These tools are amazing in their own right. But together, they grant Tansec Start some really cool superpowers.

The first one is, oh, I forgot that. The first one is server-side rendering. All it takes is a tiny SSR entry file to route the request to the router and then a tiny client entry to handle hydration. With those two changes, you're already geared up for streaming, bundling, and deployment to any provider, all thanks to Benchy, Nitro, and Vite. That's pretty sweet.

So now that we have a server, we can finally do the fun stuff. We can get into really cool fun server-side patterns like API routes. Everybody's like, I want API routes. Please give them to me. We got them. It comes with them out of the box. You can even use a handy file-based API route utility or you can bring your own. You can use tools like tRPC, Hano, Express, whatever. Anything that you want to handle requests with, you can use.

That's really great. Again, if we stopped here, it'd be pretty great, but we couldn't help ourselves, so I added server functions. And I know some of the React core team is here. So we'll just call them server RPC functions. Thanks, React, for stealing that term. But createServerFunction is the primitive that we've added to start to build server-side functionality. Now, using this primitive, we can write server-side code anywhere we want in our application and get back a server function. We can call this function from anywhere we want in our entire codebase. It has nothing to do with the router, nothing to do with query, none of it. It just, you can call it anywhere. And it's just an asynchronous function. You can even define input validation that works on both the server and, optionally, the client, and conveniently makes the entire API fully type-safe.

So what would server functions and server functionality be without middleware? You can use the createMiddleware function to create composable middleware for your server functions. You can use them to authenticate users or perform logging or even just share common code between multiple server functions, or even between other middlewares as well. So one of the best parts of this middleware is it's really powerful context system. So just like the router, you can extend any middleware context with additional data. And it's fully type-safe and inferred for any other middleware or server function that consumes it. And on top of that, we also decided to include context serialization that can go from the client to the server and from the server back to the client, all still fully inferred. And this is going to unlock some really cool stuff. The server function API and the middleware API alone, we are already cooking up some really deep integrations and really cool things that we can do with these. And they're not ready to show you yet. But hopefully we'll have them ready by 1.0.

Until then, you'll have to enjoy some of the other great things that we get with Start for free, like full control over web requests and responses. Anything you can do with H3 and Nitro and Vinci, you can do in 10-Stack Start. You'll also have the ability to do streaming. I think we saw Jack Harrington show off some streaming earlier with 10-Stack Start. We get WebSockets and other real-time primitives. Static pre-rendering. We can do some really fun stuff, because it's all Nitro and Vite and Vinci under the hood. So anything you can do with those, you can do with this.

We're really just getting started. Dad joke. One last thing I know everybody is wondering. Will 10-Stack Start support RSCs? It's not ready for primetime yet. I'm not going to give you a demo that would just not do it justice. But I will talk about it. We found out it's going to be as easy as returning React elements or JSX from a server function. That's it. We already gave you the API for server functions. All you have to do is return React stuff and we'll handle the rest for you. Is that cool? I think that's pretty cool. Which means you'll be able to use them in your loaders. You can use them during SSR. You'll be able to use them in useQuery. Or pretty much anywhere. You could call a server function from anywhere that you want. Because RSCs are really just streams of text. And these streams of text represent server state. And if you've ever heard me talk about server state, you know exactly where I'm going with this. I don't have time to get into this right now. But RSCs are coming soon. You can expect some cool new features that I think will make them even more flexible and manageable than you've seen thus far.

One more, one more last thing. The last six months have been crazy. I went full-time on 10stack six months ago to date. Which is really humbling and amazing that I've been able to do that. And it's been an alpha since then. But I think it's finally time to announce it. As of, like, right before I came on stage. It's now in beta. So... Thanks. Please, go try it. It'll have some rough edges. But we need your help to polish those up and get to 1.0. I'm really excited about the future. I wanted to thank a lot of people. But Vercel, Clerc, AGgrid, they're here. Convex, CenturyUI.dev, Nozzle. These are companies that deeply care about open source and the future of the web. And it's been amazing to work with them to be a part of that future. So I want to thank them and these little GitHub sponsors, and all of you, for being a great audience. Thanks.

Ooh, this is an interesting one. Oh, crap. Are server function route paths deterministic? How do you handle API drift and observability on them? That's not one question.

Okay. What was the first one? Are server function route paths deterministic? No. But we have some early discussions right now of the ability to simply supply a static path to a server function. And it will just become public. Which is really cool. It's kind of like a replacement for API routes, if you think about it. But we're still experimenting with that. Don't hold me to it. That is really cool.

The second part of this was, how do you handle API drift and observability on the function route paths? I've seen a lot of different ways on handling API drift. I want to support some of the more naive ones where it's like, oh, something went wrong, so we're just going to reload and recover and do what we can on the client, between the client and server. But I also want to support some of the more sophisticated ones. Features like Vercel has one that you can send headers with requests and it will make sure that it's deterministically going to the right version of the server function that you deployed. So there's a lot of different approaches and we want to make sure that we can support them all. Cool.

This is by far the most asked question. The top two are variations of what did you use for this presentation? It is beautiful. Keynote. Keynote. All right. Great. Back to the actual content. What are the limitations of using state management in the URL? There is a point where you can break the URL. We had people spam the URL like 60 frames per second, trying to update values. I even added logic to batch requests into the URL, because Safari is much more sensitive to this than others. You also can run into serialization issues. You have to store things that are relatively simple to serialize into the URL.

If you store too much in the URL, you could have truncated URLs. We've really pushed the limits on that with Nozzle, sharing dashboard URLs with eight widgets. The dashboard has its own controls that are all being synced up into the URL. The URL is this long. It depends where you send that URL. Some servers can handle it, some can't. Just be aware of truncation. That's more of a limit of systems and browsers and not the router.

Can you read headers and cookies on the server in start parentheses, unlike next parentheses? How is TanStackQuery different from RTKQuery? TanStackQuery, RTKQuery, I don't know. One of them is not based on Redux. I don't know how to best answer that question. Just that's how they're different. That is a pretty big difference.

When are we getting TanStackStop? You need to retire soon, man. Never stop stopping. How do you handle state type validation in the URL? You can handle it kind of however you want. It's pluggable. We're also working on a new validation standard, so a lot of the validation libraries are adopting a new standard where you don't need to use an adapter, so you can pass any kind of validator you want to a route, and it could be a Zod schema that says, the search parameters need to look like this. Or it could be YUP, or it could be Valobot, or Archetype, or whatever. And it even supports setting defaults and filling in empty values if necessary. We have built a very flexible system to support as many validators as we can.

OK. Back to the content. How do you handle state type validation in the URL? State type validation in the URL. You can handle it kind of however you want. It's pluggable. We're also working on a new validation standard, so a lot of the validation libraries are adopting a new standard where you don't need to use an adapter, so you can pass any kind of validator you want to a route, and it could be a Zod schema that says, the search parameters need to look like this. Or it could be YUP, or it could be Valobot, or Archetype, or whatever. And it even supports setting defaults and filling in empty values if necessary. We have built a very flexible system to support as many validators as we can.

Nice. This is the last question on the list, so everyone, now is a great time to get your question in next. If my understanding of correct RSC implementation of TanStack will have capability to render only parts of UI in a route instead of re-rendering the full page, is that accurate? Correct. I don't plan on building an RSC-first router. Please don't make me do that. We'll keep that in mind. How do you handle hijacking of state in the URL? First of all, you validate it. There are modes that you can give to your validators to throw out bad state. And ultimately, you handle it like any other user input. If you send it to the server, you should be validating it on the server for strictly only what you need and being very careful about injection. It's just another input box on the browser window.

That's fair. For the business use case, which businesses should use TanStack Start and which shouldn't? I don't know. If you're building a React app, you should probably use Start. At least router. That's a lot of businesses. Well, yeah. Great. This one is not a question. It's a life saver. Plus one.

Great. Back to the content. Can TanStack Router work in React Native with deep linking? We're working on it. TanStack Router, I initially wrote it to be agnostic. Much of the core has nothing to do with React. But I decided to pull it all together and just ship it in React first to get a product out and test the concept. As soon as we get 1.0 of Start out, I plan on investigating an adapter-based strategy to the router. I know it would be very simple for us to support React Native, definitely, and Solid as well. The other ones, I'm not so sure. We're working on other features in the router very soon that are going to help us have feature parity with some of the other native routers that you might expect if you use them.

This is a question for me then. Do you see a world where each part of it, say the UI, is plug and playable? You could swap out React, Solid, and so on? Absolutely. That's really exciting. Yeah. What is the story behind the name TanStack? Well, I know everybody thinks that I'm just some egocentric maniac. But the real story is that Sean Wang, or Swix, if you know him by Swix, he kept calling me TanStack at React Rally like 6 years ago. He wouldn't stop. He was teasing me a lot. And I said, hey, I have a problem, because React Query is no longer going to be just React and I don't want to brand myself across all these different framework names. So I need a business name. And he's like, well, you should use TanStack. And I resented him for that at first until I googled it. Zero SEO competition. And really great brand recognition. You can spell it first try. And it's got three initials, three letters of my name in there. I built it. I can put that in there if I want. But that's kind of how it came to be. I just leaned into it.

No one's mispronouncing it. Yeah. Alright. So can I have confidence to build on TanStack Start and that it will be around in a few years? Yeah. I went full time on this because it's long term for me. I don't plan on going anywhere. So I'm going to be working on this for quite a long time.

It's in beta now, which I think denotes that we don't plan on breaking anything anymore. Should you use it in production? I mean, there are already people using it in production. Just lock it down to December so it doesn't automatically upgrade. And be prepared for having to migrate through some rough edges. If you don't want to do any of that, then just wait for it to be 1.0. But we've been shipping TanStack.com in TanStack Start for the last nine months. Which is pretty cool. That's very impressive.

Last question. Is TanStack open source? Yep. That was a very resounding yes. Thank you so much for the great Q&A, everyone, and of course, Tanner, aka TanStack, thank you so much. This was fantastic. One more round of applause, everyone.