Sponsored by
Show notes
Transcript
0:00:00 Intro
0:00:00 My perspective on localf-first is that,
I think ideally every developer would
0:00:06 love to be able to interact with their
APIs as if they were localf-first.
0:00:11 and then I say that not necessarily
meaning like offline, but just , I
0:00:15 synchronously did this thing and
I can trust that it's going to
0:00:17 be persisted where it needs to
be persisted and then move on.
0:00:22 and just kind of feel like
everything gets instantaneous.
0:00:24 So, I have no doubts that
that is what everybody wants.
0:00:28 It can be difficult to get there.
0:00:30 and if you try and get there too
quickly, I know you can get into some
0:00:34 trouble and there's really smart people
who are slowly trying to carve out
0:00:38 this space and make that a reality.
0:00:40 Welcome to the localfirst.fm podcast.
0:00:42 I'm your host, Johannes Shickling, and I'm
a web developer, a startup founder, and
0:00:46 love the craft of software engineering.
0:00:49 For the past few years, I've been on a
journey to build a modern, high quality
0:00:52 music app using web technologies, and
in doing so, I've been falling down the
0:00:56 rabbit hole of local first software.
0:00:59 This podcast is your invitation
to join me on that journey.
0:01:03 In this episode, I'm speaking to
Tanner Linsley, creator of the TanStack
0:01:07 Ecosystem, including projects such
as React Query and TanStack Router.
0:01:11 In this episode, we talk about the
newest Project TanStack DB and explore
0:01:16 the problems it's trying to solve and
how it works before getting started.
0:01:20 Also, a big thank you to Jazz
for supporting this podcast, and
0:01:24 now my interview with Tanner.
0:01:26 Hey Tanner, it is so awesome
to have you on the podcast.
0:01:29 How are you doing?
0:01:30 I'm doing great.
0:01:31 Thanks for having me.
0:01:32 I'm very excited to have you.
0:01:34 so most of the audience I'm certain
are familiar with your work, are
0:01:38 probably using a lot of your tools, but
would you mind introducing yourself?
0:01:43 Sure.
0:01:44 my name's Tanner Linsley and I've
been building open source software
0:01:49 for, I don't know, almost 10 years.
0:01:52 been involved in some startups, one
of them for about a decade where
0:01:56 we were building a, a SaaS product
for SEO Marketing Analytics, which
0:02:02 was pretty intense, a lot of fun.
0:02:05 And, yeah, now I mostly work full-time
on TanStack, which is kind of the
0:02:10 umbrella of all the tools that that
I've built or have helped build in
0:02:16 the last, eight to 10 years, so.
0:02:19 That's, that's what I do.
0:02:21 That is awesome.
0:02:22 I think it's safe to say that everyone
who's listening has at the very least
0:02:26 used a product that is using one of your
tools, but I'm also pretty certain that
0:02:30 almost everyone is also directly using
one of your tools and libraries in some
0:02:36 package days, dependencies, me included.
0:02:39 I'm a huge fan of your work and you
and I actually had the chance to catch
0:02:44 up in person again at last year's next
JSConf in, very sunny San Francisco.
0:02:49 And this is where I got the chance
to show you what I've been working on
0:02:53 over the last few years with Live Store
and generally chat about localf-first.
0:02:58 And I think this was probably
not your first touch point
0:03:01 with, localf-first as such.
0:03:03 I think that goes way back further.
0:03:05 But maybe you can share a little bit of
like your relationship to localf-first.
0:03:11 As I understand it, you are not yet
fully in the center, you're aware
0:03:17 of it, but you also are developing
your own perspective on it.
0:03:22 Tanner's perspective om local-first.
0:03:22 When we met at Nex Conf and what
you showed me was impressive.
0:03:26 It was crazy.
0:03:28 and the stuff you had been
showing me before and after
0:03:30 that is just mind boggling.
0:03:32 I think the furthest back I can go for
like a localf-first, or at least what's
0:03:36 aspiring to be localf-first experience
was like back with Meteor and PouchDB.
0:03:42 I remember playing with those extensively
just thinking like, wow, this is so cool.
0:03:46 'cause, and back then it was like,
there was a, a big push to have
0:03:50 everything be offline, you know,
first, and then, sync when it can.
0:03:55 obviously, the syntax and the tools, the
tooling and everything around local-first
0:04:01 like evolved drastically since then.
0:04:03 it doesn't even look the same.
0:04:05 but that was kind of my first experience
with the feeling of localf-first
0:04:10 that you get where you kind of just,
you can interact with your data.
0:04:14 Pretty much as if it's synchronous
and then just kind of forget about it.
0:04:18 And that, I think PouchDB was probably
the first one that I felt that with and
0:04:22 I was like, wow, this is really magical.
0:04:25 you know, it's definitely far from perfect
and there's a reason that, you know, not
0:04:29 everybody's using PouchDB anymore, or
even were using PouchDB, yeah, I think, in
0:04:35 the more modern, tool chains, everything
you've been working on has been kind
0:04:41 of the most eye-opening along with some
of the other stuff from like, Convex.
0:04:46 Convex is a TanStack partner, and they.
0:04:49 Kind of like that server-first,
localf-first experience as well,
0:04:55 and they have really direct ties
with TanStack Query, which is why
0:05:00 I've experienced a lot of that.
0:05:02 so yeah, my perspective on localf-first
is that, I think ideally every developer
0:05:09 would love to be able to interact with
their APIs as if they were localf-first.
0:05:14 and then I say that not necessarily
meaning like offline, but just in a
0:05:18 very synchronous, I synchronously did
this thing and I can trust that it's
0:05:22 going to be persisted where it needs
to be persisted and then move on.
0:05:27 and just kind of feel like
everything gets instantaneous.
0:05:29 So, I have no doubts that
that is what everybody wants.
0:05:34 But obviously, as I'm sure we're going to
discuss here over the next few minutes,
0:05:38 is that it can be difficult to get there.
0:05:41 and if you try and get there too
quickly, I know you can get into some
0:05:44 trouble and there's really smart people
like you and many others who are, or
0:05:48 who are slowly trying to carve out
this space and make that a reality.
0:05:53 So I am very anxiously and excitedly
watching and also trying, we're trying
0:06:00 to take part in that journey where it
makes sense for TanStack to take part.
0:06:05 That is awesome.
0:06:06 Well, first of all, thank you
so much for the kind words.
0:06:10 I'm a huge fan of just like overall
the way, also how you approach your
0:06:14 projects, that you get to work on
those projects in a sustainable way.
0:06:18 And I think this is really why so
many people trust your projects.
0:06:23 So just wanted to mention that.
0:06:25 And there's like many different
ways how to reach and go after that
0:06:30 goal that you've motivated, that you
get instantaneous data, you get the
0:06:34 simplicity coming from synchronous data.
0:06:37 and I've certainly taken probably a
more radical approach on that over
0:06:42 the last couple of years where really
like, I had the luxury of working on a
0:06:46 greenfield project, so I was not burdened
with everything that was there before.
0:06:52 So I could make much more.
0:06:55 radical and free design decisions.
0:06:57 So in the case of LiveStore is
why I've embraced event sourcing.
0:07:01 But I think you are a bit more on
the other side of the spectrum with
0:07:05 a technology like React Query, which,
at acknowledged the reality that in
0:07:11 most projects there is already an
API data source somewhere, and that
0:07:16 makes it so much easier to adopt.
0:07:18 And that shows in the download
numbers and usage of, TanStack
0:07:23 Query, formerly React Query.
0:07:25 I think this is what most people really
find themselves using on a daily basis,
0:07:31 but as they aspire to make their app
faster, to load more quickly, reload more
0:07:36 quickly, then they also try maybe even
make their app work in a offline scenario.
0:07:43 Then they try to get there step by step.
0:07:46 So maybe you can share some
anecdotes of people doing that with
0:07:50 TanStack Query where they reach for
optimistic mutations, et cetera.
0:07:55 TanStack Query adoption
0:07:55 Yeah, that happens all the time.
0:07:57 I think that's one of the reasons
why it took off, is because it's very
0:07:59 pragmatic, for the slop that most
people are working with every day.
0:08:04 Whether that's your own slop,
hopefully you've been in your job
0:08:08 long enough to have to deal with your
own slop, or it's slop from before,
0:08:13 or you're just moving so fast that.
0:08:15 That's just what it is.
0:08:16 But, but the reality is that, you
know, things are just messy, when
0:08:21 you're shipping real products to
real people as fast as possible.
0:08:24 and I built React Query 'cause I needed a
way to make the experience better for, for
0:08:31 developers and users without needing to
get in the middle of the entire process.
0:08:38 like Meteor was trying to do,
or like GraphQL was trying to do
0:08:42 or Apollo, you know, I needed as
little buy-in as possible with
0:08:46 the maximum amount of, effect.
0:08:48 And, that's what it came to be
and I think it's very natural.
0:08:53 when you start playing with Query,
you start to realize that it is
0:08:58 in a way, a sync engine, right?
0:09:00 You have defined these declarative.
0:09:03 subscriptions to your data,
it's very manual, right?
0:09:08 Very, course brain manual timings
of like, how often do I want
0:09:12 to go and get this thing right?
0:09:14 So it's in the middle of like a
one-off, API call and a sync engine.
0:09:19 but it is living and breathing
and, the life cycle of that life
0:09:26 in this, Query cycle still takes
some effort from users, you know?
0:09:30 So when you change something, you
need to let Query know, that you've
0:09:35 changed something at the very least.
0:09:37 And we call that this invalidation, right?
0:09:39 And this is kind of like the bare
minimum for What I would call
0:09:44 probably the worst sync engine you
could want is just like, I've changed
0:09:49 something, invalidate everything
and just re-sync everything, right?
0:09:53 It's, it's very manual.
0:09:54 You are the one deciding when to re-sync.
0:09:57 And it turns out that a lot
of developers just weren't
0:09:59 doing that in the first place.
0:10:01 so it's crazy to think that just teaching,
giving people a good tool, like Query
0:10:07 and then telling them, Hey, when you
change something, you need to just
0:10:10 mark everything as dirty and re-sync.
0:10:14 It.
0:10:14 Just, that has improved
everybody's apps a ton.
0:10:20 And user apps, you know, it's
like, oh, data is up to date.
0:10:24 You know, it's not super efficient, it's
not automatic or whatever, but it is.
0:10:28 so I think that's, the bare minimum,
and that's the reality where a lot
0:10:31 of developers are today is they're
probably still coming, they may even
0:10:37 be coming from .net or, you know, some
monolithic backend shop into front
0:10:44 end, and they've never done any front
end syncing, data syncing at all.
0:10:49 And they might just think, well, I'm just
gonna call my API and display the data.
0:10:52 Right?
0:10:53 So I think that that's the
reality for most developers.
0:10:57 Most, successful companies are not running
the latest and greatest, and many of
0:11:02 them probably don't even know, you know,
the first thing about designing a sync
0:11:06 engine, I barely know anything about them.
0:11:09 So I, I wouldn't expect many, you
know, many of your run of the mill
0:11:13 developers to know a lot about it either.
0:11:15 So, but I think that's the first step.
0:11:18 And I, I think personally that once
you taste that, it's addicting.
0:11:22 You want more of that and you
naturally start to say, okay,
0:11:26 how can I make this faster?
0:11:27 Right?
0:11:27 And that's on the read's end, which
is kind of like the bare minimum.
0:11:30 It's like, I wanna read my data
and make sure it's up to date.
0:11:34 And then you start thinking about the
writes and you're like, oh, well you know
0:11:36 what would be cool is if when I click
this button it just showed that it's done,
0:11:42 even though we know it takes, you know,
a hot second for it to go and be done.
0:11:47 And then to resync all the
data, it'd be cool if it was
0:11:50 just looked like it was done.
0:11:52 And so we call that an
optimistic update, right?
0:11:55 Like optimistic, data manipulation
and Query has that built in.
0:11:59 Again, it's very manual.
0:12:01 you have to manipulate the cache that's
in your browser, in the Query client
0:12:07 to represent that new state manually.
0:12:10 and you fire off the mutation
or, the change that's going
0:12:13 to result in that state.
0:12:14 And then you just kind
of cross your fingers.
0:12:16 That when you invalidate your
data, when it's done and that new
0:12:19 data comes in, it matches what
you optimistically put in there.
0:12:23 Again, this is like from my perspective,
if you can implement optimistic
0:12:29 mutations with something like Query,
you're already so much further ahead
0:12:33 than what the standard has been
for a very, very, very long time.
0:12:38 but like I said, it's very addicting.
0:12:41 So then after that, you know,
you start to think, okay, this
0:12:45 mutation thing that I'm doing, these
optimistic updates, those are tedious.
0:12:50 You know, it's like, well, I have to,
I have to make those perform, like make
0:12:54 those optimizations myself and manipulate
the cache and it feels dirty, right?
0:12:59 And so that's when it starts to get
a little more intense with like,
0:13:03 okay, how could we make it so that
when I say I clicked this button.
0:13:10 I should like this post somewhere that
I don't have to go in and manually
0:13:16 kind of do the optimistic update that
my mutation can just know what it's
0:13:23 going to affect, make the update, send
it to wherever it needs to go, and
0:13:29 then it will sync when it needs to.
0:13:31 And then we can just carry on, not
just as like a user interface to click
0:13:35 something and be able to carry on
immediately, but also as a developer
0:13:39 to be able to say, this is what's
changing, and then just move on.
0:13:43 You know, not have to worry about
optimistic updates and cache
0:13:47 and validations and whatnot.
0:13:48 So this is where I think, at least for
me, where things start to get really,
0:13:54 really fun and really, really scary.
0:13:56 Mostly because it's just,
it's a new space, right?
0:14:01 And, you know, to, give you my
perspective on it, I haven't gone
0:14:05 too far down that rabbit hole to
be honest, because it involves a
0:14:10 lot of knowledge about a system.
0:14:12 usually involves knowing about schema
or, creating schema in some way.
0:14:18 there's different implications for where
that data is being synced, whether it's
0:14:23 local like offline or on a server or
through web sockets or REST or whatever.
0:14:28 so there's just a lot that comes with
that and that has been intimidating
0:14:33 for me because it's difficult for
me to generalize where like, React
0:14:37 Query was easy to generalize.
0:14:39 but it doesn't mean that
we're not thinking about it.
0:14:42 You know?
0:14:43 this was a, perfect tour from the
beginnings of the motivations that led
0:14:48 to React Query and now TanStack Query,
the benefit it provides and like how
0:14:53 far it gets you, but also like to the
point where it brings you where things
0:14:56 are already working pretty well, but
maybe you face some new challenges
0:15:01 and you would like things to work even
more automatically in the right way.
0:15:06 You now need to better understand that.
0:15:09 And this is also like nicely reflects,
like a lot of my thinking over the
0:15:13 last decade where I've been wrestling
with the same ideas and the same
0:15:18 challenges and a few points always like
bubbled up to me again as like those
0:15:24 can't be ignored in a generalized way.
0:15:27 And I think this is really the, key
point to underscore here, like looking
0:15:31 for a generalized solution and like at
least I don't want to be the bearer of
0:15:35 bad news, but I don't think for data
there is a generalizable solution because
0:15:40 data is like the ultimate as it depends.
0:15:44 And I think this is where a
technology like React as like
0:15:48 the first of its kind in a way.
0:15:50 showed us a, like close to generalizable
solution that applied so perfectly
0:15:57 to so many different situations and
use cases, and unfortunately I don't
0:16:02 think that is realistic for data.
0:16:04 Just because for data you have
just different trade-offs.
0:16:08 Let's say you're building a banking
app, this is where you really want to be
0:16:12 certain has that wire gone out or not.
0:16:15 But if you're building, let's say, a
note taking app, it is actually more
0:16:19 important that you can just carry
on writing down your thoughts, then
0:16:24 that you perfectly know that it's
also already arrived on the server.
0:16:29 And so it's just different trade-offs
and those different trade-offs
0:16:33 need or could be productized
and systematized into something.
0:16:38 And this again, is where I think React
Query has been just so phenomenal in
0:16:44 striking those trade-offs it meets
people, where most of them are, where
0:16:49 they don't need the perfect thing.
0:16:51 Something good is already
better than nothing.
0:16:54 And then just like calling,
fetch themselves and then,
0:16:58 dealing with that somehow.
0:17:00 But for people who wanna now go
further for a more specialized path,
0:17:05 I think this is where now there's like
a, tree of potential new approaches
0:17:10 and potential new technologies.
0:17:11 And some of them you've
been investigating.
0:17:14 And I think, one particular like hairy
topic here to investigate further is
0:17:19 like, how do you get for the writes
that you're doing for the optimistic
0:17:24 updates or the updates more generally.
0:17:26 What happens when you're updating
data, like most directly, you're
0:17:31 updating data in like a local variable
somewhere, somehow running in your,
0:17:37 let's say, React app, but then you're
also maybe posting to an API endpoint,
0:17:43 and now it's already, the universes
are already potentially splitting.
0:17:48 So you've updated your variable,
maybe your API request.
0:17:52 Goes through.
0:17:53 And as that API request is
being propagated further, fail
0:17:58 somewhere there and now you
need to unwind the entire thing.
0:18:01 But let's say maybe you do two
API requests, one goes through
0:18:04 the other, doesn't go through.
0:18:06 Now you're like in the
split brain situation.
0:18:09 And so now you need to, should you wind it
back, should you partially wind it back?
0:18:14 And now you need to handle that on your
API server as well as on your client.
0:18:19 And on the client, maybe you just say
like, you know what, if we hit this
0:18:22 case, it's so rare we just show an
error message and say the user like
0:18:26 reload, but maybe it's not so rare.
0:18:28 And then you need to think about
it in a more principled way.
0:18:32 And this is where another kind
of manifestation of that is cash
0:18:36 inconsistency and There is a
really great blog post, that goes
0:18:41 along the lines of like, your
app shouldn't become a database.
0:18:45 we'll link it in the description.
0:18:47 But, I think that is like a very nice
and provocative post that shows the
0:18:52 reality of most ambitious apps that
as you pull more on that thread, your
0:18:57 app becomes a database with all the
hard things about a database, and it
0:19:03 needs to be transactionally consistent.
0:19:05 So if you click that button,
maybe it should reflect in
0:19:08 instead over here and over there.
0:19:11 And if it doesn't, your app feels
broken or things might actually like
0:19:15 you get the dreaded, undefined is not
a function because like some, like
0:19:20 array index is not there, et cetera.
0:19:23 And the more you pull on that,
the more you want kind of like a
0:19:26 React-like foundation that you can
just trust that is maybe a bit more
0:19:31 specialized to your use case, but you
can actually trust and it just works.
0:19:36 And this is where I hope things are going.
0:19:38 Like, basically a tree of different
possibilities for, mature and well
0:19:43 designed data systems that, match
the corresponding set of trade-offs.
0:19:49 And it's now our role as educators to
educate developers which trade-offs
0:19:55 work well for their apps and what are
good, solutions and systems for those.
0:20:01 And I think that something like React
Query has been an excellent catch
0:20:06 all that already lifts people up.
0:20:11 Evaluating the right trade-offs
0:20:11 I think that makes total sense and, you
know, the way that I have always looked
0:20:16 at like trying to solve these kinds of
problems is: i'm always looking for like
0:20:21 the least common denominator, right?
0:20:24 And you can never find something
that's perfect, but you can
0:20:27 find something that's 90%.
0:20:29 And then once you have tackled
that problem, you can kind of move
0:20:33 down the spectrum to, the use cases
that might be more important or
0:20:38 more intense, but you know, are
not the least common denominator.
0:20:41 and I think that's where
React Query sits for me.
0:20:44 You know, it's not the tool for
all of the really, really specific
0:20:48 difficult use cases, but 90% of
the time it's the right choice.
0:20:53 and then we can also, if you can
build something where you can build
0:20:58 on top of it to get to those other
use cases, then that's even better.
0:21:01 in this scenario, I personally am
opening up more to the idea where
0:21:06 there, you know, there could be
this, general like solution, right?
0:21:12 I don't know exactly how that looks.
0:21:13 Like you said, I mean React kind
of just happened and it was like,
0:21:16 oh wow, this is a great solution
for the problem components.
0:21:19 I don't know if I've seen the
component solution for like data
0:21:25 yet, you know, 'cause there's
so many different trade-offs.
0:21:29 Like you said, I'm so interested in,
see in synchronous data management
0:21:34 through things like signals.
0:21:36 Like I talk with Ryan Carniato all
the time about, he's working on all
0:21:40 this new Signals stuff and I just love
it and I'm like, wow, this in terms
0:21:45 of like reactivity, this is amazing.
0:21:48 You know, this is something
to keep your eye on.
0:21:50 but a lot of the Signals stuff
that we see also isn't crossing
0:21:57 the network gap all the time.
0:21:59 and so that gets weird into like,
well, how do you then roll things
0:22:03 back or how do you do transactions?
0:22:06 And so there's this split world,
like you said, between lots of
0:22:11 effort going into both of these.
0:22:13 and I don't necessarily
think that's a bad thing.
0:22:16 so I'll fill you in a little bit on
something that we have been working on.
0:22:20 a little while ago we teased a
library called TanStack Optimistic.
0:22:25 And the idea around TanStack Optimistic
came from Kyle Matthews, and he's actually
0:22:30 the one who's been spearheading it.
0:22:32 and which is a crazy full circle because
if you go back six or seven years, Kyle
0:22:37 and I were actually competing at one point
building static site generation software.
0:22:43 I was building React Static,
and he was working on Gatsby.
0:22:46 Next Js was getting into static
site gen, and it was cool.
0:22:50 he went and raised money and turned
Gatsby into this awesome thing.
0:22:53 And I was like, well, I have a
company already, so I'm gonna fold.
0:22:59 I said, I'll have to do this later.
0:23:00 And what do you know?
0:23:02 now he's working on a new, on
at a company doing ElectricSQL
0:23:07 and really cool stuff there.
0:23:08 And now I'm the one
building the framework.
0:23:10 So the, the roles feel reversed, but
we're working together on some things
0:23:14 right now because Kyle at ElectricSQL,
they've become very interested in,
0:23:19 this exact kind of general toolkit
that we have kind of been alluding to.
0:23:25 and one of the first problems that
they ran into with ElectricSQL and, and
0:23:29 React Query and all this was that, they
needed those optimistic updates to work.
0:23:35 but in a way that was kind of compatible.
0:23:37 Not just ElectricSQL, but just kind of
in general, like what's this general
0:23:42 kind of optimistic transactional layer?
0:23:45 And that's what TanStack
optimistic started out as.
0:23:48 and I mean, it worked, it was functional.
0:23:49 it still works today, right now,
but it's, it's already evolving.
0:23:53 So that was just, you know, a
couple months ago that we were
0:23:56 talking about TanStack optimistic.
0:23:58 So problem number one, TanStack
optimistic is a bad name.
0:24:02 because we already have optimistic
updates in React Query, TanStack Query.
0:24:05 So it's like, well, does this
have something to do with Query?
0:24:09 so it was confusing, the second problem
was that, we wanted to figure out, you
0:24:14 know, does this overlap with Query or not?
0:24:18 and could it, should it utilize Query
or is it something completely different?
0:24:23 Right.
0:24:24 And.
0:24:25 So it turns out that, part of this
layer we believe up to this point
0:24:30 is that, like you said, if you
start pulling on this thread long
0:24:34 enough, it becomes a database, right?
0:24:37 And I don't really think
that's a bad thing because a
0:24:42 database is a very loose term.
0:24:43 If you look at React Query,
there's a Query cache inside of
0:24:48 query, and that's a database,
you know, it's a key value store.
0:24:52 it's not relational, it's not, you
know, sophisticated in any way.
0:24:56 I should clarify.
0:24:57 like the application should not
become a database, typically, it
0:25:01 accidentally becomes a database.
0:25:03 And that's the point.
0:25:04 The app shouldn't be the database,
but an underlying technology that
0:25:07 you use that goes above and beyond
to be a database to do all the hard
0:25:12 work that it takes to be a database.
0:25:14 That should be the database.
0:25:15 And I think that's exactly
what you're saying.
0:25:17 Totally agree.
0:25:18 Yes.
0:25:19 And that's, I think that's the most
interesting thing, is that the database
0:25:23 is gonna be there no matter what,
whether it's a, a replication, a cache,
0:25:29 a lens, whatever you wanna call it,
all these different terms, right.
0:25:33 TanStack DB
0:25:33 But that's, the direction we're headed.
0:25:34 So we, we've actually renamed
TanStack, optimistic to TanStack DB.
0:25:40 And we're only working on a small part
of it right now, which is the optimistic
0:25:46 parts and the collections part.
0:25:49 So let me get into that a little bit.
0:25:51 We don't need to go too far into
this because I'll be honest, Kyle
0:25:54 knows 100% more about this than I do.
0:25:58 I know 1%.
0:26:00 we're just kind of consulting together
just to make sure that like we can
0:26:04 build on top of each other's things.
0:26:06 what I understand at this point is
that, you know, optimistic updates with
0:26:11 something like Query only get you so far.
0:26:13 And at some point you need that
schema, like I was saying, you
0:26:17 need some kind of structure.
0:26:19 and you need some way to
declaratively kind of build up these
0:26:22 relationships between your data.
0:26:25 of your data and that you're pulling from
somewhere and your, mutations and, the
0:26:31 actions you're taking against your data.
0:26:34 And just having consistent actions against
your data solves a lot of the problems
0:26:40 around, well, if it was just signals
and we're just kind of firing reactivity
0:26:44 events off all over the place, how do
you transaction those things together?
0:26:48 How do you roll things back?
0:26:49 I mean, there's ways to do that.
0:26:51 but it, we found that if we formalize
things into mutations still, which
0:26:55 is very common across a lot of
different database, implementations
0:26:58 that, that you can transact on those
much easier and roll things back.
0:27:02 I mean, it's the same way with
Convex, you know, in LiveStore too.
0:27:06 so we want a layer that is purely
for the front end, it's purely
0:27:12 for the client where we can define
these collections and define these
0:27:19 mutations that are going to happen
and the relationships between those.
0:27:23 and then those can be fulfilled by syn So
for instance, you can make a collection
0:27:31 to say, you know, here's all my users.
0:27:34 here's my filters on those users.
0:27:37 here's pagination, or here's just all
the things that kind of create the
0:27:40 lens into this data source that I have.
0:27:44 And it's formalized contract,
formalized schema on how you get that.
0:27:49 And then you have mutations that say,
you know, I'm mutating this thing.
0:27:54 and this thing is a formalized structure
within my application, and it has schema.
0:27:58 And then.
0:27:59 Behind that layer, you have an
adapter to say, okay, now that we
0:28:04 have this formalized structure, we
can wire this up to whatever we want.
0:28:08 We could read using a rest API, and kind
of we could say, well, we want to pull
0:28:15 it, or we want to use invalidation, or we
want to use SSE or something like that.
0:28:21 Or you could set it up to work with
web sockets, or you could set it
0:28:24 up to work with SQLite or whatever.
0:28:27 it just needs to be fulfilled.
0:28:28 so in a similar way to React Query,
saying, a promise is all you need, right?
0:28:35 for TanStack db, the loose vision
right now is that you need something
0:28:42 that can satisfy the interface
or not even the interface, but
0:28:47 the lifecycle of a sync engine.
0:28:50 That might be super drop in, like
ElectricSQL or whatever, or it
0:28:56 might be more manual, which is what
I'm really excited about to say.
0:29:00 I already have a rest, API,
I'm already using React Query.
0:29:03 We can't upgrade into web sockets or
like do a bunch of crazy infrastructure
0:29:08 stuff right now on the backend.
0:29:11 But if we could kind of
upgrade the lifecycle into this
0:29:15 contract of sync engine, right?
0:29:19 What does it mean to be a
sync engine for the front end?
0:29:22 Then you could technically upgrade
your front end data reading and writing
0:29:28 experience to what feels like a sync
engine, but behind the scenes, It
0:29:33 could just be going out and kind of
using the same APIs that existed in
0:29:38 your company a year ago or whatever.
0:29:40 So I think that's the vision and to
me that sounds like a least common
0:29:45 denominator approach to it to say, data
could get here somehow, and we're gonna
0:29:51 send data out somehow and we're gonna
build formalized contracts around that.
0:29:56 and then hopefully, we see adoption around
adapters and patterns and utilities.
0:30:03 and possibly even around things
like TanStack Query where maybe you
0:30:08 don't have web sockets or service
and events or sync engine happening.
0:30:14 So maybe, maybe TanStack Query is the
fulfiller of this contract, I think
0:30:21 that starts to look very interesting.
0:30:22 to be very blunt, that's kind of the, the
envelope that's the bleeding edge of my
0:30:27 opinions and my knowledge on the topic.
0:30:29 everything honestly, from here forward is
probably gonna be more, nuanced opinion
0:30:35 That is awesome.
0:30:36 And I think that really
nicely closed the loop.
0:30:38 Something that stuck with me that you
said, the beginning of our conversation is
0:30:43 that if you squint, React Query is already
kind of like a mini sync engine is, the,
0:30:49 the benefit is it works with everything.
0:30:52 The downside is it only goes so far
and doesn't handle all of those edge
0:30:57 cases in the most resilient way.
0:30:59 Right?
0:30:59 But with like Pareto principle
style, like you do 20% of the
0:31:03 effort, you get 80%, of the outcome.
0:31:06 And now you're connecting this to, a
variation of it where what React Query
0:31:12 already does is like, it's a Query part.
0:31:15 So what do you Query?
0:31:16 You Query from like something
where data comes from and now you
0:31:20 basically say, actually that is.
0:31:23 Already very useful.
0:31:25 But where we are getting the data
from, there's sort of like this
0:31:28 in-between stage where typically
you resolve a Query to a database.
0:31:34 And so we only have that, we don't
really acknowledge that there is a
0:31:37 database in the middle, but yet there
is a database in the middle, right?
0:31:41 And once we have that, and once
we acknowledge it and build all
0:31:44 the things around it, we can
actually Query much more, much
0:31:48 better, much faster, much safer.
0:31:51 we get like super fast filtering.
0:31:53 We these updates, optimistic
updates become simpler, et cetera.
0:31:57 Sort of like embracing that
0:31:59 when you, when you sprinkle schema into
things, a lot of dev tools get better.
0:32:05 So, you know, the dev tools for Query
are awesome, don't get me wrong.
0:32:09 They, I think they're,
I think they're great.
0:32:11 But when you have schema.
0:32:13 And formalized interfaces on
top of your data dev tooling
0:32:19 can get way more sophisticated.
0:32:22 in fact, I'm remembering all of
the awesome stuff that I've seen
0:32:26 from LiveStore, you know, out,
out of dev tooling that's like,
0:32:30 it would be impossible to do with
a tool with just Query, right?
0:32:34 but, but you see some of that
come into play when you know,
0:32:38 okay, GraphQL gets involved.
0:32:39 It's like, well, now we have schema.
0:32:40 Now we can do all this cool stuff.
0:32:42 it's kind of the sa it's
kind of the same thing here.
0:32:44 Whenever you add schema into something and
create stricter contracts, even if those
0:32:49 contracts are with yourself, like you
can build much better tooling around it.
0:32:53 I couldn't agree more schemas,
like nine out of 10 cases.
0:32:58 It's a great deal.
0:32:59 You put in a little bit of work and
you get so much out of it constantly
0:33:04 in all of those different dimensions,
types, validation, and like you can
0:33:09 also like, and I think as a industry
we've only scratched the surface what
0:33:13 we can actually do with schemas, like
at least as a JavaScript industry in
0:33:17 other program languages, schemas are
like highly leveraged to, for example,
0:33:23 work with data in a more efficient way.
0:33:26 So this is where like
Protobuf, JRPC, et cetera.
0:33:29 A lot of that is used to minimize
the amount of data that we send
0:33:33 across the wires or have more stable
contracts as we are evolving things.
0:33:37 And I think we're just scratching
the surface of like what will be the
0:33:41 javaScript equivalent where we have, so
right now, maybe we have something that
0:33:46 also gives us the benefit of something
like Protobuf in let's say 2030.
0:33:51 I don't wanna be overly optimistic here.
0:33:54 Sounds accurate.
0:33:54 But, but yeah, I, I think this is super
compelling what you're pitching here.
0:34:00 And like, I don't think this is just
a, pitch, but it's actually happening.
0:34:04 And, Kyle, who we also had
previously on the guest.
0:34:08 Who's now at Electric, is an excellent
person to lead the charge on this, so
0:34:12 I'm really excited to, see that evolve.
0:34:15 I have many more questions that
I would like to ask you or Kyle.
0:34:18 Let's do it.
0:34:18 But I'll, I'll, uh, I won't
go too much into that there.
0:34:22 Just as you mentioned that you're,
only so far in the weeds so far.
0:34:26 but one thing that I'm also curious
about in regards to TanStack DB is do
0:34:33 you already have a hunch of like, what is
that contract, that makes when you bring
0:34:38 a plugable, sync engine that you provide
there as a data source, what does that
0:34:47 Sync Contracts
0:34:48 right?
0:34:49 yes, we do have a flexible and changing
idea of what those, contracts look like.
0:34:56 in fact, in inside of,
it's still at slash.
0:35:00 Still at TanStack slash
optimistic on GitHub.
0:35:03 but we do already have, like some of
the core hooks and logic set up in there
0:35:08 already to around collections, that
the documentation obviously isn't there
0:35:14 yet, but if you dig into the code in
the examples, you can start to see, kind
0:35:19 of the silhouette of what syncing is.
0:35:22 So, you know, we have some configuration.
0:35:25 there's like a sync option that
takes a sync configuration.
0:35:30 So it has been formalized, for
now in terms of what we believe
0:35:35 it needs to be, you know, to get
a proof of concept out the door.
0:35:39 and you know, one of the good examples
to go look at in there is there is
0:35:42 an Electric, there's an Electric sync
configuration that now dog foods, that
0:35:48 that interface in that contract to kind of
give you an idea of how that could feel.
0:35:53 Now things are gonna change, things
are gonna get better, upgrade, you
0:35:56 know, we'll, we'll try and add more
adapters and break our expectations.
0:36:00 So, the idea is that the, those
sync contracts are going to evolve
0:36:04 drastically, over the next little while.
0:36:08 That sounds awesome.
0:36:09 And I'm particularly excited about all
of those adapters since once you start
0:36:13 adjusting your own perspective, then
almost anything can be a data source
0:36:18 or a sync engine for that matter.
0:36:21 It might not be inherently reactive,
but then you throw polling on
0:36:24 it and until that data source is
itself reactive, you can sort of,
0:36:29 paper over that through polling.
0:36:31 And just like a, let's say the
GitHub, API could be actually
0:36:35 a sync engine implementation.
0:36:37 Absolutely.
0:36:37 And now you can build a local app that
works with like GitHub data just as
0:36:43 it's local, like code, like is local.
0:36:45 That's the idea.
0:36:46 And, you know, going beyond that, I
think, with Query right now, it's easy
0:36:50 to get trapped into thinking like, oh,
I can just Query my, my one database.
0:36:55 Or you start thinking,
well, I can Query multiple.
0:36:58 or even start Querying
anything that is a promise.
0:37:01 So, so once you start thinking about the,
the sync protocol or the sync contract
0:37:06 as just something to be fulfilled,
it kind of opens up the same gate.
0:37:11 It's like a parable to when people
are like, oh, I can use React Query to
0:37:15 use, like device APIs because they're
just based on a promise, you know?
0:37:20 So I imagine the same thing will happen,
for these sync contracts as we kind of
0:37:25 just learn that, you know, oh, anything
that I can read and write to, I can turn
0:37:29 into a sync, like a sync configuration.
0:37:32 And I think it gets really exciting when
you start looking at the ability to have
0:37:36 multiple sync configurations working
together and potentially merging into
0:37:41 the same schema in your application.
0:37:44 and they might handle
different responsibilities.
0:37:46 'cause the reality is that.
0:37:48 I mean, a lot of people
would love offline.
0:37:51 You know, you can do offline for a
lot of things, but I don't know of
0:37:55 any application that's providing a
lot of value these days that doesn't
0:38:01 eventually need to connect to the server.
0:38:05 And like you said, eventually need
very strict transactions on I did
0:38:10 this thing and did it happen, and
we cannot proceed until it did.
0:38:13 Right?
0:38:14 So we're trying to make sure that we
don't code ourselves into a corner
0:38:18 here and we wanna design it so
that, you can do all of those things
0:38:22 kinda, you know, synchronous first.
0:38:24 you can have sync contracts that
are very optimistic and just fire
0:38:29 and forget and we'll sync it later.
0:38:31 And when you need to.
0:38:33 You can kind of go deeper and say,
okay, I'm finding off this mutation,
0:38:38 but I'd like to opt into some more
strict confirmations around it to
0:38:44 make sure that we don't proceed.
0:38:45 You can lock things easier.
0:38:49 So I don't know, I like this future
where it's, it's kind of like Query
0:38:54 for Query in a way where you know,
we're just adding organization, we're
0:39:00 adding more intelligent lifecycle
where we're adding a heartbeat to
0:39:07 what people experience today is react
Query is like, oh, I'm syncing data.
0:39:11 We're just going to breathe a little
bit more life into that engine,
0:39:16 without trying to control everything
about the experience, about the
0:39:22 backend, and about the language
that you use to do things and.
0:39:27 you know, if we can create that adapter
economy there, I think that, we could
0:39:31 see some really cool stuff happen, we're
working really closely with ElectricSQL
0:39:35 and also with Convex, you know, convex
uses Query directly, which is amazing.
0:39:41 And we also have really good
relationships with TRPC that uses Query.
0:39:46 So we have a lot of people involved in
this, space to different varying degrees.
0:39:53 And I'm confident that that's, really
why we think now is a good time
0:39:57 is because we have enough signal.
0:40:01 to design something that could be
helpful to a majority of people.
0:40:05 We're trying to take a slow though,
to be honest, because this is
0:40:08 not something you just rush into.
0:40:11 Oh, I completely agree.
0:40:12 Maybe using this very topic
as an opportunity to pull back
0:40:16 the, the curtains a little bit.
0:40:18 what I see as just like the common threads
through all of the, the projects, the
0:40:23 all the TanStack projects, is that they
have a very, kinda like the, the TanStack
0:40:28 way of like how the API looks and feels.
0:40:30 It's like, it's very intuitive.
0:40:32 It's nicely modeled around the common
scenarios, but then also allows for like
0:40:38 reaching for that extra configuration,
that extra functionality once you need
0:40:42 it, but it doesn't overwhelm you upfront
with like, needing to know of all of that.
0:40:47 And now you're going into a new field
and in an existing field even deeper.
0:40:53 And so now you need to apply like that's.
0:40:56 At the end, there is a new TanStack
DB products and library emerging,
0:41:02 and I'm certain that will feel
just as intuitive and as nice
0:41:06 as the other TanStack libraries.
0:41:09 But that doesn't just happen, by itself.
0:41:12 But there's something, a lot of
intuition, a lot of experience
0:41:15 that's going into that.
0:41:17 And I'm not sure whether you
formalized that, but we, we got
0:41:19 some questions from the audience.
0:41:21 whether you have any sort of
like process guidelines, your own
0:41:25 guidance, your inner guidance,
intuition, how would you frame that?
0:41:29 that could also serve as advice to
others who aspire to build tools,
0:41:34 like, like the ones you're working on?
0:41:37 Tanner's inner guidance on developing a project
0:41:37 Well, I like to think about it.
0:41:39 I like to approach it in a way
of like, there's different tiers
0:41:44 of things that you can control.
0:41:47 So for me personally, if
I'm working on a project.
0:41:50 Building it myself.
0:41:51 Like I can control a lot and I'm
just very picky and, I try to
0:41:57 be my best customer in a way.
0:41:59 Like, I try to approach using my own
software as if I don't know everything
0:42:04 about it and call me schizophrenic.
0:42:07 But like, you need to be able to
kind of assume this other identity
0:42:10 to where you're like, okay, I don't
know anything about this project.
0:42:13 I'm trying to use this
API, this is confusing.
0:42:17 What does this even mean?
0:42:19 So you need to wear multiple hats at
the same time and be able to switch
0:42:22 between them very quickly to say,
oh, yeah, okay, now I'm gonna go back
0:42:25 to, architect Tanner and, and, change
this to, make it easier to understand.
0:42:31 So.
0:42:32 A lot of it is just, I think just
being very picky and just using your
0:42:35 own tools, like a lot, using your own
tools a lot and showing other people
0:42:40 your tools before you release them and
say, well what do you think about this?
0:42:44 And trying to teach your tool to
people and they'll say, Hey, that's
0:42:47 really cool, but this is super weird.
0:42:49 Like, I don't agree with that.
0:42:51 So you just need to be getting
feedback all the time and say,
0:42:54 always be shipping, right?
0:42:55 You can ship to a friend, you can ship
to your company, you can ship somewhere.
0:43:00 It doesn't have to be NPM before,
you know you can get feedback.
0:43:05 so that's kind of rule number one.
0:43:06 after that, I believe that at
this point for TanStack, things
0:43:12 are also changing a little bit.
0:43:13 Like I said, I'm not the one who's the
driving force between TanStack DB Kyle is.
0:43:18 and if you look at other libraries, the
same thing has kind of been happening.
0:43:21 So.
0:43:22 TanStack form was, you know, the bulk of
the entire project was spearheaded and
0:43:27 completed and done by Corbin Crutchley.
0:43:30 and it doesn't mean I didn't, I had
a lot to do with the initial, like,
0:43:35 parts of TanStack form, you know,
for the first little while, but I
0:43:39 can't be everywhere all at once.
0:43:42 So I've mostly been focusing on router
and start for the last two years.
0:43:47 And so the next part of it is, you
know, if you can't control everything
0:43:52 on your own, you need to be able
to find people that you trust.
0:43:56 And that's really what it comes down to
is I get petitions and, people every day
0:44:02 on Twitter and on GitHub who are like,
Hey, I have this idea for a library.
0:44:08 We should do it.
0:44:09 Or I have this idea for
a feature or whatever.
0:44:12 And.
0:44:13 that's excellent feedback when we
take that feedback into consideration
0:44:16 for all, all everything that we see.
0:44:19 but the choice of letting somebody
come in and start making decisions for
0:44:23 you is a really, really big decision.
0:44:25 And it just needs to
be one that you trust.
0:44:28 And so if you see one of the,
every single one of the core
0:44:31 maintainers and core contributors to
TanStack, did not happen overnight.
0:44:36 except for Corbin Crutchley.
0:44:37 I met Corbin and I knew it in 10 minutes
that, he was the right person for the job.
0:44:41 but it really comes down to trust.
0:44:43 And, and at the end of the day,
I trust, you know, Dominic and
0:44:47 Kevin and Corbin, and Manuel, and
Sean and Chris and Kyle, right?
0:44:54 I trust all these individuals
and many more that I didn't
0:44:58 mention, because they understand.
0:45:01 The brand.
0:45:02 Now they understand our priorities and
they understand what needs to happen.
0:45:07 You know, we, prioritize
type safety above all else.
0:45:11 You know, we prioritize the 90% use case
above all else, but we make it so that you
0:45:17 can gracefully opt into advance features.
0:45:20 it's not formalized in a document, but
it is formalized in the experience that
0:45:26 you get using one of these libraries.
0:45:29 And if you know, you know, and if
we're going to ship a new product,
0:45:33 everybody collectively understands
that it needs to meet the same
0:45:37 standards as all the other products.
0:45:38 So, and the people that I, invite
in or, want to come and help me
0:45:43 build stuff, those are people that
I trust to execute on that vision.
0:45:46 So.
0:45:47 That is awesome.
0:45:47 I fully agree with that.
0:45:49 Thank you so much for, for sharing that.
0:45:51 you've mentioned TanStack Router and
TanStack Start both of those projects.
0:45:55 I'm also using myself a lot.
0:45:58 I'm curious if you now
extrapolate a little bit further.
0:46:01 TanStack Start is, just getting to a
point where it's will hit I guess 1.0
0:46:07 at some point as well and if you're
now extrapolate forward TanStack start
0:46:12 filling in all of those, features
and, boxes that you have in mind.
0:46:16 and if you then take TanStack
DB and you combine them, there's
0:46:21 possibly like some really interesting
opportunities that weren't really
0:46:26 thinkable or possible before.
0:46:28 Are there any kind of napkin
sketches, shower thoughts you can
0:46:32 share where you imagine like some new
emerging, superpowers or kinda like
0:46:37 a new kind of framework that will
be possible for this combination?
0:46:41 Combining TanStack Start and TanStack DB
0:46:41 not in the sense of like some new
monolithic enclosure around these
0:46:47 things, but like the vision that I
have for it is that, already today you
0:46:53 can, build a TanStack Start project.
0:46:57 And when you build a Start project,
you're not, just using start.
0:47:01 People don't understand this either.
0:47:03 So, I mean, I'll take the moment to
explain it so that like, when you use
0:47:07 Next js right, you install next JS and
the router is enclosed inside of next
0:47:15 js, and the server loading strategies
are all enclosed inside of there.
0:47:19 The SSR tools and everything
is just, monolithic.
0:47:22 It's, abstractions around
a whole thing, right?
0:47:26 And there, there're dependencies
inside of each other.
0:47:28 Now, TanStack start is very different.
0:47:31 It's weird because we say the framework
is TanStack start, but it's not.
0:47:36 It's just a convenient marketing,
term to make it sound different
0:47:41 than what TanStack router is.
0:47:43 So TanStack router is what you'll
still import with a start application
0:47:49 that you've used it, you know this.
0:47:51 So when you import, most of the imports
that you're making and the utilities
0:47:55 that you're calling with TanStack
Start are actually coming from router.
0:47:58 there's actually very few that are
coming from start until you need
0:48:02 those server side capabilities, right?
0:48:05 So when you have your server entry,
or you want to write an API route, or
0:48:11 you have a server function or you need
some middleware, or you need to access
0:48:16 request headers or something like that.
0:48:19 That's when you reach for Start.
0:48:21 And so it's interesting to think
about Start and Router as actual
0:48:24 their parallel dependencies together.
0:48:27 and yes, Start does rely on like a peer
dependency in a sense of TanStack Router.
0:48:34 So that's why we kind of say,
oh, you're using TanStack Start
0:48:37 because it implies usage of Router.
0:48:40 But where they're together, I think
that's the most interesting part because
0:48:44 you get into the app and you start
building and you realize that you're
0:48:48 really just using these tools together.
0:48:51 And maybe you're using TanStack Router
and you're like, oh, this caching is
0:48:55 really good in the router and I like this.
0:48:57 And then you get to a moment where you're
like, oh, I really wish I had formalized
0:49:03 mutations around this thing, or that
I could share data between routes.
0:49:07 So then you bring in TanStack Query
and you know, you don't just turn
0:49:12 it on in the router, you bring in
TanStack Query and they work together.
0:49:16 So.
0:49:17 They have interfaces that,
integrate with each other and
0:49:21 they work alongside each other.
0:49:23 And my hope for something like TanStack
DB around the router and start is
0:49:31 that it would be the same experience.
0:49:33 You would bring it in and you would
use it alongside these other utilities.
0:49:38 but the solution should be that bringing
in something like TanStack db, the end
0:49:44 result should be that you should be
able to, with a little bit more work,
0:49:48 like you said, up at this top layer of
producing, you know, providing some schema
0:49:54 and providing some, some structure that
you would be able to then get rid of a
0:49:58 lot of the code, that you have in your.
0:50:02 data loading lifecycle points and your
user interaction points, in your actual
0:50:10 business logic of your application.
0:50:13 the hope for something like TanStack DB
would be similar to the experience of,
0:50:18 you know, somebody moving into TanStack
Query, being able to get rid of all of
0:50:23 that manual data fetching code with fetch
and useEffect and all this other stuff.
0:50:29 Moving to something like Query.
0:50:31 I want that same experience for
TanStack DB if it's warranted, right?
0:50:35 So it's like you're unintentionally
building schema and database and trying,
0:50:41 you know, it's like you're trying to
formalize all these contracts, but you,
0:50:44 don't have the right tool to do it.
0:50:46 Moving to TanStack DB should be an event
that removes the burden of a lot of code
0:50:53 that you've written and removes a lot of
the burden of linking queries together and
0:50:58 linking mutations and queries together.
0:51:00 that should be the goal.
0:51:01 not only goal for the developer side
of it, but also the user side of it,
0:51:05 where when you move to Query from
something that's very manual, all
0:51:10 of a sudden your data is up to date.
0:51:11 Now it's fresher.
0:51:13 You can tell a website that's probably
using React Query because you do something
0:51:20 and it updates and it's always there.
0:51:21 You focus the window
and it's always there.
0:51:24 same thing for moving
something like TanStack db.
0:51:27 You'll see better
results around mutations.
0:51:30 You know, you'll click something
it won't just be optimistic,
0:51:33 but it'll be synced everywhere.
0:51:35 and when things happen on the server.
0:51:38 And, you know, hopefully if you're using
something like web sockets or some kind
0:51:42 of servers sent event, you'll just kind
of get that synced to you automatically
0:51:46 without needing to invalidate or
refocus the window or anything.
0:51:49 So, if we can move both of those
chess pieces forward, you know, both
0:51:54 on the developer experience side of,
Hey, I, get to delete code now and
0:52:00 have better contracts and a better
experience as a developer and just
0:52:04 more confidence, in what I'm doing.
0:52:07 And as a user, you get to move forward
to say things are faster, they're
0:52:12 more responsive, and the user also
has more confidence that what they're
0:52:16 doing is happening and what they're
seeing is up to date and real, right?
0:52:21 So I think that's, the end goal.
0:52:24 and if we can't accomplish
that, we won't launch it.
0:52:27 that's the requirement,
0:52:28 That definitely resonates.
0:52:30 And I think that's sort of like a, a
nice litmus test for a library that if
0:52:36 you adopt a library in your application
and the library does some things
0:52:41 that you've previously done before,
ideally the library should absorb
0:52:47 everything that is not intent, that is
very specific about your application.
0:52:52 So everything that remains
is like pure intent.
0:52:56 That's about my application.
0:52:58 Everything else is like, you've hopefully
picked the right tool that like the
0:53:02 choice of the tool is part of your intent,
but then you're assuming down like one
0:53:06 level, become even more meta about within
the scope of this tool, this library.
0:53:12 Now I'm specifying my further intent
when you pick a really, really
0:53:15 great tool, it's, you can notice
it by, it removing even more code
0:53:21 that you had previously written.
0:53:22 It surprises you of like how concise
you can express what you want to
0:53:27 do in a way that you didn't even
expect how simple this can be.
0:53:31 And I think a really great library kinda
like surprises you through its simplicity.
0:53:37 and so I wanna round out this
conversation on one last topic that
0:53:42 I think you're a really excellent
person to share your thoughts on this.
0:53:46 most TanStack projects are more client
side centric, like TanStack table,
0:53:52 TanStack, form TanStack Query, et cetera.
0:53:55 those are all primitives that help us
to build rich client side applications.
0:54:00 but if you're looking at the React
ecosystem, on a larger scale, there's
0:54:05 been a lot of momentum and movement and
developments more on the server side
0:54:10 spectrum of application development.
0:54:13 And I think it can be a bit confusing
for developers who are not as
0:54:18 experienced on either side of the
spectrum to what to kind of lean into.
0:54:22 So it's not everything is always
compatible and, there's maybe some
0:54:27 applications that are being built
that go heavily on server side
0:54:31 technologies, even though that's not
the best fit for them and vice versa.
0:54:35 So I'm curious whether you can share
some reflections on, that sort of
0:54:40 broadening spectrum of react covering
the server as well, and whether you can
0:54:50 TanStack for server side applications
0:54:50 That's a hard question.
0:54:52 because there's a couple of
different ways to look at that.
0:54:56 There's a personal way to look at it.
0:54:57 Like, what should you be learning
yourself to, you know, be relevant?
0:55:03 and I think that you should know as much
of the web platform as you can, right?
0:55:09 Whether that's client or server.
0:55:11 You should, you know, if you're a web
developer, you need to know the web.
0:55:16 and that includes servers.
0:55:18 So, on a personal level, you need to be
learning as much as you possibly can.
0:55:24 does that mean you need to be
learning every language you can.
0:55:26 No.
0:55:27 but it means you need to know the
concepts, to be able to at least
0:55:31 communicate with, people or with
a team, you know, accurately.
0:55:35 So there's like this personal level thing
that I, I think is really important.
0:55:40 Like, I'm definitely not an expert at, you
know other languages and like server side
0:55:47 building, server side things, servers.
0:55:50 but I've worked with teams that have built
very, very sophisticated systems and I've
0:55:55 helped architect some of those systems.
0:55:57 and you know, I've been able to
work through that, those thought
0:56:00 processes and learn with them.
0:56:01 So I think that's very valuable.
0:56:03 Now, in, practice, I think
practice is a little bit different.
0:56:07 and this is where it's like a big,
it depends, because you might be at,
0:56:12 you know, Y Combinator startup where
you just have to know everything and
0:56:16 you are building full stack because
you don't have a choice, right?
0:56:20 and in that moment, your job
requires you to do it all.
0:56:24 So you better do it all.
0:56:25 You better learn it, and you better
in invest into everything that
0:56:28 you need to ship your product.
0:56:31 And I think that's really what it comes
down to in practice is that, yes, you have
0:56:35 to be thinking about your career, right?
0:56:37 But not.
0:56:39 being negligent to the task at hand.
0:56:42 And if you work for a company where
you're expected to be a, full stack
0:56:47 developer, then you better make sure
that you're investing in both the
0:56:50 front end and the back end equally.
0:56:52 if you work for a company and you're a
front end developer and you know that,
0:56:57 you know, pretty soon you're gonna,
they're gonna start running React
0:57:00 server components and server technology.
0:57:03 Does it mean you need to become a
database expert and learn SQL and learn
0:57:06 how to run Redis and, you know, and
Kubernetes or just Docker or whatever?
0:57:11 No, it doesn't necessarily mean all
of that, but it does mean that within
0:57:15 the realm of, of like JavaScript
running on the server, you should
0:57:19 probably start getting familiar
with JavaScript on the server.
0:57:22 You should probably start learning, you
know, what those patterns look like.
0:57:28 And I think, you know, on, on the, really
far end of the spectrum, which is more
0:57:33 common than you think, because there,
there's companies out there that have been
0:57:37 around for a really long time and they're
running technology that is, that's old
0:57:42 and outdated, and they move slow and they
make a lot of money and they have a lot
0:57:46 of teams and a lot of employees, and maybe
they're publicly traded, but that doesn't
0:57:51 mean that, you know, that they're even
allowed to run JavaScript on the server.
0:57:56 I mean, there are companies out there
that are, you know, billion dollar
0:58:00 companies that are not allowed to
run JavaScript on the server yet.
0:58:04 So, in situations like that, it's
like, well, do you need to focus on
0:58:09 learning React server components?
0:58:11 Sure, you can go check it out and,
and learn how to do some things
0:58:15 with SSR and play around with it.
0:58:17 But if that's your job, your job
is probably to be the best front
0:58:21 end engineer that you possibly can.
0:58:24 And if, that's the case, you just
need to make sure that you're focusing
0:58:28 on what's important to your company.
0:58:30 So I don't want to sound like,
you know, you need to sell out
0:58:33 your career to your company.
0:58:34 obviously I, you know, I like to stay on
the bleeding edge of everything as well.
0:58:38 I'm just a really pragmatic
person, and at the end of the
0:58:41 day, everybody wants to get paid.
0:58:44 Everybody needs to get paid, and we
should not ignore that that is a reality.
0:58:49 And if your paycheck is important to you
it's a, a critical piece of your life.
0:58:55 Then you need to be focusing on, on
what's gonna make sure that that paycheck
0:58:59 keeps growing and getting bigger.
0:59:01 And if that paycheck isn't going to get
bigger or grow with your effort, Then you
0:59:06 should be learning other technologies that
will help you secure either a different
0:59:12 job or a promotion or whatever that's
going to let you use that new knowledge
0:59:17 to grow yourself and grow your career.
0:59:20 That, that's kind of where I put it.
0:59:22 So it is, a lot of it depends, right?
0:59:25 totally.
0:59:25 I think that's fantastic advice.
0:59:27 We can leave it at that.
0:59:28 I know that, you only have so much time.
0:59:31 I just wanna highlight one point.
0:59:33 You've used the word pragmatic and this is
really what, for me resembles that's the
0:59:38 essence of like the entire TanStack family
of tools, like it's above everything else.
0:59:44 I think it's pragmatic.
0:59:46 So in case you ever wanna
formalize that, that is like my
0:59:49 candidate I'm offering to you.
0:59:51 I wanna thank you so much for taking
the time, sharing, everything.
0:59:55 That you've shared today.
0:59:57 and for all the loves, sweat and
tears you're putting into all of
1:00:01 your projects for such a long time.
1:00:03 I'm really excited to see
where all of this is going.
1:00:06 Particularly excited for TanStack
DB and, thank you so much
1:00:11 for, coming on the show today.
1:00:13 Absolutely.
1:00:13 It's been a pleasure.
1:00:15 Thank you for listening to
the localfirst.fm podcast.
1:00:17 If you've enjoyed this episode and
haven't done so already, please
1:00:21 subscribe and leave a review.
1:00:22 Please also share this episode
with your friends and colleagues.
1:00:25 Spreading the word about the
podcast is a great way to support
1:00:28 it and to help me keep it going.
1:00:30 A special thanks again to Jazz
for supporting this podcast.