So that's where a lot of like the Tan Stack libraries kind of began.
We needed a table library. I built one pretty much a year ago.
I went full-time doing Tan Stack and I was good at it and I liked it.
But it wasn't something where I was like, oh, this could be my career.
I found myself building websites in college to make money to pay for school
where I was studying to be an audio engineer.
And he's like, you'll have so much more fun.
And he changed my major. He didn't even ask me. He just did it.
It wasn't until React came into the picture that things really took off for me.
I worked at a third-party Apple retailer called Simply Mac.
So I worked at the Genius Bar and just fixed everybody's MacBooks.
Can you give us the backstory of where the idea of the Tan Stack or the React query came from?
People don't really know this or remember this, but I've already built a framework before.
It was called Jumpsuit and I built that with Jason Mauer.
This was around the same time that Gatsby and early Next.js was taking off.
And in those early days, I actually was competing very heavily with Next.js and Gatsby
on static site generation.
That's when React query started because I was in the thick of it with Redux
and we were managing a lot of data on the client.
There were points where we were loading in just hundreds of megabytes,
sometimes up to a gig of data.
Can you give the story from when the React query got popular
until the Tan Stack was a full stack framework?
I needed to set up the open source organizations so that it could be cross framework
and agnostic to framework because at that time everything was React something.
React query, React table.
So I decided to rebrand under Tan Stack.
It's taken a full-time job at Tan Stack to really dig in and build Tan Stack start.
What do you think the Tan Stack will do the best job for something specific, for example,
building a specific type of website or application you need the Tan Stack for?
Like I saw a meme where people or company are making money using open source software
and the people that are maintaining or contributing to the open source software are not getting paid enough.
Because the reality is that most open source packages are not maintained by large numbers of people.
Usually it's just one to a few people who are doing 99% of the work.
Even with company sponsorships and GitHub sponsors,
you know, it just never was going to bring in enough to consider it full-time.
I've been designing the sustainability model for Tan Stack for a decade,
trying to figure out how I could make it work and for today for right now,
it's enough for me to be full-time on it, which is I think really impressive.
The project and you can tell from like a big company not even maintaining their own project,
nonetheless, someone not paid to be able to work on this project to be able to work on it.
And basically it's a lot of work behind the scenes.
When you are like a building open source project, it's like you are building a startup.
You are bidding on the success of the project.
Do you think it's worth to people who are just starting out to build
another framework to build like an open source project?
Do you think it's worth the time that you spend building that open source project?
Or do you think you should think twice before building an open source project?
If Fersell didn't have Next.js, I don't know if they would have grown as quickly
or if they would have gotten the exposure that they got.
I can't say that if somebody offered me $50 million right now that I wouldn't hand over Tan Stack,
it's hard to say because it's never happened.
It's like a Tan Stack right now is your baby.
So it will be hard for people to pull off your baby from you.
Very close to a release candidate.
I think it will be out this summer.
Hopefully.
Welcome, guys, to a Let's Go podcast.
A podcast we interview social media to share their entrepreneurial history.
And here we are on episode number seven of season number two.
And we have Tanner.
He is the co-founder of Nozzle and the owner of Tan Stack or React Query,
a package that's been used with over one million projects.
It's dependent on the Tan Stack with over two million MPM downloads.
Work at a French company and study digital marketing at Ota Valley University.
So let's catch up to learn more about Tanner's story after this interview.
If you are a Shopify app developer, you already know when you are checking your Shopify partner
or DashBlockout and you just see the install and the revenue.
But where is the real data?
For example, your monthly record revenue generates reattention.
You know the actual number that actually tell you if your app is growing or not.
And you think, I just need to set up a Google Analytics account.
Few weeks later, you are looking at custom events, Goal funnel and Dashboard
that break every time Shopify needs.
And you and your team should be focusing on building future and fiction bank
instead of becoming a Google Analytics expert.
And there is a better way of handling this using the sponsor of today's video,
Sass Insights, built by a Shopify developer who live this exact nightmare.
No complex setup needed or fragile tracking scripts.
Just plug it in and instantly get the metric that's matter.
All in one clean and no BS dashboard.
It's like having a growth co-founder who show up every day to just answer your question
and never sleep complain or eat your snacks.
It's affordable for Shopify.
So honor fully customizable for your specific needs.
Try it for free at SassInsights.com.
Thank you Tanner for accepting my invitation.
It would be a pleasure hosting you for today episode.
Can you give the audience more insight about your background so people who don't know
about you will know more about you right now.
Absolutely.
I've been building software for since like 2008.
So quite a while.
But I've only been in JavaScript for probably about 12 years.
And that's where I've spent most of my time over the last decade.
Almost.
I think it was 2013, 2014.
I started a company with some friends and it was called Nozzle.
And we we built marketing software and tracks Google keywords.
We actually use Google servers to do this, which is funny.
But we we crawl Google.
We store that data and we sell that data back to you know SEO teams and marketers
and provide them with you know the tools to kind of sift through that data because
we gather quite a bit of it.
So over those 10 years I was the only front end dev on the on the team.
And it took a lot to like figure out how to build an app by myself that would scale to
serve these enterprises.
So that's where a lot of like the tan stack libraries kind of began.
We needed a table library.
I built one.
We had a lot of like client side heavy data fetching.
I built query.
We needed better routing between all of our dashboards and drill throughs.
So I started working on the router.
So yeah, it was kind of ground zero for a lot of the pain points that I experienced
building tan stack.
And then about a year ago, a little pretty much a year ago, I went full time doing tan stack.
And for the last year, we've been heads down working on tan stack start.
I have for which is the kind of it wraps around tan stack router to turn it into a full stack
frame. That's been a difficult challenge like building a full stack framework is as people
say or hopefully realize is rot with peril.
So it's been really difficult, but it's been fun.
Tan stack.com has been running on our either our alpha or beta version of tan stack start
for a little over a year now.
We're getting close to a release candidate.
Awesome.
So thank you for the action.
And I would love to start our conversation with the first question that I already asked
which is will be like a flashback of how the first interaction with computer and how was
the passion of being a web developer or a software engineer came from.
So how was your experience with that?
Well, I mean, we had computers since I was a kid.
And we mostly liked them for games.
I played a lot of I played a lot of like educational games.
I mean, they weren't amazing, but they were good for the time.
So I played a lot of like educational games growing up.
I remember my mom and dad buying lots of these like cheap
educational games for like Windows 3.1.
So that was my first experience with computers.
I really got into it when we got the internet and my brother showed me how to download
music with Napster.
And I was just like, wow, this is crazy.
So I was a pirate there for a little while as well, little pirate youth.
We hadn't really thought about the implications of IP or anything like that.
So we just kind of downloaded everything.
And interestingly enough, that kind of led me towards software because
it was really easy in the early days of the internet to get pirated versions of
high quality software that would have been otherwise too expensive to buy.
I didn't know how to use very much of it.
But I tried Photoshop and I got into some illustration software.
And then eventually I got into music software.
I started doing a lot of music.
So I played the piano and the guitar and the drums and what have you.
And I was kind of an amateur audio engineer growing up.
And that's really what got me interested in computers a lot.
I took a web development class in high school when I was like 16 years old.
And I was good at it and I liked it.
But it wasn't something where I was like, oh, this could be my career.
I loved music.
I wanted to be a studio engineer or I even wanted to get into film for a while.
I went to college for like a year and a half of film school.
But at the end of the day, I found myself building websites in college to make money
to pay for school where I was studying to be an audio engineer,
which just felt backwards.
So when I started running out of money, I was like, oh man, I need to make more.
So I started building websites.
And one of my professors in my department was like, what the heck are you doing?
Actually, I was able to meet him again just this last month at Epic Web Conf at Kent's
Epic Web Conf here in Utah.
But we were recounting this story where he said, what the heck are you doing?
You know, you shouldn't be doing audio engineering.
He's like, well, you can, you'll love to do that as an adult, as a hobby.
But that's not how you're going to make money.
He's like, you need to be a software engineer.
And I said, I don't know about that.
I don't think that doesn't sound fun.
And he's like, you'll have so much more fun.
And he changed my major.
He didn't even ask me.
He just did it.
And so I studied software engineering for the rest of my three and a half years at school.
And ever since then, I just got really into it.
I had always wanted to build an app.
I think anybody who grew up, who was growing up when the iPhone came out and apps became
a big thing, it's kind of ingrained in you that you want to build an app, right?
I wanted to build an iOS app forever, but I did not want to learn Objective-C.
So when I heard about this thing called Ionic, and this was 10 years ago,
Ionic was cool because I was like, whoa, I can ship this application to the iOS App Store,
but I can use web technology to do it, which I didn't know a whole lot of JavaScript at the
time. It was mostly PHP and the WordPress ecosystem and just my SQL.
So I started learning JavaScript and Angular just so that I could ship a web app inside of Ionic
to the App Store.
And I did that.
I built my very first app was an Ionic app using Angular 1.x.
And it was a blast.
I was hooked after that.
So after I learned Angular, I was like, this is really fun.
Front-end frameworks are very fun.
I went back and I dabbled in a couple of others.
I looked at Backbone and Ember and kind of learned more about those.
And then I got really into just learning JavaScript.
And ES6 stuff was starting to kind of come out at the time.
But yeah, it wasn't until React came into the picture that things really took off for me.
In fact, I remember being at the same meet-up as Kent here in Utah.
Actually, we always attended kind of the same meet-ups.
So I was at the first, the one where he gave his first talk about his Gini library.
I was at the second one where he talked about Jots, JWTs, and he actually got heckled.
And he defended himself very well.
And then I remember the one too where we were all presented about React for the very first time.
And people were using React inside of Angular, which was weird.
But once that came onto the scene and we started learning about React,
things really changed because that's when I started getting into open source really deeply.
I started looking into building my own open source packages.
That's also around the same time that I got involved in ChartJS,
which I was a maintainer on ChartJS for a couple of years in the early days.
Makes sense.
That's the full picture.
And you mentioned that this is the electronic science in the University of Utah,
because in the LinkedIn, you study the digital media at Utah Valley University.
Is that right?
Yeah, so back in, let's see, back in 2013 or whatever, it was called digital media.
And then you would have a focus on something.
Okay, it makes sense.
And they actually didn't have, they didn't even have a web development track.
And they definitely weren't teaching new web development stuff.
They were teaching PHP, they were teaching C-sharp classes.
It was kind of a crossover between digital media and design and traditional IT and software.
So the digital media part of it, I learned about accessibility,
and I learned about the design aspects of it as well.
But then we had some pretty hardcore programming principles classes that
were uncomfortable for a lot of design people.
But yeah, that's where, so it was at Utah Valley University is where I kind of finished out.
I did my first semester, I did my first two semesters at BYU actually, I'm doing film.
Yeah.
And then in between BYU and Utah Valley University, I served a mission for the Church
of Jesus Christ of Latter-day Saints for two years in Brazil.
So that was a little bit of a hiatus on education, but well worth it.
Very awesome.
Yeah, it makes sense.
Got the point.
That's great.
And also, like you mentioned that this is the time that you involved into open source,
and one of the, you have been maintaining a charge JS library.
And during that time, you work like, you wouldn't work in like material part time,
as I mentioned, or like as I imagine.
And you have been working maybe in less simply Mac or like what was like your full-time position
back then when you are maintaining the charge.
That was even before all that.
Before I got into even building apps, I was, I worked at a third-party Apple retailer called
Simply Mac.
So I worked at the Genius Bar and just fixed everybody's MacBooks all day, which was fun.
That was great.
But my first job I got because this guy came into Simply Mac and was like, hey,
I need a website.
And I was like, oh, I know how to build websites.
And he's like, oh, yeah, if you can build this website with all this functionality
in the next two weeks, I'll give you a job.
So I built it in three days.
I delivered it to him and he gave me the job.
So I worked at this scrapbook.
It's a scrapbook publishing company for a little while.
And pretty soon, the guy who gave me the job, he moved on to something else.
Started a new company and he promoted me to the VP of technology at that company.
And I worked there for a year doing everything, but mostly PHP, a little bit of WordPress.
That's when WooCommerce was hot.
We were using a little bit of WooCommerce.
And then I think I worked there for like a year and a half.
And then they decided to sell the company.
And I was looking for a new job like immediately.
And that's when I met my friends who helped, who kind of helped me get into React.
And they were the ones that I started nozzle with.
So they found me at a meetup and they're like, hey, we're starting a new company.
Why don't you come and be our front-end guy?
And I was like, okay, cool.
I worked at SEO.com with them for a short little while before we actually started the company.
And then six months into starting the company, they made me a co-founder.
So actually started as an employee first and then became a co-founder later.
Got.
Oh, okay.
Makes sense.
So I got the full picture right now.
And we covered like a good ground for the timeline of like your story.
And currently I would love to dive deep into the dance tag and how the idea came from.
What did you see in the market, like the gap in the market?
Because I remember it.
I think you are the founder of React Query.
Correct me if I'm wrong.
And like it started with React Query and after that it evolved to a full stack framework
to the dance tag right now that you are currently having to discuss the story behind
that full stack framework.
Can you give us the backstory of where the idea of the dance tag of
or the React Query came from?
Yeah, it actually didn't start with React Query.
The first library that I made was table, React table.
And I, so I built React table because I needed a data grid.
And when we moved to React, there wasn't a native data grid for React.
There were some that had wrappers like AG grid was there.
There were a few others, but none of them were like native to React rendering.
So I built React table as a component that would let you render really good tables.
And it took off.
And I think people really enjoyed it.
I liked it.
I used it at Nozzle.
And then let's see.
After React table, I started actually building, people don't really know this or remember this,
but I've already built a framework before.
It was called jumpsuit and I built that with Jason Mauer.
And we, we didn't work on that very long, but jumpsuit was like jumpsuit was actually
based around Redux and React.
And it wasn't full stack.
It was just a client side framework, but we thought it was pretty cool.
It didn't last very long.
Jason had other plans.
I was quickly getting tired of Redux, but at the time I wanted to,
I wanted to build a like a static site generator.
So we were building our marketing site for Nozzle and I was like, oh, we should do this
in React because I'm going to be the one who's maintaining it.
So I started building this framework called React static.
And it was a static site generator.
So this was before serverless was big before lambdas really took off.
So the SSR story for react was still very early and young.
It was very difficult to just spin something like that up on your own really easily.
Unless you were running a long running server that there just weren't frameworks for it to
make it super easy for everyone to consume.
So static site generation was the hot thing because of that.
And this was around the same time that Gatsby and next JS, early next JS was taking off.
And in those early days, I actually was competing very heavily with next JS and Gatsby on static
site generation.
And there was a brief little while there where like react static was the fastest react static
site generator out there.
I had figured out how to do parallel processing for exports, like multi-threading.
So the our ability to export was much faster than like Gatsby and next.
But it got to the point where it just it turns into a framework.
And other than having the server side part of it, it really was almost the same amount
of work that it is building a framework today.
We had to do custom code splitting using like react loadable.
We had to do weird things with CSS and import maps.
And it was really crazy.
It just became like a full time job, but I didn't want it because I already had a startup.
So I decided to give react static away to the community.
They ran with it for a little while, but I went back to just focusing on writing stuff for nozzle.
And that's when react query started because I was in the thick of it with Redux.
And we were managing a lot of data on the client.
There were points where we were loading in just hundreds of megabytes,
sometimes up to a gig of data.
And it was constantly being updated and cached.
And it just was really difficult to work with Redux to do that.
And so I built react query initially on top of Redux as a way to manage all of the state
and use it just internally inside of nozzle.
That worked really well and I liked it.
And so I was like, Hey, you know, I should open source this like I did my table library.
So I built and react static as well.
So I built it into an open source library.
And I just instead of using Redux, I just built my own store underneath
that was like specially designed for the task.
And that was the first version of react query.
So after that, it's kind of history.
It was the right place at the right time.
That's about the same time when react hooks came out.
And it was the perfect Zintax and platform for something like that to exist.
Makes sense.
So it's like a timeline.
It's where you start with react state static, which is an alternative to Godspeed
and next JS static site generator before the two like alternative come out.
So you are like the early adopter of static site related for react space application,
which is really good because I remember like at the time when Godspeed was very popular.
So there's a lot of hype or trend for static site generation.
I think remember maybe 2020 2021 was a lot of hype around that.
And after that, you move out to react query, which is like an easier way to use Redux
without the syntax of using Redux.
And it was great for like a network request.
So you can do a lot of network requests, especially with the use query and the other hooks.
And as you mentioned, it was the right time because you just made hooks before react hooks
was out from the team of like a meta.
It was at the right moment.
And so coming off the story, so you build react stages out of you would like to build
a static site for react and you build react query internally for the nozzle company
because you are like seeing a gap there and you build this.
And after that, you are open sources to the community and people love it.
And after that, react query got very popular and a lot of people use it and also like a big company uses
and after that you start building other layers.
That will become the 10 stack because the 10 stack have like other layer.
One of them is the react table and the react query and there will be other stuff
that will make a full stack framework.
Can you give the story from when the react query
goes popular until the 10 stack was a full stack framework.
So after react query got popular, I looked into a couple of other libraries that I needed.
So I wasn't happy with form libraries.
So I started working on 10 stack form.
It was just called react form back then and actually built it and used it for a while.
But I still wasn't happy with my own creation and actually killed off react form a couple of years ago.
I also built, let's see, I also built react ranger and react a new virtualizer library that was headless.
And those were those were really good.
It was around the same time too that so one of the first critical pieces too was I needed to
I needed to set up the open source organization so that it could be cross framework
and agnostic to framework because at that time everything was react.
Something react query react table.
So I decided to rebrand under 10 stack and rebrand all these libraries and restart
rewriting them or at least rewriting their cores as agnostic.
So just type script and then creating adapters for framework for specific frameworks around them.
So that was the first big step and that took a while.
We started I did that the very first one we did was 10 stack query and then we did table
and then we kind of did all the others after that.
So that was a first big critical piece was rebranding everything to 10 stack
simply because we needed a better name that didn't involve react something or view something or whatever.
I tried it for a little bit.
Actually, you might see like view query view table or whatever.
But I just didn't want to maintain, you know,
one brand for every library framework combination.
That's stupid.
So yeah, we rebranded under 10 stack.
And along with that rebrand and those rewrites, we also went really deep into type script.
So it took me a while to get on the type script train.
But once I did everything needed to be type script and type safe.
So we rewrote 10 stack query and table to be type safe.
And that took a while.
And then eventually when all of that was done, it was all under 10 stack.
It was all type safe and type script and framework agnostic.
I started looking into routing because it felt like the very last piece of nozzle
that was really not a great experience.
We were using react router at the time v5 and they were teasing v6.
I think v6 was in beta for like two years.
And we used v6 for those two years.
And it was much better.
It had a lot of good stuff.
But during that time, they were also building remix focusing on remix.
So it took a while for some of those features of remix to end up in the new v7.
So there was a long time where I was using remix for some side project stuff.
And I really liked it.
But I needed a better routing experience for my SPA like for nozzle.
And I was also running into some pretty big limitations with react router v6 beta at nozzle.
Mostly around like a lot of it was around types.
So it wasn't type safe at all really v6 was.
And then it also was just really it didn't have the API's that I thought
it should have had for managing state in the URL.
It owned the URL essentially for you know when you have a router it basically owns the URL.
And I was storing a lot of state in the URL with search parameters.
And even like hashes and just different things to make it so that people could sift through the data
and the dashboards that we had for them and share those links with their team.
And also bookmark them and come back and have everything look exactly the same.
So to do that you need really really good URL management.
And I just wasn't getting that from v6.
I tried extending it.
And I did actually built a bunch of custom router logic on top of react router six beta.
And it was it was pretty crazy what I was doing.
I got to the point where I was actually proxying every single export from react router beta six.
And I was like OK I basically have built my own version of react router.
I looked into doing some upstream contributions.
They were focused on other things they didn't they weren't really interested in type safety at the time.
They weren't interested in some of the search parameter APIs that I had designed.
So at that point it was either fork or build something new.
Because I needed a little bit more control to kind of fully realize the tools that I had designed.
I wasn't going to get it with react router v6.
So I decided then to take all of my extra logic that I had and you know
replant it on top of a new core router.
And so I decided to build something called react location which was just a toy router
basically just for nozzle but I also open sourced it.
And it was kind of my first experience of learning how to build a router from the ground up.
And it wasn't great. I mean it was it was good.
It was fine. It wasn't the best router because I had learned I learned a lot doing that.
And I did I tried that tried I didn't really look at any other like routing implementation code.
There was water there's react router Gatsby was open source.
Next JS was open source.
I really didn't I really wanted it to be like my own interpretation of how routing is supposed to work.
So I built everything from the ground up.
I even built my own history management library.
Which was which is a lot on its own just a good history management library.
Other than the public APIs that I had worked with in these other libraries.
I didn't really know much about it.
So that first version of react location was that it was kind of my interpretation of how to build a router.
But I got really interesting when okay we started using that at nozzle and it was pretty good.
It gave me the runtime functionality almost that I needed.
But the type safety still wasn't there because I didn't know how to do a type safe router.
I had it was still a lot better than what I had.
But I it just didn't meet what it didn't match my expectations for what I was hoping to build.
I was still casting a lot of things.
And so that's when I set out and I started researching really heavily on how to do
like really complex type safe systems.
10 sec table is a pretty complex system.
But it doesn't have a lot of like hierarchical context.
Like a router does that spans an entire application.
So I had to do a lot of R&D to learn how to build a type script system that could span an entire app
and still be fully inferred.
And so that's where you see kind of the the interesting structure and syntax of like tan stack router.
That's where that was born was in this research.
And it took a while to figure out.
But once I figured that out that's when I started the really long journey
of building tan stack router and ultimately tan stack start.
So honestly can't even remember the year because everything's blended together.
But I know that I've been I let's see.
Tan stack routers been out for a year and a half.
I worked on it for I worked on it for two years almost two and a half years before I before I released it.
So I've been working on routing for the last four and a half years.
Four to four and a half years.
And it's it's a really complex problem to solve.
But once I so the routers been out for a year and a half it's been stable.
It's fully type safe.
I think it was a really big moment for type safety that we were able to do that.
We had some interesting patterns that I'd never seen before.
I really do think it was pretty novel.
Um tan stack start.
So this is when it gets interesting to me because I didn't want to have to build a framework.
I really didn't I don't I had already done it once and I didn't like I didn't like the challenges
that it presented with react static.
And I knew it was going to be even harder this time around.
So I really didn't want to build a framework but I knew that I might have to.
So I already had the router and having the having a router is really 80 percent of
of the challenge of building a framework because you can't really build a full stack
framework without a router that can do both client side and server side.
So you'll end up there anyway.
I knew I was really close but there was going to be a lot more work to go.
But at this point building a full stack JavaScript framework based on the router
wasn't something that nozzle needed up to that point.
Everything else that I had built is something that we needed at nozzle.
But a full stack framework we didn't need that.
There's some things about it that would that would be helpful.
It would be nice to have but it wasn't necessary because
tan stack router with VIT was enough for what we had built.
You know we had we had a SAS application.
We didn't need SSR.
We just needed to render on the client and let people look at all these charts and dashboards
and stuff.
So that that came to a bit of a turning point there where I thought about building this framework.
I decided you know let's just dig back into nozzle.
But the people started using tan stack router to build enterprise applications.
The uptake the people who used the router there weren't it's not that many it's still not that
many today but the people who are using it are building very significant projects with it because
it's very nice to use if you're building big large enterprise applications with
really hairy URL management and things.
So you know the usage is not in the millions or anything yet but the people who are using it
are very sophisticated and the projects being built with it are are pretty intense.
And a lot of those people started asking me about a full stack framework.
They're like we would really love this.
We would use it if you built it.
I didn't even need to try it out to know that I had you know a product market fit or an audience
for it.
People just were telling me whenever you build a full stack framework I will use it.
So that was that was interesting to hear.
After I started hearing that for a while I had some some people approach me and we're just like
hey how can we help make this happen.
A couple of those companies were AG grid Vercel and Convex.
Those are some of my earliest sponsors and they wanted me to invest my time into this into this
project which was really awesome of them to do.
And so I struck a partnership deal with those three initially to kind of help me
transition to a full-time role doing TAN stack and not necessarily leave nozzle but definitely
I've taken a backseat and I'm not in the day-to-day at nozzle anymore just because of the time
requirements to work on TAN stack.
Um but it's taken it's taken a full-time job at TAN stack to really dig in and build TAN stack
start. Front and full stack frameworks are just no joke really really difficult.
Yep makes sense and I remember that I had an interview with Wes Boss over the season for the
podcast and we mentioned that TAN stack is one of uh like a he's like one of the framework that
he's currently working with as a full stack framework and you are competing right now with
like a Vercel with remix there's other like a full stack framework out there but how do you think
if you are like choosing a tool for the right job what do you think the TAN stack will do the
best job for something specific for example building a specific type of website or application you
need the TAN stack for? So I think the easiest way to answer that is to say that I think TAN
stack start and router are going to be great for most applications to be honest when by the time
we're done with it um there's not something that I wouldn't want to build with it because I I do
believe that it has the it's built on the best router out there it has the the best features
it's the most type safe it's really scalable for teams so there's not very many projects that I
would say I don't want to use TAN stack to build this um there are a few use cases where I would
say it's not the right fit one of those use cases would be if you are building a zero JS or a very
heavily progressively enhanced application so if you're targeting devices that you know are
probably not going to run JavaScript at all or you just don't want to run JavaScript at all
this is not this is not the framework to do that if that was your goal you should probably
look into something like astro something a little more static or you could look into even using
you know something like react router v7 which I know they have a really big focus on
progressive enhancement to be able to you know build an application that doesn't use really
JavaScript on the client at all which is really cool but that's just not our demographic that's
not what I'm that's not what TAN stack start or router is optimized for other than that use case
you know there's still there's still the use case around if you're building a very static
site that's not changing very much then you might be more comfortable with something like astro or
even wordpress you know because I just think that if you're not building dynamic application stuff
you're not going to you're not going to need a lot of the stuff that TAN stack's bringing
that is until we have uh rsc support so as soon as we add support for react server components
we're going to take back a lot of that use case to be able to do static stuff TAN stack.com is a
good example of a site that we've built it with TAN stack start to dog food it and it's been really
good using TAN stack start we're very happy with it and we've been able to do some really cool
dynamic stuff because of it but most of TAN stack.com is static it's just static documentation that
is changing every now and then and that's a perfect use case a natural use case for something like
astro or for react server components which we know we're not using astro and we don't have
server components yet but as soon as we do it really will just leave maybe a sliver of the kind
of that progressive enhancement area where I would say maybe not the best fit but for pretty
much everything else I I envision it becoming a really versatile tool to build pretty much whatever
you want. That's great and also I have a question so it's been a long time ago since I saw a meme
where people or like a company are making money like using open source software and the people
that are maintaining or contributing to the open source software are not getting paid enough do you
still agree with that as someone who has been contributing to open source software for a long
time do you agree with this statement or do you think it's not the same for everyone? I think
largely I would agree that there are I mean there's a lot of open source out there there's a
lot of open source libraries to be honest most of the industry only relies on a very very small
percentage of all of the open source out there there's very there's relatively very few packages
that kind of prop up our industry or even the back end languages and things like that because
there's just a lot of open source that's just out there for fun so I think there are a lot of people
who probably build hobby open source projects who wish they could do it full time and say man I wish
I got paid more I think I think there is a problem for packages that do prop up our industry those
maintainers are often putting in a lot of time more time than we realize to triage issues and
provide support and keep keep updating the libraries and those people are not being compensated enough
and it really wouldn't take much from our industry to make sure that these core people are propped up
because the reality is that most open source packages are not maintained by large numbers of
people usually it's just one one to a few people who are doing 99 percent of the work and so you
know if you think about it like if you pick one of your favorite libraries and you say okay who's
the person maintaining this library that's getting downloaded you know a billion times a month or
something like that that person could easily be be justified of making a six figure salary from
you know any any company in Fortune 500 or Fortune 1000 that uses that software otherwise
if that software dies it would crumble yes but that's the problem is that there there's no way to
like force that there's no way to um there's no way to enforce that on on either side so
the companies using it don't feel pressure to pay because it's just going to keep being free
and one of the biggest challenges with open source I think is that it's looked at as a commodity
so that if one library maintainer decides I'm done I'm not going to do this anymore
there there's a time period where that library will still keep working
but they'll have time to switch to something else and if a library maintainer stops maintaining
something it's going to immediately create room in the ecosystem for another person to come in
and build something to replace it so it very much is looked at as a commodity from a lot of companies
that use it to say if it's not this library it'll be another library and yet if we need to we can
switch but that's a that's a risk and a gamble they're willing to take that's what makes it really
difficult and as an open source maintainer there's very few ways that you can consistently
raise money and keep money coming in even just to sustain yourself I mean for the for the eight
years that I was doing open source on the side I never made remotely enough money at all to consider
doing it even part time I mean it was just it was almost nothing even with company sponsorships
and github sponsors you know it just never was going to bring in enough to consider it full time
it's not until you have an open source library that is popular enough and well known enough
and has a good brand behind it that you're able to start getting into brand and partnership deals
and marketing deals or or even even if you didn't do any of those and you just ran ads on your website
you still would need to have a really really popular library to make that worth it for you to
do it full time so I just think that the open source sustainability model has a lot of flaws
the fact that tan stack is working and that I'm I'm succeeding at doing that and sustaining it
did not happen overnight at all I've been I've been designing the sustainability model for
tan stack for a decade trying to figure out how I could make it work and you know I've seen companies
raise venture capital and then a few years later they die I've seen I've seen open source projects
raise venture capital and then get acquired which is awesome for them but then I've also seen
those acquisitions change their priorities and change their you know change their motivations
I've seen open source projects who decide to start building paid products or paid versions
of their open source that also changes your motivations and it changes you know do I work
more on the paid version or the open source version now and at the end of the day it's really
difficult to find a balance between how can I keep doing what open source should be which is
building free to use software that is supported by the community and has a good support behind it
that's always going to be free but still somehow make money it's been a real challenge to figure
that out but so far at tan stacks we've been able to do that and I'm trying to I'm trying to stay
true to the way that I feel about open source where I don't believe that you should take a thousand
dollars of open source sponsorship money and split it between a thousand people because like I said
usually one or two or three people are doing 99% of the work so at tan stack I try and do
things very differently where I have a set of core maintainers and contributors that I I really
really trust we have a big group of contributors and maintainers now at tan stack who basically
in their in their own right are the backbones of a lot of these libraries you know like Dominic
Dorfmeister TK Dodo he he is react query now you know and Kevin Kevin Van Cot he manages
tan stack table and he's building the next version of it so these these like champions
you know that come out of the woodwork to to say hey you know I I want to be a part of this
I'm trying to treat those individuals as partners and employees and part of the company
and making sure that I'm compensating them as well as much as I possibly can for for the work
that they're doing you know so a bulk in fact if you go to if you were to go look at all my
github sponsorships I have a pretty significant amount of github sponsorship money now coming in
but I don't I don't keep really any of that github sponsorship money all of that money
gets redistributed right back to each of my core contributors so I've been sponsoring each of them
for quite a bit for a while now and I and I can't wait to sponsor them for even more I mean if I
had my way I'd you know grab a couple more marketing partnership deals and you know employ
all of them full-time I would love to have a team of you know five to six people of full-time
engineers that we could just focus on tan stack hopefully we'll get there someday but right now
you know we're still trying to figure out the sustainability model and for today for right
now it's enough for me to be full time on it which is I think really impressive considering that
you know we haven't raised any venture capital we don't have any paid products and as far as I
as far as I think I think people really love tan stack products so as far as I know we can
just keep doing this forever you know we don't need to we don't need to scale to 50 employees
or become some unicorn company or raise money and get into AI we can just be you know a really
tight-knit group of open source engineers build great software and as more and more support and
money comes in we can sustain ourselves even more that's great so that's conversion is really
important because there's a lot of things that people should know about open source and also
talking about this like even like a big company that's have like a resource available to have their
own open source products if you like a go to their like GitHub repo you will see a lot of
and like a still open issue for like a quite some time so it's a lot of work for someone
who is not paid to be able to maintain a library so don't take it for granted and if you are using
the company like I did the library I think the best way is at least to sponsor the product so
the people that are behind that product can like at least get something out it will not like a be
like a rewarding number just will just like a small like appreciation token for what they are
doing because it's a lot of work behind the project and you can't tell from like a big company not
even maintaining their own product nonetheless someone not paid to be able to work on this
product to be able to work on it and basically it's a lot of work behind the scene and also
people when you are like a building open source project it's like you are building a startup
you are betting on the success of the project it's like a if the project is popular you will get
like a partnership you will get sponsors to be able to sponsor your work model of like a getting
a paid for example you can offer premium support or a paid support for technical support or also
you can offer some commercial license like for example I think like a remotion have source
available so the source is available but it's not open source so they can you can use it for free
if you are like as a one developer or like up to three developer if you are big you will shoot
like a pay for a license to be able to use it but the code is is there you can like contribute
and use it for your own but you should like a page be able to use it for commercial so there's a
lot of other ways we will get paid with your open source but it's always you are betting
on the projects if the product succeeds you will get paid if not it will be just a hobby
product and it will not be successful enough to be able to grab the attention of like a sponsorship
and the company to be able to willing to sponsor the product so it can work on it full time because
it's a lot of work to be able to maintain a product and like a much like a support for the people
who are making the product because it's a lot of work and it's and pay it unfortunately and also
one of the things that for example I think it was the first time that I heard that
an opportunity has been acquired which is the remix acquisition from Shopify in October 2023
I think from my I think I remember it was acquisition of Remix.js which is acquired by
Shopify so people can get like a work at Shopify and maintain the remix project
and this will lead me to a question about open source do you think this is the only like a solution
or like a available business model for open source to be alive for example we mentioned
premium support commercial license sponsorship do you think this is enough for people to work on
the project full time and what do you think or what listen that you learned over a decade working
on contributing to open source do you think it's worth to people who are just starting out to build
another framework to build like an open source project do you think is worth the time that you
spend building that open source project or do you think you should think twice before building
other projects so let's talk about motivations first I would say if you're building if you're
setting out to build an open source project because you want it to become popular or you want
your library to become popular or or you don't like another open source library and you just
want to be better than that one all of these reasons I think are there there okay reasons I
guess it they'll get you some of the way but I don't think that those reasons alone are enough
to get you to success mostly because if you're not building something that you that you need
then you're you're already going to fail you need to be building something that you deeply
understand and you need to be building something that you have that you know the pain points
and you've lived them or are living them and you should be building the tools that you want
and need at the moment for yourself you know we could go back to kind of the hammer manufacturer
analogy right um are you going to want to buy a brand new fancy hammer from a guy who has you
know not who hasn't swung a hammer for the last 10 years or are you going to want to buy
a new hammer it's that some guy designed who is currently building things all the time with it
and who understands the ins and outs and the challenges right so I think that's kind of the
first indicator of motivations and success that you need to be aware of is you need to look at the
motivations behind a library look at you know why it's being built why you're building it and if
it's not to help you build better things or or genuinely to help other people build better things
easier then the motivations are kind of out of whack I would question that um and that that fuel
if it's not one of those things then the fuel that you have will only get you so far you know
once once your library does get popular you're going to say okay problem solved my library is
popular or once you push out the you know the incumbent it's like okay I won and then you just
stop right there's no more motivation to keep going and keep making it better so make sure you're
using your tools and building tools out of necessity and not out of uh you know grandeur or spy or
whatever to answer your other question I I don't think that I think this was your first question
I don't think that acquisition um the only way out of you know open source sustainability
issue in fact I think it should probably be looked at as the the rare occurrence you know
next J.S. was built internally at Versailles it wasn't acquired next J.S. was built as an
open source utility for people to use that happened to be owned by a hosting company
and they they made it really easy for you to build and host kind of in one fell swoop which
is really awesome like that's why it has succeeded so well is because it's so easy to go from zero
to shift immediately they didn't acquire next J.S. though so that's that's something to be aware of
and remix getting acquired by Shopify awesome for them uh I know that before they got acquired
it was it was going down a route that looked difficult they weren't sure how they were going
to monetize they had previously looked into paid licenses but the future was uncertain and the fact
that they that they did get acquired by Shopify I think is a a genius stroke of of luck that Shopify
needed or wanted exactly what they were providing in that moment and they were able to to strike a
good deal that also I think Shopify has mostly been a good steward of of remix which um that's not a
guarantee I would say that most of the time I would wager that if a company big enough to acquire a
large open source product is interested in buying it usually there's going to be motivations behind
that acquisition and Shopify's motivations were technical I think a lot of it was technical where
they wanted to bolster you know the Shopify uh engineering story around building their
applications but I don't think that that would be the case for a lot of acquisitions that could
happen I think most of the time you would see oh yeah we're going to buy this open source library
that's really popular and then we're going to try and exploit or those users to buy our product
somehow right and Vercell doesn't do this with Next.js but but it does it does have a little
bit of crossover where Next.js is a big reason of why Vercell is successful because it is a massive
lead generation tool for Vercell right if Vercell didn't have Next.js I don't know if they would have
grown as quickly or if they would have gotten the exposure that they got right or would have been able
to hire the talent that they have been able to attract because of Next.js so it's it's a two-way
street yeah it's a two-way street it goes both ways but it's easy to look at at something like
remix or look at Next.js and say oh that's that's the way that it should be done in reality I think
that the the idea of having an open source company that doesn't need venture capital and doesn't need
to be acquired and can generate its own revenue through brand deals and brand partnerships that
hasn't really been explored a whole lot and that's what I'm doing right now the way I look at it is
there are Instagram and TikTok accounts out there that are making tens of millions or hunt you know
many many millions of dollars a year just by being very popular and by doing being really smart about
their partnerships and their brand marketing efforts and their advertising if TikTok and Instagram
accounts can do that there's really no reason why an open source library couldn't do it either
and in my opinion I think it's because many developers and software engineers are just
not great marketers and they're not great salesmen I would say that if you're going to get into open
source and you know that's what you want to do as a full-time job for a really long time you need to
become a better marketer and you need to become a better salesman you need to learn about SEO
you need to learn about your users and how to understand them and you need to learn how to use
these tools in a good way like in an ethical way right you're not you're not supposed to exploit
your users you're supposed to be useful to them in some way and I'd say like right now
we have amazing companies that are that are partnering with Tanstack who are not just there
to just sell whatever to our users right these are companies that are that have built amazing
products that are actually helpful who also they have the they have the best interests of our
developers in their minds as well and we're not ramming though those companies down our
users' throats we are just trying to make sure that people are aware of great tools out there
that we trust and that we use ourselves and so that's an avenue that I'm exploring right now
it's very new to our industry I think to open source the idea that I have refused to ever
build a paid product or ever take venture capital money or otherwise sell out I think is pretty foreign
to some people so far so good we'll see I can't say that if somebody offered me 50 million dollars
right now that I wouldn't hand over Tanstack it's hard to say because it's it's never happened
but I can't say that it would it would take a lot to pull Tanstack away from me right now
personally mostly just because there's still so much to do you know there's still so many
things that we could build and make that I would I would not just want to stop right now so until
I'm satisfied that there's nothing left to build Tanstack is going to stay where it is and funded
how it is so that's great it's like a Tanstack right now is your baby so it will be hard for people
to pull off your baby from you yeah absolutely that's great so I have a I have two questions right
now because it would be the last part of the podcast episode so the first question you will be
you mentioned that you are working on some future that's like for the Tanstack if you might change
some of them if and the second question you will be what are the lessons that you learn
over a decade of contributing to open source all right so the short version of kind of the
roadmap for Tanstack is we are we're trying to get Tanstack start released it's very close to a
release candidate I think it will be out this summer hopefully summer of 2025 once Tanstack start is out
personally I want to go back to Tanstack router and add some more features that I've been wanting
mostly parallel routes and a couple of others things that I think Tanstack router really needs
parallel to that we have other projects that are happening that you know I I'm now no longer the
only person building libraries at Tanstack Kyle Matthews from Gatsby who is now a co-founder
at electric sequel has been working on a new library called Tanstack DB that I'm really excited
about and Tanstack DB builds on top of Tanstack query and it gives you like the local first
sync experience for the client now it doesn't fulfill all of the needs that you would need for
a sync engine on the server side but if you could think of it it's like the it's like the
Tanstack query for sync engines it's the client side part of it that is agnostic and can work with
anything you just need the right adapters to hook up to it and you can have a local first sync engine
for inside of your application very very cool stuff I would definitely keep your eye on that
in other news so Kevin has Kevin van Caat has recently released Tanstack Pacer which is like
debouncing throttling queuing utilities and Tanstack Pacer is a pretty interesting library
it's kind of our first utility library but I would keep an eye on that one we're also working on
Tanstack select which is a headless select picker experience so if you could imagine something like
aria complete or even downshift but just way more feature packed and headless
kind of the end and works across every single framework so we're working on Tanstack select
and then a little much further out probably is Tanstack time which is going to be our take on
time manipulation UI library so we are building Tanstack time to help you build UI experiences
that deal with time so date pickers date range pickers calendars scheduling systems
anything that and it's going to all be headless so you could use Tanstack time as a primitive to
build out like your own calendar widget or