Exploring TanStack Ecosystem: From React Query to TanStack Start
Subtitles
Show
I got into open source software because I was like, whoa, this is software that people are putting out for free that I can use for free that's legal to use for free.
I was like, what a great replacement for this terrible pirate culture.
Just calling it server state or client state instead of global state for some reason clicked for everyone.
Tanstack start gives you a couple of things that you don't get with router.
You already have loaders and you know life cycle events and things with router but the problem is everything happens client side.
So what Tanstack start does is gives you server side control and server side utilities.
Now there really isn't anything you can't do with tanstack router and start that we would be missing from something like Nex.
js or Remix or React Router 7.
Are you a client site hero that React needs right now?
No.
That's all I want to do is I have applications that just don't need to have this server first [Music] mentality.
React Universe on Air, your go-to podcast for all things crossplatform.
Hey everyone and welcome to React Universe on Air.
Today I'm really excited to have Tanner Linsley with me from Tanstack.
Obviously uh me and Taran Tanner we met on uh React Summit New York couple of months ago and Tanner you had a talk about uh Tanstack start framework.
Do you remember that?
Vaguely.
Okay.
So since then since then you had a bunch of other talks and podcasts explaining Tangst start and like its role in the in the community.
So I would love to talk about that definitely but really there has been so much material about this.
I want to take a different uh approach here and maybe discuss the Tanstack ecosystem because I can see that you have a bunch of libraries and you have a bunch of stories to tell.
Uh so maybe let's let's
I was like, what a great replacement for this terrible pirate culture.
Just calling it server state or client state instead of global state for some reason clicked for everyone.
Tanstack start gives you a couple of things that you don't get with router.
You already have loaders and you know life cycle events and things with router but the problem is everything happens client side.
So what Tanstack start does is gives you server side control and server side utilities.
Now there really isn't anything you can't do with tanstack router and start that we would be missing from something like Nex.
js or Remix or React Router 7.
Are you a client site hero that React needs right now?
No.
That's all I want to do is I have applications that just don't need to have this server first [Music] mentality.
React Universe on Air, your go-to podcast for all things crossplatform.
Hey everyone and welcome to React Universe on Air.
Today I'm really excited to have Tanner Linsley with me from Tanstack.
Obviously uh me and Taran Tanner we met on uh React Summit New York couple of months ago and Tanner you had a talk about uh Tanstack start framework.
Do you remember that?
Vaguely.
Okay.
So since then since then you had a bunch of other talks and podcasts explaining Tangst start and like its role in the in the community.
So I would love to talk about that definitely but really there has been so much material about this.
I want to take a different uh approach here and maybe discuss the Tanstack ecosystem because I can see that you have a bunch of libraries and you have a bunch of stories to tell.
Uh so maybe let's let's
start there.
Can you please introduce yourself and let us know how you got into programming in the first place?
So my name is Tanner Lindley.
I let's see how I got into programming in high school.
I took a web class that was, you know, HTML and very very fresh off the press.
New CSS stuff, which was it was all the rage, right?
So CSS was getting hot.
JavaScript was still very young.
And I I liked that class, but I didn't I didn't think anything of that class when I took it.
I was just like, "Oh, this is neat.
I seemed to be good at it, but I didn't think this is going to be my career.
So, I actually went on to study film and audio engineering for quite a while because I had it in my head that I was going to be a film editor, uh, producer.
I was going to work for um I wanted to work for like uh pro like pro alete videography companies like Red Bull and stuff like that and uh you know go snowboarding and film and that kind of thing that uh ended up not being as glamorous as I thought it was going to be.
And um I eventually got into audio engineering because who doesn't love music?
Uh I was also very musical.
I I played many instruments um growing up.
I even wrote some songs, some music that's all terrible, but it was super fun.
And uh ended up going to school for another three years for audio engineering.
Um and while I was doing that, I started running out of money for school.
Um I was working for an Apple retailer doing like Genius Bar work and it just wasn't enough.
So on the side I started building websites.
What year was that?
Let's see that was 2011 20 early 2012 that I started I started getting into that.
I needed more money.
So I was building websites on the side to make more money.
So no React yet definitely.
So probably some jQuery there.
Oh yeah, loads of jQuery.
Um I
Can you please introduce yourself and let us know how you got into programming in the first place?
So my name is Tanner Lindley.
I let's see how I got into programming in high school.
I took a web class that was, you know, HTML and very very fresh off the press.
New CSS stuff, which was it was all the rage, right?
So CSS was getting hot.
JavaScript was still very young.
And I I liked that class, but I didn't I didn't think anything of that class when I took it.
I was just like, "Oh, this is neat.
I seemed to be good at it, but I didn't think this is going to be my career.
So, I actually went on to study film and audio engineering for quite a while because I had it in my head that I was going to be a film editor, uh, producer.
I was going to work for um I wanted to work for like uh pro like pro alete videography companies like Red Bull and stuff like that and uh you know go snowboarding and film and that kind of thing that uh ended up not being as glamorous as I thought it was going to be.
And um I eventually got into audio engineering because who doesn't love music?
Uh I was also very musical.
I I played many instruments um growing up.
I even wrote some songs, some music that's all terrible, but it was super fun.
And uh ended up going to school for another three years for audio engineering.
Um and while I was doing that, I started running out of money for school.
Um I was working for an Apple retailer doing like Genius Bar work and it just wasn't enough.
So on the side I started building websites.
What year was that?
Let's see that was 2011 20 early 2012 that I started I started getting into that.
I needed more money.
So I was building websites on the side to make more money.
So no React yet definitely.
So probably some jQuery there.
Oh yeah, loads of jQuery.
Um I
was still going to school.
I remember um it's actually funny.
I think at the time a lot of like the people that I looked up to in like the JavaScript ecosystem were working at um in structure and building instructure which is like this educational platform and I remember thinking they're building this platform you know I probably with a framework and here I am in class using jQuery to like try and automate it and make my work go faster at school and like kind of not h you know not hacking but just dinking around in the console with jQuery.
on on this educational platform.
So that's kind of where I started getting into JavaScript.
I did a lot of WordPress.
So I actually got a job doing full-time WordPress and then over the course of about two years, the VP of tech left that company and I was promoted to VP of tech, which was scary.
That's when I decided that I didn't want to dive too much deeper into PHP.
like I I had gotten my hands dirty and with tons of PHP and and MySQL and WordPress plugins and Woo Commerce, I just didn't want to do that anymore.
I wanted to build apps like either web apps or native apps.
So, my first foray into like JavaScript for real was probably Ionic.
Ionic and I I wasn't expecting to find any like crossplatform mobile technologies in your resume.
Yeah.
So I actually learned Ioni and Angular like before I learned JavaScript for real.
I mean, I I knew PHP and I dabbled in some other programming languages before, so picking up JavaScript was not super difficult, but JavaScript frameworks and the JavaScript ecosystem are very different.
So, it it took a little bit, but I wanted to build an application for like iOS.
If I can like jump in and ask you about that early early experiences with software development with lots of different tools and ideas, do you feel
I remember um it's actually funny.
I think at the time a lot of like the people that I looked up to in like the JavaScript ecosystem were working at um in structure and building instructure which is like this educational platform and I remember thinking they're building this platform you know I probably with a framework and here I am in class using jQuery to like try and automate it and make my work go faster at school and like kind of not h you know not hacking but just dinking around in the console with jQuery.
on on this educational platform.
So that's kind of where I started getting into JavaScript.
I did a lot of WordPress.
So I actually got a job doing full-time WordPress and then over the course of about two years, the VP of tech left that company and I was promoted to VP of tech, which was scary.
That's when I decided that I didn't want to dive too much deeper into PHP.
like I I had gotten my hands dirty and with tons of PHP and and MySQL and WordPress plugins and Woo Commerce, I just didn't want to do that anymore.
I wanted to build apps like either web apps or native apps.
So, my first foray into like JavaScript for real was probably Ionic.
Ionic and I I wasn't expecting to find any like crossplatform mobile technologies in your resume.
Yeah.
So I actually learned Ioni and Angular like before I learned JavaScript for real.
I mean, I I knew PHP and I dabbled in some other programming languages before, so picking up JavaScript was not super difficult, but JavaScript frameworks and the JavaScript ecosystem are very different.
So, it it took a little bit, but I wanted to build an application for like iOS.
If I can like jump in and ask you about that early early experiences with software development with lots of different tools and ideas, do you feel
that that experience from 15 years ago or something helped you build all of those nice tools in like 2019, 2020, 2022 or something?
Oh yeah, absolutely.
Like even when I was doing WordPress, I was getting really into open- source software.
So, actually, here's some more backstory.
I used to be like a pirate.
I loved downloading movies, music, and all sorts of stuff.
And I mean, this is a long time ago.
I was naive and young and and I was still like I could convince myself that it was okay to do that.
But after I mean, when I when I grew up um and I realized, hey, this is this is wrong.
like I shouldn't be doing this.
I had to like stop doing that cold turkey.
And so all this software and all this stuff that I, you know, was getting for free, like basically illegally when I was like 16 years old, you know, I deleted all that stuff from my youth and just, you know, decided to true up.
And um part of that was I got into open- source software because I was like, whoa, this is software that people are putting out for free that I can use for free that's legal to use for free.
I was like, what an what a great replacement for this terrible pirate culture.
You know, it sounds so terrible to say that on air, actually.
People are going to be like, damn, there's like an evil dude.
I'm going to use that in our episode like trailer or something.
Definitely.
Yeah, I mean it wasn't difficult to stop um doing that.
And I I think I stopped pirating stuff when I was like 17 years old.
So it was a long time ago, but that that drive for free software was still there.
You know, I also feel like nowadays we take for granted how much free software we actually have right now and we don't have to pirate or sorry, we don't have to buy.
We we get it for free.
Like even the the professional software for like photo editing and
Oh yeah, absolutely.
Like even when I was doing WordPress, I was getting really into open- source software.
So, actually, here's some more backstory.
I used to be like a pirate.
I loved downloading movies, music, and all sorts of stuff.
And I mean, this is a long time ago.
I was naive and young and and I was still like I could convince myself that it was okay to do that.
But after I mean, when I when I grew up um and I realized, hey, this is this is wrong.
like I shouldn't be doing this.
I had to like stop doing that cold turkey.
And so all this software and all this stuff that I, you know, was getting for free, like basically illegally when I was like 16 years old, you know, I deleted all that stuff from my youth and just, you know, decided to true up.
And um part of that was I got into open- source software because I was like, whoa, this is software that people are putting out for free that I can use for free that's legal to use for free.
I was like, what an what a great replacement for this terrible pirate culture.
You know, it sounds so terrible to say that on air, actually.
People are going to be like, damn, there's like an evil dude.
I'm going to use that in our episode like trailer or something.
Definitely.
Yeah, I mean it wasn't difficult to stop um doing that.
And I I think I stopped pirating stuff when I was like 17 years old.
So it was a long time ago, but that that drive for free software was still there.
You know, I also feel like nowadays we take for granted how much free software we actually have right now and we don't have to pirate or sorry, we don't have to buy.
We we get it for free.
Like even the the professional software for like photo editing and
video editing and like OBS for for streaming, we get all of that from open source for free.
We don't have to pay for that.
It wasn't it wasn't like that 15 years ago.
No way.
It was it was very like at the best case scenario it was like very premium sharewware type stuff where you know you'd get to use like this much of it and then you'd get roped into upgrading or paying some crazy amount.
It's so much easier today to to do stuff especially with open source.
So that's probably one of the the really core Freudian reasons that I like got obsessed with open source in the beginning.
Well, researching you before this episode, before this recording, I've noted somewhere that you worked on ChartJS and that was like a turning point for you when you like fall fell in love with open source.
Can you talk about that?
Yeah, I actually had forgotten about that a little bit.
So, um You're welcome.
Yeah, so I uh started a company with some friends shortly after that in like 2013.
Uh it's called Nozzle.
Nozzle.
io.
It's still going today.
It's awesome.
This uh SEO marketing analytical platform.
Very powerful, very cool.
And when we started building that, we needed charting, lots of lots of charts and dashboards.
So, I started looking around and and the best library I found was chart.
js, uh which at the time was 1.
0.
It wasn't fresh, but it had been out for a little while.
and Nick, I can't remember his last name, but his GitHub handle is like nnk.
Nick had built chartjs and then I think he got burned out and just totally left open source for a long time.
Maybe still has gone.
I'm not sure.
So, I was using ChartJS at Nozzle and I loved it, but I was bumping up against limitations, performance concerns, animation, like lack of animation for
We don't have to pay for that.
It wasn't it wasn't like that 15 years ago.
No way.
It was it was very like at the best case scenario it was like very premium sharewware type stuff where you know you'd get to use like this much of it and then you'd get roped into upgrading or paying some crazy amount.
It's so much easier today to to do stuff especially with open source.
So that's probably one of the the really core Freudian reasons that I like got obsessed with open source in the beginning.
Well, researching you before this episode, before this recording, I've noted somewhere that you worked on ChartJS and that was like a turning point for you when you like fall fell in love with open source.
Can you talk about that?
Yeah, I actually had forgotten about that a little bit.
So, um You're welcome.
Yeah, so I uh started a company with some friends shortly after that in like 2013.
Uh it's called Nozzle.
Nozzle.
io.
It's still going today.
It's awesome.
This uh SEO marketing analytical platform.
Very powerful, very cool.
And when we started building that, we needed charting, lots of lots of charts and dashboards.
So, I started looking around and and the best library I found was chart.
js, uh which at the time was 1.
0.
It wasn't fresh, but it had been out for a little while.
and Nick, I can't remember his last name, but his GitHub handle is like nnk.
Nick had built chartjs and then I think he got burned out and just totally left open source for a long time.
Maybe still has gone.
I'm not sure.
So, I was using ChartJS at Nozzle and I loved it, but I was bumping up against limitations, performance concerns, animation, like lack of animation for
things.
We needed to do just more.
And I was like, "Hey, I I think I could, you know, hack some of this together.
" And so, I remember getting on the GitHub uh issues, which was the best place that we had at the time to talk about anything.
And I was like, "Hey, I'm willing to like take this project over and take it to the next level, but I don't I don't even know where this guy Nick is.
" And another guy I met, uh, Ever Timberg, he was kind of looking to do the same thing even more.
And Ever and I teamed up and found Nick some somewhere like through email or something like that.
And we're like, "Hey, we want to take this to the next level.
" And he's like, "Sure, here's publish keys.
Here's GitHub rights.
Go for it.
Sorry, I I I just need to interrupt here.
What a crazy story when you have the library chart.
js and you think, "Oh, I can hack around it.
I I can I can maybe do some improvements and then you go, okay, so I want to take over this library.
" I mean, we we didn't want to take it over.
We wanted Nick to do it.
We wanted Nick to upgrade to all his stuff.
And he basically was like, "No, I don't have time.
I don't want to do it.
Uh, if you guys want to do it, let me know.
" and we were like, "Whoa, okay.
" And me and Ever hadn't really done anything like that before.
So, we teamed up and just started building Chart.
js 2.
0.
I can't remember exactly what we built cuz it's been a long time, but I know we rebuilt the animation, like all of the animation framework inside of it.
We redid a bunch of the layering for like all the different canvas layerings.
We did a lot of stuff.
And it was when we launched 2.
0 0 it was a big deal.
It kind of paved the way for char.
js to explode even more.
I think even in that first open big open source experience that you have and it's going to come up
We needed to do just more.
And I was like, "Hey, I I think I could, you know, hack some of this together.
" And so, I remember getting on the GitHub uh issues, which was the best place that we had at the time to talk about anything.
And I was like, "Hey, I'm willing to like take this project over and take it to the next level, but I don't I don't even know where this guy Nick is.
" And another guy I met, uh, Ever Timberg, he was kind of looking to do the same thing even more.
And Ever and I teamed up and found Nick some somewhere like through email or something like that.
And we're like, "Hey, we want to take this to the next level.
" And he's like, "Sure, here's publish keys.
Here's GitHub rights.
Go for it.
Sorry, I I I just need to interrupt here.
What a crazy story when you have the library chart.
js and you think, "Oh, I can hack around it.
I I can I can maybe do some improvements and then you go, okay, so I want to take over this library.
" I mean, we we didn't want to take it over.
We wanted Nick to do it.
We wanted Nick to upgrade to all his stuff.
And he basically was like, "No, I don't have time.
I don't want to do it.
Uh, if you guys want to do it, let me know.
" and we were like, "Whoa, okay.
" And me and Ever hadn't really done anything like that before.
So, we teamed up and just started building Chart.
js 2.
0.
I can't remember exactly what we built cuz it's been a long time, but I know we rebuilt the animation, like all of the animation framework inside of it.
We redid a bunch of the layering for like all the different canvas layerings.
We did a lot of stuff.
And it was when we launched 2.
0 0 it was a big deal.
It kind of paved the way for char.
js to explode even more.
I think even in that first open big open source experience that you have and it's going to come up
in the future work as well.
I think what's stands out to me is that you have a project that needs that functionality.
So we you build that functionality in the open in the open source and that's like a feedback loop that you get that you can try it out on your own project that's that's quite big already but also you get those like use cases you get the use cases for the library you get the new ideas and new stuff that you want to implement there because your product needs that functionality I think that's that's pretty important when you start working in open source you don't build just for the sake of building it.
You build it because you have a need for it.
Yeah, there's a big need for it.
And also, it's like if I'm going to build it anyway, it would be really cool if I could build it in a way that just works for 90% of the other, you know, everybody else using it as well.
So, yeah, that's I think that's a really important feedback loop because it's fun.
It's fun to do that.
And that's one of the reasons that it's kind of like owning a business and having customers without having to go through all of the hassle of owning a real business and having real customers.
You get to build a product, ship it to users, get fast feedback, and you you get that kind of rush fulfilling a need for people and making it better over time over and over.
So after that chartjs first introduction to open source I think what happened there because I read a bunch about you and about your companies is that at nozzle you had a need for react query.
What was the use case that you were trying to solve at nozzle at that time?
not as the uh very high-minded idea behind the react query but like the simplest use case that you encountered one day and said okay I think this library might be helpful in solving that
I think what's stands out to me is that you have a project that needs that functionality.
So we you build that functionality in the open in the open source and that's like a feedback loop that you get that you can try it out on your own project that's that's quite big already but also you get those like use cases you get the use cases for the library you get the new ideas and new stuff that you want to implement there because your product needs that functionality I think that's that's pretty important when you start working in open source you don't build just for the sake of building it.
You build it because you have a need for it.
Yeah, there's a big need for it.
And also, it's like if I'm going to build it anyway, it would be really cool if I could build it in a way that just works for 90% of the other, you know, everybody else using it as well.
So, yeah, that's I think that's a really important feedback loop because it's fun.
It's fun to do that.
And that's one of the reasons that it's kind of like owning a business and having customers without having to go through all of the hassle of owning a real business and having real customers.
You get to build a product, ship it to users, get fast feedback, and you you get that kind of rush fulfilling a need for people and making it better over time over and over.
So after that chartjs first introduction to open source I think what happened there because I read a bunch about you and about your companies is that at nozzle you had a need for react query.
What was the use case that you were trying to solve at nozzle at that time?
not as the uh very high-minded idea behind the react query but like the simplest use case that you encountered one day and said okay I think this library might be helpful in solving that
believe it or not query was not the first one that I needed at nozzle okay what was that it was actually react table okay yeah so the table scene was very similar to the chart scene there were a couple of libraries that were okay.
AG grid was there.
It was very new though and it was only for Angular and we had we had already moved to React.
We were using a a tool called NG Grid in Angular and then we moved to React and there was nothing there.
Ag Grid had started to work on their you know React support but it was still young.
It wasn't ready.
I just needed something that worked at all.
So I just threw together this table component like overnight and started using it in internally in nozzle and it was just a it was a component and it was built 100% with React.
It was just like a bunch of class components thrown together into basically React table.
And that was that was a big undertaking because tables are crazy.
Data grids are nuts.
They you can do so many different things with them, go so many different directions.
That project got really popular.
The minute that I open sourced it, it got really popular and kind of exploded for a data grid, right?
And um that was kind of the first one that I was like, if I'm going to build this for nozzle and and I used it and I loved it, then why wouldn't I just give it away for free?
Because it's front end, it's JavaScript, it's client side code.
like there's there's not a lot of like intellectual property protection needed for something like that.
People are going to use it.
Developers are going to find it.
They're going to reverse engineer it and if if my solution isn't the open source one, there will be one there anyway.
Yeah, it was really successful and uh that was kind of my first library that that took off.
After that, I thought, well, I
AG grid was there.
It was very new though and it was only for Angular and we had we had already moved to React.
We were using a a tool called NG Grid in Angular and then we moved to React and there was nothing there.
Ag Grid had started to work on their you know React support but it was still young.
It wasn't ready.
I just needed something that worked at all.
So I just threw together this table component like overnight and started using it in internally in nozzle and it was just a it was a component and it was built 100% with React.
It was just like a bunch of class components thrown together into basically React table.
And that was that was a big undertaking because tables are crazy.
Data grids are nuts.
They you can do so many different things with them, go so many different directions.
That project got really popular.
The minute that I open sourced it, it got really popular and kind of exploded for a data grid, right?
And um that was kind of the first one that I was like, if I'm going to build this for nozzle and and I used it and I loved it, then why wouldn't I just give it away for free?
Because it's front end, it's JavaScript, it's client side code.
like there's there's not a lot of like intellectual property protection needed for something like that.
People are going to use it.
Developers are going to find it.
They're going to reverse engineer it and if if my solution isn't the open source one, there will be one there anyway.
Yeah, it was really successful and uh that was kind of my first library that that took off.
After that, I thought, well, I
really like this uh library thing.
And I I saw um I had been you know this was in the era of like Hugo was really big which is a static site generator.
Kyle Matthews was building Gatsby.
Nex.
js was a static like doing static site generation stuff.
I was really into that and we needed to build our marketing site for Nozzle and I was like hey what if we just use you know I'm the only front-end developer for our for our company or startup at the time.
So I was like, well, if I have to build this marketing site, it'd be really cool if I could just use React and use all the components that I built for the app for the marketing site, too.
So, let's do that.
And I couldn't find a good solution for that either.
And so I built a library called React static which for all intents and purposes was like it it was it was a it was the first framework that I ever built like the first front-end framework and it was a massive undertaking because frameworks are just really really difficult to do.
We don't have many guests on this podcast that that uh can say in the conversation that was my first framework that I ever built.
you know, it was h React static it was be it was a little bit ahead of its time just almost like Gatsby was ahead of its time a little bit and and Nex.
js like these frameworks they we we were struggling to like make sense of these new ideas we had but still using kind of these like you know the best tools we had at the time.
So you got to remember that we didn't have hooks yet.
We didn't have React hooks.
we didn't have a lot of great tools.
It was all still like CSS and JS was exploding and everybody was obsessed with that.
So, at the end of the day, um, React Static got pretty popular, too.
Like, when we launched it, it was it was pretty cool.
And honestly,
And I I saw um I had been you know this was in the era of like Hugo was really big which is a static site generator.
Kyle Matthews was building Gatsby.
Nex.
js was a static like doing static site generation stuff.
I was really into that and we needed to build our marketing site for Nozzle and I was like hey what if we just use you know I'm the only front-end developer for our for our company or startup at the time.
So I was like, well, if I have to build this marketing site, it'd be really cool if I could just use React and use all the components that I built for the app for the marketing site, too.
So, let's do that.
And I couldn't find a good solution for that either.
And so I built a library called React static which for all intents and purposes was like it it was it was a it was the first framework that I ever built like the first front-end framework and it was a massive undertaking because frameworks are just really really difficult to do.
We don't have many guests on this podcast that that uh can say in the conversation that was my first framework that I ever built.
you know, it was h React static it was be it was a little bit ahead of its time just almost like Gatsby was ahead of its time a little bit and and Nex.
js like these frameworks they we we were struggling to like make sense of these new ideas we had but still using kind of these like you know the best tools we had at the time.
So you got to remember that we didn't have hooks yet.
We didn't have React hooks.
we didn't have a lot of great tools.
It was all still like CSS and JS was exploding and everybody was obsessed with that.
So, at the end of the day, um, React Static got pretty popular, too.
Like, when we launched it, it was it was pretty cool.
And honestly,
if I had stuck with it, React Static would have turned into something really really big.
We at the time we like when we were doing it actively, we were the fastest static site generator for React on the market.
We were beating out Gatsby compile times, Nex.
js compile times.
I'm glad that I didn't go down that route because just like Gatsby, we would have I would have needed to basically turn it into my full-time job, create a cloud platform, you know, or eventually get into like server side rendering.
Yeah, probably.
I was I was thinking in terms of there are no meaningful right now static site generators can't do just static.
If you wanted to turn that into like a proper framework you'd have to go to the route of Nex.
js which is like make it all you can do client side server side serverside components uh what else static all of that and and mix all of those together.
I think one of the missing pieces at the time was this was still before serverless had really taken off and not just serverless in general but servers being more accessible for front-end technology for JavaScript that hadn't really taken off yet.
um it was still in the early stages of that.
And so when we were thinking of static sites, you know, everything needs to start with a server and the best server we had was on our machines at build time.
We had CI, you know, we could do stuff in CI, but we just weren't thinking big enough, you know, and the technology around serverless stuff hadn't caught up yet and or just running JavaScript easily on the server in general.
as that started to catch up.
Well, before that happened, I got out of React Static.
I needed to focus on Nozzle.
So, I gave React Static away to um some people who were going to maintain it and continue working on it.
We at the time we like when we were doing it actively, we were the fastest static site generator for React on the market.
We were beating out Gatsby compile times, Nex.
js compile times.
I'm glad that I didn't go down that route because just like Gatsby, we would have I would have needed to basically turn it into my full-time job, create a cloud platform, you know, or eventually get into like server side rendering.
Yeah, probably.
I was I was thinking in terms of there are no meaningful right now static site generators can't do just static.
If you wanted to turn that into like a proper framework you'd have to go to the route of Nex.
js which is like make it all you can do client side server side serverside components uh what else static all of that and and mix all of those together.
I think one of the missing pieces at the time was this was still before serverless had really taken off and not just serverless in general but servers being more accessible for front-end technology for JavaScript that hadn't really taken off yet.
um it was still in the early stages of that.
And so when we were thinking of static sites, you know, everything needs to start with a server and the best server we had was on our machines at build time.
We had CI, you know, we could do stuff in CI, but we just weren't thinking big enough, you know, and the technology around serverless stuff hadn't caught up yet and or just running JavaScript easily on the server in general.
as that started to catch up.
Well, before that happened, I got out of React Static.
I needed to focus on Nozzle.
So, I gave React Static away to um some people who were going to maintain it and continue working on it.
And I went back to Nozzle because we were, you know, expanding, we were growing, we needed I just needed to focus my efforts there.
So that is about around the time when react query started to take shape inside of nozzle.
So going back to my initial question about react query probably you haven't started it with this like highle philosophical things thinking about server state and client state and synchronizing you had a real problem on your hands.
What was that problem that you were trying to solve?
The problem at the time was that we had all this data that we were fetching from the server, from our API, tons of it.
We had workspace data, user data teams projects keywords you know, groupings and like all the like columns, everything that we needed to make nozzle work was coming from this API.
And it was like it was a ton.
And it was like, you know, we had the schemas and and we even investigated using something like GraphQL to like bring all that back down, you know, and some of that led into like, well, maybe we should adopt Apollo.
And GraphQL when when we gave it a proof of concept, GraphQL was not the right tool.
Like we were a very small team.
It just put a lot of layers of indirection between us and just getting things done.
So what it really boiled down to was I needed a way to just basically synchronize all of this data down into our application and keep it up to date.
Like for lack of a better term, it's a sync engine that you kind of build yourself.
And that's what I needed.
At the time I was using Redux for that.
So I had Redux stores and subtores everywhere.
A substore for every well I think they call them slices.
there was a slice for every single concern of the API.
Um, and inside of there, I always found myself repeating over and over the same actions
So that is about around the time when react query started to take shape inside of nozzle.
So going back to my initial question about react query probably you haven't started it with this like highle philosophical things thinking about server state and client state and synchronizing you had a real problem on your hands.
What was that problem that you were trying to solve?
The problem at the time was that we had all this data that we were fetching from the server, from our API, tons of it.
We had workspace data, user data teams projects keywords you know, groupings and like all the like columns, everything that we needed to make nozzle work was coming from this API.
And it was like it was a ton.
And it was like, you know, we had the schemas and and we even investigated using something like GraphQL to like bring all that back down, you know, and some of that led into like, well, maybe we should adopt Apollo.
And GraphQL when when we gave it a proof of concept, GraphQL was not the right tool.
Like we were a very small team.
It just put a lot of layers of indirection between us and just getting things done.
So what it really boiled down to was I needed a way to just basically synchronize all of this data down into our application and keep it up to date.
Like for lack of a better term, it's a sync engine that you kind of build yourself.
And that's what I needed.
At the time I was using Redux for that.
So I had Redux stores and subtores everywhere.
A substore for every well I think they call them slices.
there was a slice for every single concern of the API.
Um, and inside of there, I always found myself repeating over and over the same actions
that was like refresh, refresh, synchronize, you know, and the the words started changing to just sync, like sync, sync, sync, just give me all of the new stuff.
And I would have to fire those actions off manually all the time.
And it got to the point where it wasn't up todate enough for the user to be like did my say, you know, where are my changes?
Am I seeing the latest stuff?
And then we had users start working on the same things at the same time.
You know, not not real time collaboration, but working in the same, you know, workspace or team.
And we there was there wasn't really a great way at the time for us to like channel that back down to the application without going really deep into websockets.
So I had this idea even before like just when we were using Redux I was like you know what every single time the user focuses the page or every single time that they navigate a page I'm just going to reync everything and that was really heavy and slow with what we had with Redux and it was very manual like I ended up building my own custom hooks.
So, React hooks came out and I built these hooks that's like anytime you wanted to use data out of Redux, you had to use my hook to get it so that I could get in the middle and say, "Oh, you're subscribing to users.
" Well, I'm going to make sure that every anytime we navigate, we're refetching users.
So, that's kind of where it started.
And from there, it just started to snowball.
Sorry to jump in, but like it's so fascinating to me when I when I hear you speak about this is how you're using the tool Redux and you basically implement your own system within Redux.
You implement your own I don't Yeah, you hack around it so that it does what you need it to do.
Yeah.
Well, and not not just hack around it, but essentially I I
And I would have to fire those actions off manually all the time.
And it got to the point where it wasn't up todate enough for the user to be like did my say, you know, where are my changes?
Am I seeing the latest stuff?
And then we had users start working on the same things at the same time.
You know, not not real time collaboration, but working in the same, you know, workspace or team.
And we there was there wasn't really a great way at the time for us to like channel that back down to the application without going really deep into websockets.
So I had this idea even before like just when we were using Redux I was like you know what every single time the user focuses the page or every single time that they navigate a page I'm just going to reync everything and that was really heavy and slow with what we had with Redux and it was very manual like I ended up building my own custom hooks.
So, React hooks came out and I built these hooks that's like anytime you wanted to use data out of Redux, you had to use my hook to get it so that I could get in the middle and say, "Oh, you're subscribing to users.
" Well, I'm going to make sure that every anytime we navigate, we're refetching users.
So, that's kind of where it started.
And from there, it just started to snowball.
Sorry to jump in, but like it's so fascinating to me when I when I hear you speak about this is how you're using the tool Redux and you basically implement your own system within Redux.
You implement your own I don't Yeah, you hack around it so that it does what you need it to do.
Yeah.
Well, and not not just hack around it, but essentially I I
put my own API in front of Redux.
Yeah.
Uh, and I started powering my own ideas with Redux until it got to the point where I was like, you know, would be really cool is if I could kind of break the rules of Redux a little bit and have this global store follow me around and just be able to kind of like store state there and mutate it and store timers in it.
Stuff that like Redux stores are supposed to be serializable and immutable and, you know, it no longer felt Redux.
And the the Redux was just a glue for you to like start it somewhere.
Yeah.
Yeah.
It just a detail.
And the minute that I started to rip Redux out and build what is today is the query client or like the query cache uh class instance.
That's really where React Query was kind of like born, right?
Is I was like, "Oh my goodness, I I'm writing my own Redux.
" And then I I sat there for a minute and I was like, "Wait, I'm writing my own state management software that's specifically designed for this task that I've been having a hard time with.
" And at the time I I was like, "Wow, there's other libraries that are trying to do this and they have some good ideas, but they haven't nailed all of them.
" If anybody remembers, this library didn't take off too much, but there was a library called uh Dracula.
Dracula.
I don't remember that.
So it was like Dracula but QL at the end, right?
And they they were supposed to be geared towards like GraphQL, but they had nailed some of these APIs like use query and use mutation.
And I liked that about the GraphQL ecosystem, the query, the mutation talk and kind of the life cycle around that.
So I took inspiration from Dracula or DraQL and that's where the first version of the API took place.
is use query, use mutation, but instead of being GraphQL, I just said, you know
Yeah.
Uh, and I started powering my own ideas with Redux until it got to the point where I was like, you know, would be really cool is if I could kind of break the rules of Redux a little bit and have this global store follow me around and just be able to kind of like store state there and mutate it and store timers in it.
Stuff that like Redux stores are supposed to be serializable and immutable and, you know, it no longer felt Redux.
And the the Redux was just a glue for you to like start it somewhere.
Yeah.
Yeah.
It just a detail.
And the minute that I started to rip Redux out and build what is today is the query client or like the query cache uh class instance.
That's really where React Query was kind of like born, right?
Is I was like, "Oh my goodness, I I'm writing my own Redux.
" And then I I sat there for a minute and I was like, "Wait, I'm writing my own state management software that's specifically designed for this task that I've been having a hard time with.
" And at the time I I was like, "Wow, there's other libraries that are trying to do this and they have some good ideas, but they haven't nailed all of them.
" If anybody remembers, this library didn't take off too much, but there was a library called uh Dracula.
Dracula.
I don't remember that.
So it was like Dracula but QL at the end, right?
And they they were supposed to be geared towards like GraphQL, but they had nailed some of these APIs like use query and use mutation.
And I liked that about the GraphQL ecosystem, the query, the mutation talk and kind of the life cycle around that.
So I took inspiration from Dracula or DraQL and that's where the first version of the API took place.
is use query, use mutation, but instead of being GraphQL, I just said, you know
what, let's support anything that's a promise and we'll call it a day.
And that's basically where it was born.
Thanks for that Dracula Dracul uh mention because like when I first so for your earlier open source work the chartjs react static and uh react table those were not like very original concepts right like the charts the tables you just build what you need the react query when I first saw it and how it's how it's uh perceived in the ecosystem as well is that this is something completely new.
This is an original thought that we and like I didn't know this Dracula but I thought this is an original thought.
This is something new.
This is a new paradigm.
It's not the just the state management.
This is something original.
So what was the work on it like?
What was the community reaction like?
how your life changed after that.
I had known from talking with other with other people who had built clients like Apollo and Dracula and Urkl came out a little bit after that and then also uh like when I launched actually SWR from Nex.
js launched like literally days after that.
We didn't even know we'd been working on the same thing.
So there was obviously something going on in the ecosystem driving everyone to want to kind of build this solution.
But what I found that is that when when I launched it and started marketing it to developers that hey this is going to solve your problems they a lot of them didn't even know they had this problem because it was being solved partially by tools that were great like Redux.
Redux is a is and was a great tool that was partially solving this problem.
And so it's difficult to convince people to to replace a tool that is great that is only partially solving a problem with a different tool.
It took a lot of education to to do that
And that's basically where it was born.
Thanks for that Dracula Dracul uh mention because like when I first so for your earlier open source work the chartjs react static and uh react table those were not like very original concepts right like the charts the tables you just build what you need the react query when I first saw it and how it's how it's uh perceived in the ecosystem as well is that this is something completely new.
This is an original thought that we and like I didn't know this Dracula but I thought this is an original thought.
This is something new.
This is a new paradigm.
It's not the just the state management.
This is something original.
So what was the work on it like?
What was the community reaction like?
how your life changed after that.
I had known from talking with other with other people who had built clients like Apollo and Dracula and Urkl came out a little bit after that and then also uh like when I launched actually SWR from Nex.
js launched like literally days after that.
We didn't even know we'd been working on the same thing.
So there was obviously something going on in the ecosystem driving everyone to want to kind of build this solution.
But what I found that is that when when I launched it and started marketing it to developers that hey this is going to solve your problems they a lot of them didn't even know they had this problem because it was being solved partially by tools that were great like Redux.
Redux is a is and was a great tool that was partially solving this problem.
And so it's difficult to convince people to to replace a tool that is great that is only partially solving a problem with a different tool.
It took a lot of education to to do that
which is where and I don't I don't know if I would maybe call this a skill that I have to some degree but finding a way to educate developers that feels innovative but isn't really something that's new that they have to learn just calling it server state or client state instead of global state for some reason clicked for everyone and they were like yes they were like whoa you're Right?
I've been thinking about global state for the last four years and now I now all it's like you you allow them to think differently say no it's client state and server state and they're like huh and all of a sudden everything made sense and and that's kind of the platform that I got on as soon as I adopted that marketing for the library everybody seemed to get it and that's when I started giving talks and and doing podcasts about it And yeah, it was honestly really surprising to see how quickly it went from what I don't understand what this library does.
What is a query?
What is a mutation?
You know, um to now all of a sudden there's people who are preaching to other people going, "No, no, no, that's client state.
That's server state.
" You know, and I'm like, "Oh, no.
What have I done?
" No, but I remember even in even in the projects that I worked on when when we started looking into those kind of solutions, there were a bunch of different already talks and like you say preachers of this like client state, server state like we should be using that and funny that you mentioned Redux that was already solving some of that problems because then RTK query came into into Redux itself which is a very like mirror solution to to to React Query.
Yeah.
And I I think that's really smart.
Mark Mark's the one who did uh Mark Ericen is the one who did almost all the work on not all of it but a lot
I've been thinking about global state for the last four years and now I now all it's like you you allow them to think differently say no it's client state and server state and they're like huh and all of a sudden everything made sense and and that's kind of the platform that I got on as soon as I adopted that marketing for the library everybody seemed to get it and that's when I started giving talks and and doing podcasts about it And yeah, it was honestly really surprising to see how quickly it went from what I don't understand what this library does.
What is a query?
What is a mutation?
You know, um to now all of a sudden there's people who are preaching to other people going, "No, no, no, that's client state.
That's server state.
" You know, and I'm like, "Oh, no.
What have I done?
" No, but I remember even in even in the projects that I worked on when when we started looking into those kind of solutions, there were a bunch of different already talks and like you say preachers of this like client state, server state like we should be using that and funny that you mentioned Redux that was already solving some of that problems because then RTK query came into into Redux itself which is a very like mirror solution to to to React Query.
Yeah.
And I I think that's really smart.
Mark Mark's the one who did uh Mark Ericen is the one who did almost all the work on not all of it but a lot
of the work on uh like RTK which is like this new fresh generation of re redux like the Redux toolkit.
And I think hit the the idea of trying to bring that same primitive into Redux is really good because there there's companies that are entrenched in technology everywhere that they can't change, right?
So giving them upgrade paths to these concepts um and these utilities without making them totally switch is definitely useful.
I think the interesting part though is that what I saw in practice is that most front-end developers were only using Redux for this and maybe a little bit of glo like true global state and that should have just been either in memory or in the URL but other than that uh which kind of leads me to the next portion of my journey but I saw that when they replaced react query like when they started using react query there was no more global state that they needed to manage because their global state was just a cache of their server state.
So, um I think that was a big realization for a lot of people that it's like, oh wow.
And you're going to see you're already seeing that today again where for the people that didn't move on to React Query or did and they're still wanting more, what you're seeing now is a a revitalization of sync engines, right?
And React Query is like tan set query is a sync engine.
It's just a different unique flavor of sync engine that you kind of put together on your own.
It's schemaless, but you're seeing it happen again.
There's people that are like, "Oh, look at this cool thing.
It can solve all of our all of our sync engine problems.
" So, we're just always rediscovering, you know, things from the past that can be applied or marketed in a different way to be like, "Oh, yeah, that does solve my problem.
I I should use that.
" So, we're going to see the
And I think hit the the idea of trying to bring that same primitive into Redux is really good because there there's companies that are entrenched in technology everywhere that they can't change, right?
So giving them upgrade paths to these concepts um and these utilities without making them totally switch is definitely useful.
I think the interesting part though is that what I saw in practice is that most front-end developers were only using Redux for this and maybe a little bit of glo like true global state and that should have just been either in memory or in the URL but other than that uh which kind of leads me to the next portion of my journey but I saw that when they replaced react query like when they started using react query there was no more global state that they needed to manage because their global state was just a cache of their server state.
So, um I think that was a big realization for a lot of people that it's like, oh wow.
And you're going to see you're already seeing that today again where for the people that didn't move on to React Query or did and they're still wanting more, what you're seeing now is a a revitalization of sync engines, right?
And React Query is like tan set query is a sync engine.
It's just a different unique flavor of sync engine that you kind of put together on your own.
It's schemaless, but you're seeing it happen again.
There's people that are like, "Oh, look at this cool thing.
It can solve all of our all of our sync engine problems.
" So, we're just always rediscovering, you know, things from the past that can be applied or marketed in a different way to be like, "Oh, yeah, that does solve my problem.
I I should use that.
" So, we're going to see the
same thing happen with sync engines already are over the next couple of years.
I think the next the next step that you referred to is uh router, right?
But before we go to router, I want to maybe touch on a little bit about the framework agnostic approach because react query was react query at the beginning and then the decision was made by you probably but let me know if I'm wrong to make it server agnostic and to name it tanstack query.
So can you talk about that for a little bit?
The decision was all basically made by the people using it who wanted who wanted it in other places.
Okay.
You know, there was a large group of people who were using React.
They were like, "Hey, but Vue is really cool, too.
You know, we'd love to use tools there.
" And I was like, "Yeah, that would be really cool.
" But right now, it's just React.
Already I had seen an issue um in React's table with you know relying too much on React especially as React was changing slowly over the years.
I didn't I didn't want to be necessarily locked into the React ecosystem cuz I believed what I had built was useful for more than just React.
So there was like a big there's a big break in the middle of like query and kind of the next generation of the libraries that we built where we just spent a really long time going through both framework agnostic efforts and also Typescript efforts.
In fact, they were kind of done at the same time because they were really really big refactors to go to an agnostic codebase.
And if you know anything about refactors, if you don't have types, refactors are really, really scary.
I kind of it was slowgoing at first because I had to learn Typescript, not just learn how to use TypeScript, but use like library level TypeScript and generics while I was refactoring React table into TANSAC
I think the next the next step that you referred to is uh router, right?
But before we go to router, I want to maybe touch on a little bit about the framework agnostic approach because react query was react query at the beginning and then the decision was made by you probably but let me know if I'm wrong to make it server agnostic and to name it tanstack query.
So can you talk about that for a little bit?
The decision was all basically made by the people using it who wanted who wanted it in other places.
Okay.
You know, there was a large group of people who were using React.
They were like, "Hey, but Vue is really cool, too.
You know, we'd love to use tools there.
" And I was like, "Yeah, that would be really cool.
" But right now, it's just React.
Already I had seen an issue um in React's table with you know relying too much on React especially as React was changing slowly over the years.
I didn't I didn't want to be necessarily locked into the React ecosystem cuz I believed what I had built was useful for more than just React.
So there was like a big there's a big break in the middle of like query and kind of the next generation of the libraries that we built where we just spent a really long time going through both framework agnostic efforts and also Typescript efforts.
In fact, they were kind of done at the same time because they were really really big refactors to go to an agnostic codebase.
And if you know anything about refactors, if you don't have types, refactors are really, really scary.
I kind of it was slowgoing at first because I had to learn Typescript, not just learn how to use TypeScript, but use like library level TypeScript and generics while I was refactoring React table into TANSAC
table while we were discussing how we were going to do the same thing for query.
And I had at by that point I had help.
So, uh, Dominic Dorfmeister aka TK Dodo and a handful of other people were currently helping me with React Query at the time.
And so, we kind of did all this at the same time.
We said, we're going to make framework agnostic cores and strip all of the all of the logic that doesn't have to do with React into these cores.
And we did it with table, we did it with query and then we built adapters around them to kind of translate the state management.
That came with a lot of new challenges.
Uh in fact even though we didn't release it for another two or three years that's where Tanstack store was born was this this requirement to have some kind of a store state management solution that we could use internally in our core and translate out back out to all the different types of reactivity and state management that's you know for each framework.
For the framework question, maybe you can you can answer which one of of those is the most difficult to to work with?
Which gave you the the most headaches?
You know, Vue is not bad.
They work with observables and it's it's not too difficult to to take events coming out of like a out of an immutable store and translate them into observables.
And same thing with solid.
It was it wasn't very difficult to do it with solid either.
Angular was a little more difficult, but I wouldn't even I wouldn't say because of that problem.
Angular is just very it feels very proprietary compared to kind of the modern-day framework and there's a lot of ngrx stuff.
So, Angular was a little bit more challenging.
Spelt, I think, is one of the more challenging ones.
And even today, spelt 5, I think, is making it easier.
But I'll be honest,
And I had at by that point I had help.
So, uh, Dominic Dorfmeister aka TK Dodo and a handful of other people were currently helping me with React Query at the time.
And so, we kind of did all this at the same time.
We said, we're going to make framework agnostic cores and strip all of the all of the logic that doesn't have to do with React into these cores.
And we did it with table, we did it with query and then we built adapters around them to kind of translate the state management.
That came with a lot of new challenges.
Uh in fact even though we didn't release it for another two or three years that's where Tanstack store was born was this this requirement to have some kind of a store state management solution that we could use internally in our core and translate out back out to all the different types of reactivity and state management that's you know for each framework.
For the framework question, maybe you can you can answer which one of of those is the most difficult to to work with?
Which gave you the the most headaches?
You know, Vue is not bad.
They work with observables and it's it's not too difficult to to take events coming out of like a out of an immutable store and translate them into observables.
And same thing with solid.
It was it wasn't very difficult to do it with solid either.
Angular was a little more difficult, but I wouldn't even I wouldn't say because of that problem.
Angular is just very it feels very proprietary compared to kind of the modern-day framework and there's a lot of ngrx stuff.
So, Angular was a little bit more challenging.
Spelt, I think, is one of the more challenging ones.
And even today, spelt 5, I think, is making it easier.
But I'll be honest,
I'm not involved much with the spelt efforts.
It's a relatively small subset of users and people who want the spelt adapters.
So, we're kind of letting the spelt community step up and work on those adapters if they want to.
But I I think that's the general order of things.
Um, what's cool is that when we went head by going headless and core agnostic, we basically got pact and react native for free.
Yeah, because the, you know, if you're if you're headless, then it doesn't really matter what you're using for UI.
And if it works, if we have a React adapter, we can build a Pact adapter.
This leads me to my next question.
You mentioned handless here, and I and I have in my notes that in your uh documentation, in your libraries, you often emphasize uh those being headless, type safe, zero depend dependencies.
So why are those principles so important for you when you build the ecosystem, when you build the libraries?
I think there's two sides to it.
One side is my sanity and the other side is it's just really useful like it's uh so let's start with my sanity.
So I actually have a talk that I gave at React Summit in Amsterdam about React Table.
Uh you should go watch it.
It's about building React table and why these things were important about headless and type safety.
But generally by going headless, you're removing an entire swath of problems and use cases that people are going to want to customize about an experience.
And if you go headless, you open that gate and just say you can do whatever you want after you get the logic.
You can do whatever you want with your markup.
You can do whatever you want with your styles.
You can switch things around.
All we do is handle the logical part of it.
And I think that embraces a lot of like the Unix style um
It's a relatively small subset of users and people who want the spelt adapters.
So, we're kind of letting the spelt community step up and work on those adapters if they want to.
But I I think that's the general order of things.
Um, what's cool is that when we went head by going headless and core agnostic, we basically got pact and react native for free.
Yeah, because the, you know, if you're if you're headless, then it doesn't really matter what you're using for UI.
And if it works, if we have a React adapter, we can build a Pact adapter.
This leads me to my next question.
You mentioned handless here, and I and I have in my notes that in your uh documentation, in your libraries, you often emphasize uh those being headless, type safe, zero depend dependencies.
So why are those principles so important for you when you build the ecosystem, when you build the libraries?
I think there's two sides to it.
One side is my sanity and the other side is it's just really useful like it's uh so let's start with my sanity.
So I actually have a talk that I gave at React Summit in Amsterdam about React Table.
Uh you should go watch it.
It's about building React table and why these things were important about headless and type safety.
But generally by going headless, you're removing an entire swath of problems and use cases that people are going to want to customize about an experience.
And if you go headless, you open that gate and just say you can do whatever you want after you get the logic.
You can do whatever you want with your markup.
You can do whatever you want with your styles.
You can switch things around.
All we do is handle the logical part of it.
And I think that embraces a lot of like the Unix style um
componentization approach where instead of trying to be this tool that is trying to cross many gaps, you know, trying to cross many concerns, we're just going to do one thing and we're going to do it really well.
And if we need to do the other thing too, then we're going to make it a separate thing and do it really well.
A great example of that is we we took React table headless.
So it handles all of the logic for you for building a data grid.
We didn't really specialize in the UI part of it, the markup and the styles.
Well, now you see Shad CN.
Shad Cien is this ultra successful UI approach and he kind of did the same thing but mirrored.
He probably thought I don't want to build all the logic around a data grid.
I don't want to build all the logic around you know these complex tables.
So he just built the UI part of it and because Tanstack table is headless they can just merge together flawlessly.
So meaning the the prescription for success here is focus on some atomic part of it and make it really good and then this is pluggable to other systems that are really good as well on the atomic parts of their part of the job and then then it just works because if you if you've built the uh react table the logic part of it would be really good but then the opinionated view part of it would suck for some people, then it wouldn't be as popular.
Yeah.
And that's that's how I learned is I did that.
I built it all together.
I built a component with with markup and styles and so much of the support requests and the complaints and just the entitlement around you know open source was just focused on I just want to I just want my table to look the way that I want it to look.
I want to use my components.
I want to use my styles and they want to override everything.
And
And if we need to do the other thing too, then we're going to make it a separate thing and do it really well.
A great example of that is we we took React table headless.
So it handles all of the logic for you for building a data grid.
We didn't really specialize in the UI part of it, the markup and the styles.
Well, now you see Shad CN.
Shad Cien is this ultra successful UI approach and he kind of did the same thing but mirrored.
He probably thought I don't want to build all the logic around a data grid.
I don't want to build all the logic around you know these complex tables.
So he just built the UI part of it and because Tanstack table is headless they can just merge together flawlessly.
So meaning the the prescription for success here is focus on some atomic part of it and make it really good and then this is pluggable to other systems that are really good as well on the atomic parts of their part of the job and then then it just works because if you if you've built the uh react table the logic part of it would be really good but then the opinionated view part of it would suck for some people, then it wouldn't be as popular.
Yeah.
And that's that's how I learned is I did that.
I built it all together.
I built a component with with markup and styles and so much of the support requests and the complaints and just the entitlement around you know open source was just focused on I just want to I just want my table to look the way that I want it to look.
I want to use my components.
I want to use my styles and they want to override everything.
And
you can't do that in a good way without basically exploding the complexity and the size of a library.
So that's the biggest reason that I did it.
TypeScript.
This doesn't need to turn into a TypeScript podcast, but all I can say is that if if you're not using TypeScript, you either don't know the benefits that it will give you or you do know and you're being stubborn about it because you either don't work with a team that's big enough to need it.
you're not doing refactors that are big enough to lean on it or you're not you're not shipping code that's used by enough developers that's going to that they're going to find the holes in your code.
There's there's even a couple of people that I'm thinking of personally right now that are just so stubborn that they will not use TypeScript.
They see it as an overhead.
They see it as a problem.
You know, that was me four years ago.
I was very anti-typescript.
And you know because you know I'm one of those people where even for really large projects like React Table and React Query I could keep almost all of it in my brain and it's taxing.
It was taxing but I could do it like I had all of the types and the contracts and the API in my head and you know I just knew what I could do and what I couldn't and yeah we had some tests.
I didn't even write like to write tests, but it's like, you know, I could handle it most of the time.
And then the time came when I needed to refactor or bring somebody new onto the team like like TK Dodo or just any big moment where we needed to change something.
And Dominic was like, "So, what what is the contract here?
" And I so I ended up you end up distilling all this information out of your squishy terrible brain to someone else to someone else's squishy terrible brain.
And you know not that
So that's the biggest reason that I did it.
TypeScript.
This doesn't need to turn into a TypeScript podcast, but all I can say is that if if you're not using TypeScript, you either don't know the benefits that it will give you or you do know and you're being stubborn about it because you either don't work with a team that's big enough to need it.
you're not doing refactors that are big enough to lean on it or you're not you're not shipping code that's used by enough developers that's going to that they're going to find the holes in your code.
There's there's even a couple of people that I'm thinking of personally right now that are just so stubborn that they will not use TypeScript.
They see it as an overhead.
They see it as a problem.
You know, that was me four years ago.
I was very anti-typescript.
And you know because you know I'm one of those people where even for really large projects like React Table and React Query I could keep almost all of it in my brain and it's taxing.
It was taxing but I could do it like I had all of the types and the contracts and the API in my head and you know I just knew what I could do and what I couldn't and yeah we had some tests.
I didn't even write like to write tests, but it's like, you know, I could handle it most of the time.
And then the time came when I needed to refactor or bring somebody new onto the team like like TK Dodo or just any big moment where we needed to change something.
And Dominic was like, "So, what what is the contract here?
" And I so I ended up you end up distilling all this information out of your squishy terrible brain to someone else to someone else's squishy terrible brain.
And you know not that
not that we have terrible brains but we're just not good at remembering the all these details at scale.
And eventually you'll forget it will decay.
It will bit flip.
You'll forget a contract.
Typescript takes all of that away.
You take all of that architecture and contract and signatures and types and you make it explicit in your code.
And if you do it right, you don't have to write a lot of TypeScript.
You really don't.
If you do complex stuff, you do, which is fine.
By the time you get there, you'll probably enjoy it.
Like I enjoy it.
But when you do that, you liberate yourself from all of that cognitive overhead that you are keeping in your brain for JavaScript.
And like I said, maybe that's not a problem for some people because they're not working on a project that's big enough or that's complex enough and that's fine.
But eventually you'll get there.
I hope that people would eventually get to the point where they are building cool stuff that necessitates that.
Today, I would not start a project without TypeScript.
I think it would be foolish.
Uh, in fact, even when I'm even when I'm just playing around with something in code sandbox or or whatever, I still do it in Typescript because it's so easy to just misuse your own contracts and abuse the language of JavaScript.
It is an easily abused language.
going to the the last principle that I found zero dependencies.
Not having dependencies is a good idea because usually if you want to deliver the best product you can, you'll eventually or gradually want to have more and more control over the entire experience.
If you don't have control over like the pipeline of your product, then either I hope that either if you do have a dependency, it's worth it because it's something you don't want to have to handle or instead of having a
And eventually you'll forget it will decay.
It will bit flip.
You'll forget a contract.
Typescript takes all of that away.
You take all of that architecture and contract and signatures and types and you make it explicit in your code.
And if you do it right, you don't have to write a lot of TypeScript.
You really don't.
If you do complex stuff, you do, which is fine.
By the time you get there, you'll probably enjoy it.
Like I enjoy it.
But when you do that, you liberate yourself from all of that cognitive overhead that you are keeping in your brain for JavaScript.
And like I said, maybe that's not a problem for some people because they're not working on a project that's big enough or that's complex enough and that's fine.
But eventually you'll get there.
I hope that people would eventually get to the point where they are building cool stuff that necessitates that.
Today, I would not start a project without TypeScript.
I think it would be foolish.
Uh, in fact, even when I'm even when I'm just playing around with something in code sandbox or or whatever, I still do it in Typescript because it's so easy to just misuse your own contracts and abuse the language of JavaScript.
It is an easily abused language.
going to the the last principle that I found zero dependencies.
Not having dependencies is a good idea because usually if you want to deliver the best product you can, you'll eventually or gradually want to have more and more control over the entire experience.
If you don't have control over like the pipeline of your product, then either I hope that either if you do have a dependency, it's worth it because it's something you don't want to have to handle or instead of having a
dependency, a hard dependency on something, build your library in a way that can just integrate with it or integrate with any tool like that dependency.
You know, we're not 100% true on that with all of our libraries.
Like Tanstack start wouldn't be anything without VIT.
Um, and wouldn't have been anything for the last, you know, one year of beta without Vinci and you know won't be anything for the next six months to a year maybe without know.
So dependencies are are sometimes um necessary especially for things that you don't want to build yourself.
It's funny how you reminded me of uh Tanstack start because that was my initial idea about this episode.
So let's slowly move toward that uh that new JavaScript framework that you built.
But in order to get there, we have to talk about yet another Tanstack library which is Tanstack router.
Question to you connected with Tanstack router.
Do you think that client site was underappreciated and overlooked in React community over the past I don't know four years or something like that?
Yeah, parts of it parts of it were um there's parts of it that were prioritized like the React team themselves have been working on the compiler which is very much client sideoriented you know so there's certain parts of the client experience that many of us are still thinking about and there's parts that I think that we reached kind of a good enough level of satisfaction and we just kind of moved on and that that good enough probably means that things were good enough for most people to ship good products.
So, uh no more in innovation just stops and moves on to the next nail that's sticking out, you know, and we say, well, how can we hammer this next nail?
For me, the reason that I started getting into router comes from Nozzle
You know, we're not 100% true on that with all of our libraries.
Like Tanstack start wouldn't be anything without VIT.
Um, and wouldn't have been anything for the last, you know, one year of beta without Vinci and you know won't be anything for the next six months to a year maybe without know.
So dependencies are are sometimes um necessary especially for things that you don't want to build yourself.
It's funny how you reminded me of uh Tanstack start because that was my initial idea about this episode.
So let's slowly move toward that uh that new JavaScript framework that you built.
But in order to get there, we have to talk about yet another Tanstack library which is Tanstack router.
Question to you connected with Tanstack router.
Do you think that client site was underappreciated and overlooked in React community over the past I don't know four years or something like that?
Yeah, parts of it parts of it were um there's parts of it that were prioritized like the React team themselves have been working on the compiler which is very much client sideoriented you know so there's certain parts of the client experience that many of us are still thinking about and there's parts that I think that we reached kind of a good enough level of satisfaction and we just kind of moved on and that that good enough probably means that things were good enough for most people to ship good products.
So, uh no more in innovation just stops and moves on to the next nail that's sticking out, you know, and we say, well, how can we hammer this next nail?
For me, the reason that I started getting into router comes from Nozzle
again.
So at Nozzle, we we were building dashboards, dashboarding systems, and part of this experience was we just have a lot of different dashboards and there's the concept of drill through, right?
Where you're on one dashboard and you you're looking at an item in a dashboard and you're kind of like, I want to investigate that item a little bit more.
you click on it and you kind of dive in deeper to that segment of data.
And it might be the same dashboard but just kind of a deeper view or it could be a different dashboard or it could even be that you're like you know what I want to edit my settings for that piece of data like I want to go to the admin part of it to kind of change some of my configuration.
So there's a lot of navigating around in this very interactive data explor exploration um vibe that we had from Nozzle.
And as we got deeper and deeper into building more dashboards, I found that an area of friction for me was the URL because we had users that work on in big teams, marketing teams, SEO teams, and they're diving into this data and they see something that's like, "Oh my gosh, look at this chart.
It just went down.
" You know what the heck happened here?
and they take they either take a screenshot and they send it to somebody and then they're like, "Well, I don't know.
I I can't go off of a screenshot and they take the URL and they send it to their coworker and their coworker's like, "What am I looking at?
" Cuz everything looks fine because we weren't keeping enough of the state into the URL.
And that that is this this was like four or five years ago long time ago in terms of like the life of react query and router like this is a long time ago.
So it's been a problem for a while and we started playing with how much state could we put in the URL?
Could we just
So at Nozzle, we we were building dashboards, dashboarding systems, and part of this experience was we just have a lot of different dashboards and there's the concept of drill through, right?
Where you're on one dashboard and you you're looking at an item in a dashboard and you're kind of like, I want to investigate that item a little bit more.
you click on it and you kind of dive in deeper to that segment of data.
And it might be the same dashboard but just kind of a deeper view or it could be a different dashboard or it could even be that you're like you know what I want to edit my settings for that piece of data like I want to go to the admin part of it to kind of change some of my configuration.
So there's a lot of navigating around in this very interactive data explor exploration um vibe that we had from Nozzle.
And as we got deeper and deeper into building more dashboards, I found that an area of friction for me was the URL because we had users that work on in big teams, marketing teams, SEO teams, and they're diving into this data and they see something that's like, "Oh my gosh, look at this chart.
It just went down.
" You know what the heck happened here?
and they take they either take a screenshot and they send it to somebody and then they're like, "Well, I don't know.
I I can't go off of a screenshot and they take the URL and they send it to their coworker and their coworker's like, "What am I looking at?
" Cuz everything looks fine because we weren't keeping enough of the state into the URL.
And that that is this this was like four or five years ago long time ago in terms of like the life of react query and router like this is a long time ago.
So it's been a problem for a while and we started playing with how much state could we put in the URL?
Could we just
serialize all of our global state and put it into a share link?
You know at the end of the day it came down it it boiled down to the tools that were managing the URL and that was React Router at the time.
It was React Router V5.
And when I started diving into this problem, they were working on React Router v6 and it was in beta.
It was in beta for I think like two years or something like that.
But it was good enough that I started building kind of like what I did with Redux.
I said, I'm going to start building my solution to this problem on top of a great tool like React Router.
And I did.
I started proxying all of the React router hooks and components through my own versions that would allow me to manage URL state better to have better contracts to better type safety.
And that went on for about a year and we used that internally at Nozzle for quite a while.
But eventually I hit the glass ceiling.
I needed more control than React Router could give me and more control than they were willing to give up.
Uh because there were other people asking for, you know, can you expose this context, this React context or uh you know, could we, I don't know, could we augment the API here or change some of the way the core mechanics work?
I get it.
You know, they didn't want to do that.
And so I I didn't really have much choice at that time to just say okay then I need to now replace the you know implementation detail just like I did with Redux.
I need to replace it with something of my own that uh is just going to have the right contracts that I need for nozzle.
meaning you've already built so much on top of Reacter then that the the internal library was basically your dependency and you just swapped the dependency for something that you wrote your own and I was able to even get rid
You know at the end of the day it came down it it boiled down to the tools that were managing the URL and that was React Router at the time.
It was React Router V5.
And when I started diving into this problem, they were working on React Router v6 and it was in beta.
It was in beta for I think like two years or something like that.
But it was good enough that I started building kind of like what I did with Redux.
I said, I'm going to start building my solution to this problem on top of a great tool like React Router.
And I did.
I started proxying all of the React router hooks and components through my own versions that would allow me to manage URL state better to have better contracts to better type safety.
And that went on for about a year and we used that internally at Nozzle for quite a while.
But eventually I hit the glass ceiling.
I needed more control than React Router could give me and more control than they were willing to give up.
Uh because there were other people asking for, you know, can you expose this context, this React context or uh you know, could we, I don't know, could we augment the API here or change some of the way the core mechanics work?
I get it.
You know, they didn't want to do that.
And so I I didn't really have much choice at that time to just say okay then I need to now replace the you know implementation detail just like I did with Redux.
I need to replace it with something of my own that uh is just going to have the right contracts that I need for nozzle.
meaning you've already built so much on top of Reacter then that the the internal library was basically your dependency and you just swapped the dependency for something that you wrote your own and I was able to even get rid
of some of the external stuff that I was wrapping it with by just making it first class.
So by making search parameters a first class citizen of the navigational APIs, I got rid of all of my search parameter hooks.
You know, at the time they were working on remix, which had loaders and actions and a lot of cool stuff there.
And I thought, well, while I'm at it, why don't I just add loaders to this to this library that I'm doing?
You know, client side only loaders, but still loaders.
And so it started to take shape and it actually was called React location in the beginning.
Yes.
Yeah.
I I I found that on the when I was preparing for this episode, I was trying to find the libraries that are no longer mentioned on Tanstack uh site and I came across this React location library and I was like, "Yay, I found it.
I can ask uh Tanner about this location library.
" And then I clicked on the link and it redirected me to to router.
Yeah, that's on purpose.
You can actually there is a uh there is a branch I think in Tanstack router that has the old react location code in it if you wanted to go look at it.
Really what it is is if you look at the code it was kind of my learning experience on can I build a router which if you ask anybody a lot of people will say well yeah sure anybody can build a router that seems really easy uh it's deceptively simple and turns into a very complex task so react location was my playground to kind of say can I do it and how well can I do it and at the time intellect intellectual property uh and like you know protection of ideas had come up a lot between remix and nex.
js and they were kind of you know quibbling over that to some extent.
It was kind of a sensitive topic.
I I really didn't want to get into that.
So I challenged myself with react location to build all
So by making search parameters a first class citizen of the navigational APIs, I got rid of all of my search parameter hooks.
You know, at the time they were working on remix, which had loaders and actions and a lot of cool stuff there.
And I thought, well, while I'm at it, why don't I just add loaders to this to this library that I'm doing?
You know, client side only loaders, but still loaders.
And so it started to take shape and it actually was called React location in the beginning.
Yes.
Yeah.
I I I found that on the when I was preparing for this episode, I was trying to find the libraries that are no longer mentioned on Tanstack uh site and I came across this React location library and I was like, "Yay, I found it.
I can ask uh Tanner about this location library.
" And then I clicked on the link and it redirected me to to router.
Yeah, that's on purpose.
You can actually there is a uh there is a branch I think in Tanstack router that has the old react location code in it if you wanted to go look at it.
Really what it is is if you look at the code it was kind of my learning experience on can I build a router which if you ask anybody a lot of people will say well yeah sure anybody can build a router that seems really easy uh it's deceptively simple and turns into a very complex task so react location was my playground to kind of say can I do it and how well can I do it and at the time intellect intellectual property uh and like you know protection of ideas had come up a lot between remix and nex.
js and they were kind of you know quibbling over that to some extent.
It was kind of a sensitive topic.
I I really didn't want to get into that.
So I challenged myself with react location to build all
of it just without looking at anything.
not just React router source code, but any other routers, router, uh just anything.
I just wanted it to be fresh and maybe even come up with some of my own innovations around how to do it.
Now that I've done that, I think a lot of a lot of it ends up being similar.
There's some concepts you just can't get away from, but there are a lot of things internally it end up being very different in a good way.
So talk about that.
Talk about the principles for React uh for Ta Crowder.
The principles for the router I think they start with the URL.
So the URL is just another place to store state and if you if you think about it and very important one very important state it's it's actually if you imagine you we use local storage all the time and if you take one key out of your local storage that can hold a string.
Now imagine taking that one local storage keys string and permanently placing it at the top of your application.
That's the URL, right?
It is a it's a locally and sharable stateless stringified representation of where you are and what you're doing with the added context of the browser history which is where now you have a version.
you you now have versioned stacks of these stringified states.
That is really the core of it.
And you can almost start to think of the URL as like a versioned database, right?
It's a database with one column, one row.
Well, no, multiple rows, I guess, if you want to think about rows as like history, right?
And you can update that one cell with new values that can represent the user's new state.
It's the part though where users can just hit refresh or share that URL that breaks all of that down.
So my biggest frustration after I got into this dashboard experience with Nozzle
not just React router source code, but any other routers, router, uh just anything.
I just wanted it to be fresh and maybe even come up with some of my own innovations around how to do it.
Now that I've done that, I think a lot of a lot of it ends up being similar.
There's some concepts you just can't get away from, but there are a lot of things internally it end up being very different in a good way.
So talk about that.
Talk about the principles for React uh for Ta Crowder.
The principles for the router I think they start with the URL.
So the URL is just another place to store state and if you if you think about it and very important one very important state it's it's actually if you imagine you we use local storage all the time and if you take one key out of your local storage that can hold a string.
Now imagine taking that one local storage keys string and permanently placing it at the top of your application.
That's the URL, right?
It is a it's a locally and sharable stateless stringified representation of where you are and what you're doing with the added context of the browser history which is where now you have a version.
you you now have versioned stacks of these stringified states.
That is really the core of it.
And you can almost start to think of the URL as like a versioned database, right?
It's a database with one column, one row.
Well, no, multiple rows, I guess, if you want to think about rows as like history, right?
And you can update that one cell with new values that can represent the user's new state.
It's the part though where users can just hit refresh or share that URL that breaks all of that down.
So my biggest frustration after I got into this dashboard experience with Nozzle
was then I mean even before that was going to a website you're doing something you click on some filters or you click somewhere you hit refresh to refresh your page cuz something broke obviously and then you're lost every like what you were doing is gone.
You're back at the home screen or who knows what else has just happened.
That's a really frustrating experience for an end user.
It It's maddening for somebody who's working in an enterprise application.
So the URL needs to represent where you are, what you're doing, and it needs to have everything in it not only to recreate most of your local experience if they hit refresh, but it needs to have everything in it to replicate the necessary experience for someone else if you were to share that URL.
That's what it all boils down to.
And these principles are shared by most URLs.
I mean, when React Router came out, one of their big things was and you know, we support commandclick where you can you can hold command and or or control and click on a link and it will open in a new tab and actually be where you want to where you want to be cuz they were they were doing real path name tracking and path name generation using the URL as a source of truth instead of like hashbang routing.
So in a similar fashion, Tanstack Router builds on that principle and says, you know what, we're not only going to worry about the path, we're going to worry about search parameters, your history, we're going to do things like route masking.
And there's lots of features that build on top of that.
And even some ones that get really into the weeds, like if you're going to use the URL as state management, how quickly can you update the URL?
Turns out you can update it really quickly, but not in every browser.
So like with Safari, if
You're back at the home screen or who knows what else has just happened.
That's a really frustrating experience for an end user.
It It's maddening for somebody who's working in an enterprise application.
So the URL needs to represent where you are, what you're doing, and it needs to have everything in it not only to recreate most of your local experience if they hit refresh, but it needs to have everything in it to replicate the necessary experience for someone else if you were to share that URL.
That's what it all boils down to.
And these principles are shared by most URLs.
I mean, when React Router came out, one of their big things was and you know, we support commandclick where you can you can hold command and or or control and click on a link and it will open in a new tab and actually be where you want to where you want to be cuz they were they were doing real path name tracking and path name generation using the URL as a source of truth instead of like hashbang routing.
So in a similar fashion, Tanstack Router builds on that principle and says, you know what, we're not only going to worry about the path, we're going to worry about search parameters, your history, we're going to do things like route masking.
And there's lots of features that build on top of that.
And even some ones that get really into the weeds, like if you're going to use the URL as state management, how quickly can you update the URL?
Turns out you can update it really quickly, but not in every browser.
So like with Safari, if
you try and update the URL too fast, too often, you'll get throttled and the the browser will be like, "Hey, this website's trying to do something weird with your URL.
" So I ended up building this like synchronization queuing system between the router and the URL to take updates that happen within the same micro tick and and bash them into the URL so that you're not spamming it.
So there were a lot of like really low-level things to figure out with the URL, but that's one of the guiding principles there.
And the other guiding principles are pretty much shared between the other libraries.
It can't be totally headless because there are components that you that you need to render.
But in the spirit of headless UI, we can take as much opinion out of the routing as possible so that we don't interfere with your markup and your styles and the and the like the UI code that you write.
So mostly just keeping it logical.
The other principle of you know being agnostic is really great.
So we ripped out the core of Tanstack router into a router core that is just TypeScript.
So today even so while we're talking there's they're chatting on Discord right now.
Brandon Roberts is working on an Angular router version of Tanstack router.
They we already have a solid router version of Tanstack router that you can use today that's ready to go.
So all the same principles apply.
The type safety is this is one where it got really really deep into type safety because no other router had really tackled type safety in the way that that I wanted to and it took honestly about a year or two to figure out even how to do that in a way that would be scalable.
Yeah, there is a mig migration guide between uh react location and react router sorry tack router talking about how the type safety is different between
" So I ended up building this like synchronization queuing system between the router and the URL to take updates that happen within the same micro tick and and bash them into the URL so that you're not spamming it.
So there were a lot of like really low-level things to figure out with the URL, but that's one of the guiding principles there.
And the other guiding principles are pretty much shared between the other libraries.
It can't be totally headless because there are components that you that you need to render.
But in the spirit of headless UI, we can take as much opinion out of the routing as possible so that we don't interfere with your markup and your styles and the and the like the UI code that you write.
So mostly just keeping it logical.
The other principle of you know being agnostic is really great.
So we ripped out the core of Tanstack router into a router core that is just TypeScript.
So today even so while we're talking there's they're chatting on Discord right now.
Brandon Roberts is working on an Angular router version of Tanstack router.
They we already have a solid router version of Tanstack router that you can use today that's ready to go.
So all the same principles apply.
The type safety is this is one where it got really really deep into type safety because no other router had really tackled type safety in the way that that I wanted to and it took honestly about a year or two to figure out even how to do that in a way that would be scalable.
Yeah, there is a mig migration guide between uh react location and react router sorry tack router talking about how the type safety is different between
the two.
Yeah.
which in in a good way the migration guide kind of says you don't have to pass anything because we just infer everything now.
Uh so you get to remove types from your code if you move to tan sect start.
Um, in fact, I think it's one of the one of the things that kind of speaks uh to the to the like the the quality of the types and the thought process that we put into it is that you can have an entire route with loaders and components and, you know, server functions and all this cool stuff and you you likely will not see a single bit of TypeScript syntax in the entire file.
Nice.
it it just looks like JavaScript.
Um, and that's kind of a testament to like the level of care that we've put into it.
Going back to the beginning of this episode when I said we've met after your talk about Tanstack start and that I didn't want for this podcast to be about Tanstack start exclusively.
It turns out that this podcast was almost exclusively about other things than Tanstack start.
But surprise surprise over the past 10 minutes we've been actually talking about Tanstack start because Tanstack router is an integral part like it's a most important part of Tanstack start.
So can you talk about that and also what are the other 10% of things that compose to to tan stack start 10 seconds start.
Yeah, it is interesting that we're marketing it as like a separate thing like as like a wrapper around router, which it kind of is, but so so what's really interesting is if you were to go and build a Tanstack router application, client side application, use all the APIs, build everything you can with Tanstack router, the only change you would need to maybe make to go to start would be you would likely want to adopt file-based routing instead of codebased
Yeah.
which in in a good way the migration guide kind of says you don't have to pass anything because we just infer everything now.
Uh so you get to remove types from your code if you move to tan sect start.
Um, in fact, I think it's one of the one of the things that kind of speaks uh to the to the like the the quality of the types and the thought process that we put into it is that you can have an entire route with loaders and components and, you know, server functions and all this cool stuff and you you likely will not see a single bit of TypeScript syntax in the entire file.
Nice.
it it just looks like JavaScript.
Um, and that's kind of a testament to like the level of care that we've put into it.
Going back to the beginning of this episode when I said we've met after your talk about Tanstack start and that I didn't want for this podcast to be about Tanstack start exclusively.
It turns out that this podcast was almost exclusively about other things than Tanstack start.
But surprise surprise over the past 10 minutes we've been actually talking about Tanstack start because Tanstack router is an integral part like it's a most important part of Tanstack start.
So can you talk about that and also what are the other 10% of things that compose to to tan stack start 10 seconds start.
Yeah, it is interesting that we're marketing it as like a separate thing like as like a wrapper around router, which it kind of is, but so so what's really interesting is if you were to go and build a Tanstack router application, client side application, use all the APIs, build everything you can with Tanstack router, the only change you would need to maybe make to go to start would be you would likely want to adopt file-based routing instead of codebased
routing.
But other than that, there's no breaking changes that you would need to make to any of your routes or your routing to use tanstack start because tanstack start is not a different it's not a different router or a different library.
It's just additional tools and context to use with router.
So they're actually more parallel and side by side than they are wrapping one another.
So tan stack start gives you a couple of things that you don't get with router.
You already have loaders and you know life cycle events and things with router but the problem is everything happens client side.
So what tansac start does is gives you server side control and server side utilities.
Um the first thing it does is gives you server functions and API routes.
So now in your loaders for your routes instead of doing something on the client you can shift that that logic into a server function or an API route and it will only run on the server.
even when we SSR or when you get to the client and you're just using TANS stack router, we ensure that it will always go back to the server for you.
So that's the first thing that you get.
The next thing that Tanstack start does is it takes your single client side entry and it splits it into two.
So that now you have a client side entry, but you also have a server side entry which gives you server side rendering, handles all of the hydration for you and allows you to have cool things like streaming.
So you can now do uh streaming through, you know, um suspense or whatever else you want to do.
And then it produces a new integration layer for things like Tanstack query to work even smarter.
One of the things we have, we have an integration for Tanstack query that links up the links up Tanstack router and TANSAC start
But other than that, there's no breaking changes that you would need to make to any of your routes or your routing to use tanstack start because tanstack start is not a different it's not a different router or a different library.
It's just additional tools and context to use with router.
So they're actually more parallel and side by side than they are wrapping one another.
So tan stack start gives you a couple of things that you don't get with router.
You already have loaders and you know life cycle events and things with router but the problem is everything happens client side.
So what tansac start does is gives you server side control and server side utilities.
Um the first thing it does is gives you server functions and API routes.
So now in your loaders for your routes instead of doing something on the client you can shift that that logic into a server function or an API route and it will only run on the server.
even when we SSR or when you get to the client and you're just using TANS stack router, we ensure that it will always go back to the server for you.
So that's the first thing that you get.
The next thing that Tanstack start does is it takes your single client side entry and it splits it into two.
So that now you have a client side entry, but you also have a server side entry which gives you server side rendering, handles all of the hydration for you and allows you to have cool things like streaming.
So you can now do uh streaming through, you know, um suspense or whatever else you want to do.
And then it produces a new integration layer for things like Tanstack query to work even smarter.
One of the things we have, we have an integration for Tanstack query that links up the links up Tanstack router and TANSAC start
together.
And now you can just call use suspense query in your component and you don't have to do anything else.
You don't have to dehydrate or use initial props.
You don't have to uh use suspense or anything like that.
You just call use suspense query and you get uh streaming to you know SSR capable streaming just right out of the box.
So it's it's a really impressive extension I think to the router that just lets you have full stack capabilities.
And I'm not saying just a few full stack capabilities.
There really isn't much you no there really isn't anything you can't do with tan stack router and start that you you know that we would be missing from something like Nex.
js or remix uh or react router 7 I think that's actually my next question like how do you position tanto start uh alongside those two alongside Nex.
js JS and and Remix.
So I guess I got to re I have to say RSC react server components is one area that we don't have everything yet.
That's kind of the only area but and sorry and for that I've heard you talk a lot about some some really fun ideas how you can incorporate React server components in transact start.
Yeah.
So let's talk about that next.
I think it's I think it's worth hitting on.
Maybe we can end on that.
But positioning start and router in the ecosystem has been interesting because the router is very much a client side router.
It's a client side framework.
Start makes that a full stack framework but it doesn't change the APIs of the router.
So you're very much still writing a clientside oriented or you know a clientside principles first application that happens to have full stacked capabilities like everything else.
So that is mostly the positioning that I've taken with it because it isn't like Nex.
js JS where everything is
And now you can just call use suspense query in your component and you don't have to do anything else.
You don't have to dehydrate or use initial props.
You don't have to uh use suspense or anything like that.
You just call use suspense query and you get uh streaming to you know SSR capable streaming just right out of the box.
So it's it's a really impressive extension I think to the router that just lets you have full stack capabilities.
And I'm not saying just a few full stack capabilities.
There really isn't much you no there really isn't anything you can't do with tan stack router and start that you you know that we would be missing from something like Nex.
js or remix uh or react router 7 I think that's actually my next question like how do you position tanto start uh alongside those two alongside Nex.
js JS and and Remix.
So I guess I got to re I have to say RSC react server components is one area that we don't have everything yet.
That's kind of the only area but and sorry and for that I've heard you talk a lot about some some really fun ideas how you can incorporate React server components in transact start.
Yeah.
So let's talk about that next.
I think it's I think it's worth hitting on.
Maybe we can end on that.
But positioning start and router in the ecosystem has been interesting because the router is very much a client side router.
It's a client side framework.
Start makes that a full stack framework but it doesn't change the APIs of the router.
So you're very much still writing a clientside oriented or you know a clientside principles first application that happens to have full stacked capabilities like everything else.
So that is mostly the positioning that I've taken with it because it isn't like Nex.
js JS where everything is
server oriented and server first.
And Remix kind of sits more in the middle, but even Remix it still has a a decent side of it that's very server first.
You know, we got to go back to the server to do things.
Both of both Nex.
js and Remix can operate the way that Tanstack Router does in a client first fashion.
remix more so than next, but the APIs and like the conventions and the the happy paths for those weren't designed to be a client side first experience in my in my opinion.
Next.
js definitely not.
So, yeah, the default the default is just server the server side rendering and and Remix is much much better about it.
They they sit I think evenly in the middle.
You know, you can do this in this on the server or you could do this in the client.
But for apps that have already been written as client side applications that want to just start taking part in an SSR experience or server functions or just some of those features on their own, they'll probably feel more at home in something like Tanstack Router because everything is written from the client side perspective where the server is 100% optional.
So Tanner, let me ask you this.
Are you a client site hero that React needs right now?
Those people who already created a bunch of applications on client.
No, the the pe the real heroes are the people who are just going to keep building their apps as client side apps.
those are the real heroes because that's all I want to do is I have applications that just don't need to be um they don't need to have this server first mentality but that doesn't mean that I want to ditch the ability to SSR or ditch the ability to have server functions or API routes or anything like that like I want to do all those things too or have React server components like you shouldn't have to choose you know based on the
And Remix kind of sits more in the middle, but even Remix it still has a a decent side of it that's very server first.
You know, we got to go back to the server to do things.
Both of both Nex.
js and Remix can operate the way that Tanstack Router does in a client first fashion.
remix more so than next, but the APIs and like the conventions and the the happy paths for those weren't designed to be a client side first experience in my in my opinion.
Next.
js definitely not.
So, yeah, the default the default is just server the server side rendering and and Remix is much much better about it.
They they sit I think evenly in the middle.
You know, you can do this in this on the server or you could do this in the client.
But for apps that have already been written as client side applications that want to just start taking part in an SSR experience or server functions or just some of those features on their own, they'll probably feel more at home in something like Tanstack Router because everything is written from the client side perspective where the server is 100% optional.
So Tanner, let me ask you this.
Are you a client site hero that React needs right now?
Those people who already created a bunch of applications on client.
No, the the pe the real heroes are the people who are just going to keep building their apps as client side apps.
those are the real heroes because that's all I want to do is I have applications that just don't need to be um they don't need to have this server first mentality but that doesn't mean that I want to ditch the ability to SSR or ditch the ability to have server functions or API routes or anything like that like I want to do all those things too or have React server components like you shouldn't have to choose you know based on the
style that you approach to build your application you shouldn't have to give things up.
And that kind of happened when Nex.
js kind of pivoted and and said we're just going to be server first and you know Remix focused for a really long time on the server uh as a server first library and now they're kind of reconciling.
So I don't know.
I just think that there's a lot of applications out there that are going to stay the way they are as client side applications and they shouldn't be left in in the dust in terms of what they're able to do simply because you know they say we're just going to move to Vit and we're going to keep using a clientside router.
You know there's two great options there.
you use React Router, that's probably what they're using already.
And or you can use Tanstack router and actually upgrade your client side routing experience to have new and greater things on the client version of like with actual routing and you get all these good things on the server as as well if you want.
You just add a plugin, you get 10 stack start and you're ready to go.
So, you know, React Router 7 and and Tensex start are way more aligned than they are different.
There's just, you know, important but more subtle differences between something like us and Next.
js.
So, yeah, that's that's the vision that I have for it is that I I definitely am going to keep focusing on the client side uh experience.
For instance, routing.
I know that uh a lot of people are going to be like, well, you have server side capabilities now.
What are you gonna do?
Are you going to go cloud tools utilities uh server utilities?
No.
Once we get start out, I'm actually going back to Tanstack router.
Uh I have more features and more very powerful concepts that still need to happen in Tanstack Router that I haven't seen in
And that kind of happened when Nex.
js kind of pivoted and and said we're just going to be server first and you know Remix focused for a really long time on the server uh as a server first library and now they're kind of reconciling.
So I don't know.
I just think that there's a lot of applications out there that are going to stay the way they are as client side applications and they shouldn't be left in in the dust in terms of what they're able to do simply because you know they say we're just going to move to Vit and we're going to keep using a clientside router.
You know there's two great options there.
you use React Router, that's probably what they're using already.
And or you can use Tanstack router and actually upgrade your client side routing experience to have new and greater things on the client version of like with actual routing and you get all these good things on the server as as well if you want.
You just add a plugin, you get 10 stack start and you're ready to go.
So, you know, React Router 7 and and Tensex start are way more aligned than they are different.
There's just, you know, important but more subtle differences between something like us and Next.
js.
So, yeah, that's that's the vision that I have for it is that I I definitely am going to keep focusing on the client side uh experience.
For instance, routing.
I know that uh a lot of people are going to be like, well, you have server side capabilities now.
What are you gonna do?
Are you going to go cloud tools utilities uh server utilities?
No.
Once we get start out, I'm actually going back to Tanstack router.
Uh I have more features and more very powerful concepts that still need to happen in Tanstack Router that I haven't seen in
any other router.
things that I think are going to actually elevate the experience of building an application and w with regards to routing.
Awesome.
I'm definitely I'm looking forward to to seeing those.
Like you said, let's end on the React Server component side of things.
You said it's not yet fully uh start is not fully compatible with React Server components, but I've heard you say that you have some really fun ideas how to incorporate them.
So talk about that for a minute.
Yeah.
So um I've done a lot of playing around and research proofs of concept with RSC's.
In fact I have I have local branches on my machine where RSC's are mostly working.
Uh I say mostly because there's still some things missing and they are really fun.
So let me tell you my philosophies on React server components.
I'm going to start by saying that I think they were named incorrectly.
server components.
React server components is a bad name.
They should have been called pre-rendered components or serializable components.
Hey, they don't they don't sound as good, but whatever.
The reason I say that is because server components, they don't just happen on the server.
They just they just happen before the client is really what it is or just in a different place than the client.
And Dan Abramov gets into this a little bit.
You know, that there's two Reacts, right?
There are there's there's the React that's running on the client and then there's the React that's running everywhere else.
It's not really I mean, yeah, it's going to be a server a lot of the time, but it could be uh it could be your local machine statically deploying something or statically pre-rendering something or you could even you could even run RSC's in like a worker if you wanted like in a web worker or something
things that I think are going to actually elevate the experience of building an application and w with regards to routing.
Awesome.
I'm definitely I'm looking forward to to seeing those.
Like you said, let's end on the React Server component side of things.
You said it's not yet fully uh start is not fully compatible with React Server components, but I've heard you say that you have some really fun ideas how to incorporate them.
So talk about that for a minute.
Yeah.
So um I've done a lot of playing around and research proofs of concept with RSC's.
In fact I have I have local branches on my machine where RSC's are mostly working.
Uh I say mostly because there's still some things missing and they are really fun.
So let me tell you my philosophies on React server components.
I'm going to start by saying that I think they were named incorrectly.
server components.
React server components is a bad name.
They should have been called pre-rendered components or serializable components.
Hey, they don't they don't sound as good, but whatever.
The reason I say that is because server components, they don't just happen on the server.
They just they just happen before the client is really what it is or just in a different place than the client.
And Dan Abramov gets into this a little bit.
You know, that there's two Reacts, right?
There are there's there's the React that's running on the client and then there's the React that's running everywhere else.
It's not really I mean, yeah, it's going to be a server a lot of the time, but it could be uh it could be your local machine statically deploying something or statically pre-rendering something or you could even you could even run RSC's in like a worker if you wanted like in a web worker or something
like that.
But at the end of the day, really what it is is you're just taking a bunch of React component code and you're rendering it to string.
And you can't do that totally on the server without running into some problems around suspense and running into problems around client components that are using interactive hooks.
So what happens is it's more like it's a partial application of the rendering process.
It says we're going to render as much as we can of this React component here.
And for the things that we can't do, we're going to leave them alone and we're going to ship the the rest of the work down to the client or wherever it's going to get rendered.
And you can finish the rest of the work there.
And to do that, they have to take the rendered element and they have to serialize it into something that can be streamed somewhere else.
And it has to support streaming because of suspense which is really cool.
So everybody's been looking at React server components as if that's kind of the primitive the server component.
Everybody likes to say that.
What is a server component is really it is it is a stream of text.
That's all it is.
it it is an iterable.
Like if we're talking TypeScript types, it is an iterable of string that you are shipping somewhere else that's going to be incrementally read back out.
And you just need the tools on the other end to transform that stream of text back into React elements.
Some of those are going to be HTML elements that are just really easy to convert back into React components, but some of those are going to reference client components where you're going to need to say, "Oh, this is a button.
" So, we need to import the button code and when it's ready, we'll render the button as we're kind of bringing it back out of this serialized
But at the end of the day, really what it is is you're just taking a bunch of React component code and you're rendering it to string.
And you can't do that totally on the server without running into some problems around suspense and running into problems around client components that are using interactive hooks.
So what happens is it's more like it's a partial application of the rendering process.
It says we're going to render as much as we can of this React component here.
And for the things that we can't do, we're going to leave them alone and we're going to ship the the rest of the work down to the client or wherever it's going to get rendered.
And you can finish the rest of the work there.
And to do that, they have to take the rendered element and they have to serialize it into something that can be streamed somewhere else.
And it has to support streaming because of suspense which is really cool.
So everybody's been looking at React server components as if that's kind of the primitive the server component.
Everybody likes to say that.
What is a server component is really it is it is a stream of text.
That's all it is.
it it is an iterable.
Like if we're talking TypeScript types, it is an iterable of string that you are shipping somewhere else that's going to be incrementally read back out.
And you just need the tools on the other end to transform that stream of text back into React elements.
Some of those are going to be HTML elements that are just really easy to convert back into React components, but some of those are going to reference client components where you're going to need to say, "Oh, this is a button.
" So, we need to import the button code and when it's ready, we'll render the button as we're kind of bringing it back out of this serialized
state.
That's all RSC's are.
And so when I talk to people about React server components or just server components in general as a concept, I like talking about iterable strings and then the utilities to serialize that and then bring it back to life on the client.
That's all it really is.
Where I have interesting ideas I think around this is that when you when you boil things down to just primitives like an iterable string, I like that because now you can start thinking about it from a primitives first approach.
Now, RSC's, React server components are just another form of data that you're getting from the the back end.
It could be JSON.
It could be whatever.
Like I I'm going to say I'm going to say it again.
It's just server state.
Like for those of you who have gotten into React Query or test query mind, it's just server state.
It really is.
Or just ser state that came from your server.
And if we know anything about server state, it's that there's lots of challenges with managing server state.
That's what React Query was built for.
You run into challenges of staleness.
You have to invalidate.
You have to track dependencies.
You have to be able to uh scope things down to invalidate only certain portions of it, right?
And it it gets a lot into caching.
Like I haven't heard of anybody talk about this yet.
How can you cache a React server component?
I I think a lot of people would be like I mean my first reaction was you cannot cache an element.
How do you cache a React element?
You know you would have to serialize it into what?
An iterable string the string right?
So in a way I'm looking to approach React server components from this p perspective where we already have great tools at Tanstack to manage and wrangle and and not just control server components but like
That's all RSC's are.
And so when I talk to people about React server components or just server components in general as a concept, I like talking about iterable strings and then the utilities to serialize that and then bring it back to life on the client.
That's all it really is.
Where I have interesting ideas I think around this is that when you when you boil things down to just primitives like an iterable string, I like that because now you can start thinking about it from a primitives first approach.
Now, RSC's, React server components are just another form of data that you're getting from the the back end.
It could be JSON.
It could be whatever.
Like I I'm going to say I'm going to say it again.
It's just server state.
Like for those of you who have gotten into React Query or test query mind, it's just server state.
It really is.
Or just ser state that came from your server.
And if we know anything about server state, it's that there's lots of challenges with managing server state.
That's what React Query was built for.
You run into challenges of staleness.
You have to invalidate.
You have to track dependencies.
You have to be able to uh scope things down to invalidate only certain portions of it, right?
And it it gets a lot into caching.
Like I haven't heard of anybody talk about this yet.
How can you cache a React server component?
I I think a lot of people would be like I mean my first reaction was you cannot cache an element.
How do you cache a React element?
You know you would have to serialize it into what?
An iterable string the string right?
So in a way I'm looking to approach React server components from this p perspective where we already have great tools at Tanstack to manage and wrangle and and not just control server components but like
exploit their uh strengths tfold.
you know, we already have the capability to cache them and to persist them to disk and bring them back to life.
We have the ability to move them around, push them through a router, push them through query, you know, we could stream them into a table.
Like, we could do all of these things that we need to do because we've already built the utilities to do it.
So for instance with tan stack start the way that you're going to use a server component is it's going to be a server function or an API route really any anywhere that there's a network io boundary and if you return jsx or an element you have created a server component and that's it and on the client you will receive a stream of text an iterable of text like of the string and we will give you the utility that you need to convert that back into a React element to to render.
It's that simple.
But before you do that, you can pipe it through the router.
You could pipe it through query a persist.
You could pipe it anywhere that you want and we'll have everything in place to be able to cache it and manage it and invalidate it.
See, Nex.
js, JS they support RSC's but everybody so far has just taken you know the approach of well if you if you need to get new content from your server that's a react server component you have to invalidate everything right well we we already have granular invalidation with react query um and dependency tracking and management so if you put your RSC's through react query you get granular invalidation for free yeah I'm looking forward to seeing that to seeing like different approach to to server components that is not influenced by Nex.
js just taking them like I don't know 3 years ago and almost making it their own concept.
Thank you Tanner.
In
you know, we already have the capability to cache them and to persist them to disk and bring them back to life.
We have the ability to move them around, push them through a router, push them through query, you know, we could stream them into a table.
Like, we could do all of these things that we need to do because we've already built the utilities to do it.
So for instance with tan stack start the way that you're going to use a server component is it's going to be a server function or an API route really any anywhere that there's a network io boundary and if you return jsx or an element you have created a server component and that's it and on the client you will receive a stream of text an iterable of text like of the string and we will give you the utility that you need to convert that back into a React element to to render.
It's that simple.
But before you do that, you can pipe it through the router.
You could pipe it through query a persist.
You could pipe it anywhere that you want and we'll have everything in place to be able to cache it and manage it and invalidate it.
See, Nex.
js, JS they support RSC's but everybody so far has just taken you know the approach of well if you if you need to get new content from your server that's a react server component you have to invalidate everything right well we we already have granular invalidation with react query um and dependency tracking and management so if you put your RSC's through react query you get granular invalidation for free yeah I'm looking forward to seeing that to seeing like different approach to to server components that is not influenced by Nex.
js just taking them like I don't know 3 years ago and almost making it their own concept.
Thank you Tanner.
In
this episode we've been talking mostly about your road in uh about your journey in open source over the past I don't know like 15 years or something like that.
Uh thank you so much for all of your contributions.
Yeah, I'm sure many of our listeners and viewers already know who you are from your work.
Hopefully, right now they can see you in person on the screen.
Can you maybe last few words about how can people contribute, get in touch with you?
What would you like them to to see to watch from from your Tanstack ecosystem?
Sure.
If you have nice things to say, uh you can just get on Twitter or or X or whatever.
I'm on there.
Uh I'm also on other social networks, but not as much.
But you can talk to me anywhere you want to talk to me.
If you have not nice things to say, then you can jump on Discord.
You can DM me in Discord anytime.
We have a Tanstack Discord.
If you go to tansack.
com, there's a link uh in the sidebar for Discord.
Um we've got a really healthy community there.
I think 6,000 people at any given moment.
There's 600 people on there ready to chat about Tensac stuff.
Um, and you can you can talk to us in there.
If you want to contribute, that's the best the best place to start.
There's plenty of people with questions about how to build things with Tanstack Start and what to do and best practices and you that's where everybody who is a contributor now to Tanstack start or Tanstack query or whatever, that's where they started.
TK Dodto started in Discord answering questions.
Same thing with everybody else.
So yeah, if you want to contribute, then come hang out.
Thanks a lot again.
Thanks for uh joining me on this show and uh see you around on conferences and online.
I can't wait.
Bye.
React Universe Conf just dropped
Uh thank you so much for all of your contributions.
Yeah, I'm sure many of our listeners and viewers already know who you are from your work.
Hopefully, right now they can see you in person on the screen.
Can you maybe last few words about how can people contribute, get in touch with you?
What would you like them to to see to watch from from your Tanstack ecosystem?
Sure.
If you have nice things to say, uh you can just get on Twitter or or X or whatever.
I'm on there.
Uh I'm also on other social networks, but not as much.
But you can talk to me anywhere you want to talk to me.
If you have not nice things to say, then you can jump on Discord.
You can DM me in Discord anytime.
We have a Tanstack Discord.
If you go to tansack.
com, there's a link uh in the sidebar for Discord.
Um we've got a really healthy community there.
I think 6,000 people at any given moment.
There's 600 people on there ready to chat about Tensac stuff.
Um, and you can you can talk to us in there.
If you want to contribute, that's the best the best place to start.
There's plenty of people with questions about how to build things with Tanstack Start and what to do and best practices and you that's where everybody who is a contributor now to Tanstack start or Tanstack query or whatever, that's where they started.
TK Dodto started in Discord answering questions.
Same thing with everybody else.
So yeah, if you want to contribute, then come hang out.
Thanks a lot again.
Thanks for uh joining me on this show and uh see you around on conferences and online.
I can't wait.
Bye.
React Universe Conf just dropped
Timestamps
Show
Guests
Tanner Linsley
Owner
@
TanStack
In this episode, Łukasz Chludziński talks with Tanner Linsley—creator of TanStack and co-founder of Nozzle.io—about the evolution of his open-source libraries, starting with React Table and React Query and leading up to TanStack Router and TanStack Start. The discussion focuses on the real technical problems these tools were designed to solve and how they fit into modern application architecture.
Tanner explains why being framework-agnostic, headless, type-safe, and dependency-light matters—not just for developer experience, but for long-term maintainability and business flexibility. He also discusses the trade-offs of client-side and server-first approaches, and where TanStack Start fits into that conversation.
From solving internal pain points to influencing frontend architecture
The conversation begins with Tanner’s early development experiences and how practical needs at Nozzle led to building React Table, React Query, and other libraries. These tools weren’t created in isolation—they emerged from specific challenges around data synchronization, state management, and user expectations in real production apps.
React Query came out of a need to manage stale and shared server state more effectively than Redux allowed. Similarly, TanStack Router began when Tanner hit architectural limitations in React Router and needed better control over state stored in URLs. TanStack Start brings these ideas together into a full-stack solution that still keeps the client-first model front and center.
What makes TanStack Start stand out
TanStack Start adds full-stack capabilities like SSR, server functions, and API routes on top of TanStack Router, without forcing a server-first model. Applications built with a client-side mindset can gradually adopt server-side features as needed. This is especially useful for teams migrating incrementally or maintaining large existing React apps.
Tanner also shares his thoughts on React Server Components. Instead of following Next.js’s approach, he proposes treating them as another form of server state—something that can be streamed, cached, and integrated using TanStack Query.
Key discussion points in the episode
- Why open-source libraries are best built on real-world use cases
- How React Query reframed the conversation around global state by introducing the client/server state split
- What headless, type-safe design means in practice, and how it reduces support complexity
- The thinking behind framework-agnostic cores and adapters for React, Solid, Angular, and more
- A practical model for working with React Server Components using TanStack tools
Learn even more about the TanStack ecosystem
- Łukasz Chludziński on X, Bluesky, and GitHub
- Tanner Linsley on X and GitHub
- Tanner’s blog
- TanStack documentation
- TanStack on GitHub
- TanStack Discord community
Need help with React or React Native projects?
We support teams building scalable apps with React and React Native.
Let’s chat
//
Insights
Learn more about
React
Here's everything we published recently on this topic.
//
React
We can help you move
it forward!
At Callstack, we work with companies big and small, pushing React Native everyday.
React Native Performance Optimization
Improve React Native apps speed and efficiency through targeted performance enhancements.
Code Sharing
Implement effective code-sharing strategies across all platforms to accelerate shipping and reduce code duplication.
Web App Development
Build a solid foundation that meets latest standards and scales easily to other platforms in the future.
Next.js Development
Use Next.js to build fast, SEO-friendly web applications with server-side rendering at the edge.
