Sponsored by
Show notes
Transcript
0:00:00 Introduction
0:00:00 the main thing is browsers have
storage now, like, they didn't
0:00:03 have storage for the longest time.
0:00:04 I feel like my mission in life
is just like I'm shouting from
0:00:08 the mountaintop Hey, did you
know browsers have storage now
0:00:13 Welcome to the localfirst.fm podcast.
0:00:15 I'm your host Johannes Schickling, and I'm
a web developer, a startup founder, and
0:00:19 love the craft of software engineering.
0:00:21 For the past few years, I've been on a
journey to build a modern, high quality
0:00:25 music app using web technologies.
0:00:28 And in doing so, I've been falling down
the rabbit hole of local first software.
0:00:32 This podcast is your invitation
to join me on that journey.
0:00:36 In this episode, I'm speaking to Aaron
Boodman, who's the founder of Rocicorp,
0:00:41 the company behind local first products,
such as Replicache and Reflect.net.
0:00:46 This conversation covers a wide range
of topics, starting from how his work on
0:00:50 Google Gears has led to Google Chrome.
0:00:53 And many of today's web standards.
0:00:55 Later, we're diving into what
Replicache is and how it's implemented.
0:01:00 Also a big thank you to Expo
and Crab Nebula for supporting
0:01:03 this podcast and supporting the
local first ecosystem as a whole.
0:01:08 And now my interview with Aaron.
0:01:12 Welcome Aaron to the show.
0:01:14 Thank you so much for joining today.
0:01:16 Would you mind briefly
introducing yourself?
0:01:19 Yeah, sure.
0:01:20 okay, , My name's Aaron.
0:01:21 I am most recently the founder of
Reflect.net which is a hosted service for
0:01:26 multiplayer and And for local first style
apps, my company also built Replicache
0:01:32 which is a variation of that product.
0:01:35 And I kind of have a
long history in the web.
0:01:38 I've been doing open source on
the web for a really long time.
0:01:40 I started in like, I
don't know, 2002, 2001.
0:01:44 And yeah that's me.
0:01:46 Awesome.
0:01:47 Thank you so much for making
time and coming on the show.
0:01:50 Would you mind sharing a little bit
of like your arc of what brought
0:01:54 you to local first software today?
0:01:57 Yeah, sure.
0:01:57 I'll try to give a short history.
0:02:00 You know, I started out my career just
doing JavaScript libraries, UI libraries.
0:02:03 Actually, a bunch of my oldest friends
and co workers we were a member of this
0:02:07 community online called dhtmlcentral.
0:02:09 com, which was like back in the very
dark ages of the web, like before GitHub,
0:02:13 before really open source like hit its
stride and we would share JavaScript
0:02:17 on there, and we built UI components
and things like that, and we were
0:02:21 just really excited about, you know,
pushing this, Tiny, terrible platform
0:02:27 to build, like, real apps with it.
0:02:29 One of my friends built, like, a whole
windowing, like, toolkit, like, with
0:02:33 all the window components, like, in
JavaScript, like, in 2000, I don't know,
0:02:37 it must have been, like, 2001 in there.
0:02:39 And, you know, over time, you
know, the web grew and we found
0:02:44 ourselves at big companies.
0:02:45 I found myself at Google helping them
do do their JavaScript products, right?
0:02:50 And, you know, it was always
like this huge fight to get
0:02:54 anything in browsers at that time.
0:02:56 Like, like, browsers just
would never add any features.
0:02:58 Like, there's no incentive
for them to do it.
0:03:00 And so, this opportunity at Google came
up to work on this thing called Gears.
0:03:04 Which was this crazy idea to, like, add
a plug in to browsers that added APIs.
0:03:09 Like, usually plug ins, they're
like a graphical thing, you know.
0:03:12 They like, they add
some sort of UI feature.
0:03:14 But this was an idea to add a
plug in that had no UI features.
0:03:17 All it did was add web APIs.
0:03:18 So that, like, we could actually
build stuff with browsers that
0:03:21 was, like, good, you know?
0:03:22 And and it was just such
a cool, like, bold idea.
0:03:26 And so I jumped on that, and
the first, one of the very first
0:03:28 things we built was a database.
0:03:31 aNd the reason that we wanted to put a
database in browsers was because, at that
0:03:34 time, you know, you could only store five
megabytes of data in a browser, you know?
0:03:39 And so, if you think about it, the web
is just, like, fundamentally hobbled.
0:03:44 By not having storage.
0:03:46 Like, you think about what makes an app.
0:03:48 You know, we have this constant
annoying debate on the web.
0:03:50 SPA, MPA, blah, blah, blah, blah, blah.
0:03:52 Just step back and think to yourself.
0:03:54 Like, what are the
ingredients of a native app?
0:03:56 What makes it tick?
0:03:57 What makes it a native app?
0:03:59 And there's not that much to it.
0:04:00 It's processing, memory,
network, storage, UI.
0:04:04 You know?
0:04:05 Those are the ingredients.
0:04:06 You know?
0:04:07 The web until recently didn't
have storage and that's like
0:04:10 an important ingredient.
0:04:10 If you don't have storage you're
doomed to be a dumb app, a dumb client.
0:04:15 completely agree.
0:04:16 So before going a bit more into today's
storage mechanisms, what was , back then
0:04:22 for Gears, what was the inspiration,
was there any sort of existing database
0:04:27 that you looked at where you said, okay.
0:04:29 It would be great to have something
similar to this, but for the web, or
0:04:35 From Google Gears to Chrome
0:04:36 Well, the API that we the actual
database that we used was SQLite,
0:04:39 which at that time felt very
mature, even then, at that time.
0:04:43 You know, I think,
0:04:45 I'm pretty sure that SQLite
started, I want to say, in 2000.
0:04:48 And this was 2007 that
we were doing this in.
0:04:51 It was a really, it's
kind of an obvious thing.
0:04:53 Already SQLite was in everything
at that point, you know?
0:04:56 And, or it felt like it was in everything.
0:04:58 And it's embedded, fast, robust.
0:05:01 But, you know, it wasn't an
appropriate API for the web.
0:05:05 The cool thing about working on
Gears was like a lot of the people
0:05:07 that were doing the platform design
were like JavaScript developers.
0:05:09 And then we had a bunch of
like sort of more gnarly C++
0:05:11 people working on the guts.
0:05:13 And we, you know, we wanted to do APIs
that fit in the web from both like a
0:05:18 security and a usability point of view.
0:05:20 So we wrapped SQLite in you know,
a simple, but what we felt was
0:05:25 like fairly webby abstraction.
0:05:28 So what was the path forward from there?
0:05:30 So I can't say that I've built
something on top of Google Gears.
0:05:34 But I, I've, I know of quite a few
database-like abstractions for the
0:05:40 web for example, thinking of web SQL,
which I also think is built on top of
0:05:45 SQLite was that sort of an evolution
of what you built back then, or take
0:05:51 me from back then, from the first
steps of bringing SQLite to the web to
0:05:56 the various chapters up until today.
0:05:58 Yeah, absolutely.
0:06:00 Gears had a short and glorious life.
0:06:04 I think it did not last long.
0:06:06 We launched it in I believe.
0:06:09 And it was dead by 2010.
0:06:11 And what happened was It was this
very, in retrospect, it was this
0:06:15 very high risk strategy for Google.
0:06:17 We were trying to force change on the web.
0:06:20 Like, Google needed the web to be better,
like, in order to do its applications.
0:06:24 And and, what happened when we
launched Gears was, like, the other
0:06:28 browser vendors, like, hated it.
0:06:29 And, like, like, legitimately,
or all, at that time, Google
0:06:32 did not have a browser, right?
0:06:33 So, the browser vendors hated it.
0:06:35 And, you know, they felt
threatened by it, you know?
0:06:38 And I think there were also, Fair and
good like standardization arguments,
0:06:43 but I think the reality was like
they were the people who made the web
0:06:47 platform and this was like someone
coming and trying to like force things
0:06:50 on them sort of against their will.
0:06:51 Whether the will was like fair or not.
0:06:53 And and so there was a lot of backlash.
0:06:55 We Had hoped that we would
distribute gears with browsers.
0:06:59 Safari, like, they outright said
no I think Firefox said no, and
0:07:03 basically, like, around that same
time, Google was starting Chrome.
0:07:07 And there was strategic questions
of how the two fit together.
0:07:10 And basically how do we advance the web?
0:07:12 And it just became really clear that the
way to do that was to have a browser.
0:07:16 Because like, browser vendors were
the ones with a seat at the table.
0:07:19 And it just, it was obvious that we
would, as a company, we would have
0:07:23 more leverage doing it that way.
0:07:24 At first, we put Gears in Chrome.
0:07:26 So the first thing was Chrome
launched and we put Gears in Chrome.
0:07:29 And then, a little while
later, we shut down Gears.
0:07:32 But, even with, like, just the
few properties using Gears, it was
0:07:35 obvious that the web needed this.
0:07:38 And there's a guy at Google who was HTML5
spec named Hixie, Ian Hickson and he
0:07:45 just worked right down the hall from me.
0:07:46 And he was like, we have
to standardize this.
0:07:49 We have to specify it.
0:07:50 His philosophy was like, The web is
what browser vendors ship, you know,
0:07:55 that's just the reality, you know,
and Chrome has shipped this and then
0:07:59 shortly thereafter like Safari was
working on shipping it and he was
0:08:02 like we have to have a spec for this.
0:08:04 Otherwise, no one's, it's
not gonna be interoperable.
0:08:06 So he wrote it down and he designed the
web SQL API, web SQL database, which
0:08:11 was a JavaScript API around SQLite.
0:08:14 Which was inspired by Gears.
0:08:16 I helped, like, edit the spec.
0:08:18 And That took us to WebSQL database.
0:08:20 The story actually has this long and
sad history Beyond that, because, you
0:08:24 know, of course, WebSQL got killed too.
0:08:27 Yeah, well, as, as many products and great
ideas within Google, but looking at the
0:08:34 looking at it as a glass half full, I
think each of those has brought new ideas
0:08:41 and started new things that I outlived.
0:08:44 The initial products.
0:08:45 So I think now SQLite
is far from being done.
0:08:50 So it's really like a technology of the
decades and is still getting better.
0:08:56 And I think we should do entire shows
also just on SQLite and local first.
0:09:01 Were there any other ideas that
are sort of noteworthy that came
0:09:05 out of the gears project that
also made it in today's browsers.
0:09:10 Yeah, absolutely, you know, geolocation.
0:09:12 We shipped geolocation.
0:09:13 We were the first way that you could get
access to geolocation programmatically
0:09:16 in web browsers and the API and the guy
who designed that API was like on my team
0:09:21 and the API that ended up in browsers is
almost like word for word the same API
0:09:26 and Workers so the very first version of
Gears had three APIs offline boot, like
0:09:33 the inability to boot a web app offline.
0:09:35 So it had a sort of equivalent,
something a little bit like AppCache.
0:09:38 And then it had workers, so that
you could do sync processing in the
0:09:42 background without blocking the UI thread.
0:09:44 And it had a database based on SQLite.
0:09:47 And all three of those are the
first release, and all three of
0:09:49 those APIs became web standards.
0:09:51 You know, not the exact same API,
but they directly influenced, I mean,
0:09:54 basically, Hixie was like, we better
write this down, because people
0:09:57 are going to start implementing it.
0:09:58 So.
0:09:59 In that way, Gears definitely had the
impact that Google and that, you know,
0:10:04 I hoped it would have, that it did move
the web forward a lot, really fast.
0:10:08 That's incredible.
0:10:09 You had like all of those
foundational ideas already back then.
0:10:12 And I feel like now, what is it like
definitely more than 10 years later,
0:10:19 the web still feels like to just about
discover those bigger primitives that
0:10:24 we can actually use storage to build
real web apps, that we can use workers
0:10:29 to make things more performant and
kind of spare the main thread a bit.
0:10:33 To keep the app more responsive.
0:10:35 So all of those capabilities that you
all kept thinking of way, way back,
0:10:41 I feel like step by step that the
web is finally waking up to those.
0:10:45 So I think storage is really like
the main thing on your mind there.
0:10:50 Yeah, I mean, there's so much to talk
about, I'll try not to ramble, , you said
0:10:53 10 years, it's been more than 15 years.
0:10:55 Like, it's 2023, we
launched Gears in 2007.
0:10:59 So it is crazy how long these things take.
0:11:02 it hasn't been a, it has not
been a straight line it wasn't
0:11:04 Google that , killed WebSQL.
0:11:06 It was actually Firefox
kind of, and Microsoft.
0:11:09 Like, basically, the browser
vendors wouldn't implement it.
0:11:11 They were afraid that it would
not be able to be standardized.
0:11:14 Which I think is not really true.
0:11:15 We could have done that but it
would, there was a fear and it,
0:11:18 I think it was a legitimate fear.
0:11:19 But I think ultimately
we could have done that.
0:11:21 And so we sort of randomly got
IndexedDB out of the deal instead.
0:11:26 And it, you know, the vendors
were looking for an alternative
0:11:30 that was standardizable, right?
0:11:32 And so this thing sort of emerged.
0:11:35 And like one of the, one of the like
participants in the W3C list or the
0:11:38 H, the WhatWG list proposed this.
0:11:40 And it was like, it fit.
0:11:43 The sort of strategic goals of the other
vendors, but, and so it got specified and
0:11:48 implemented really quick, but just one of
those things where it wasn't coming from
0:11:52 a place of people actually using it, you
know, and wanting to build things with it.
0:11:56 And so it just has this just like
always happens when you do that, like,
0:11:59 it just has this really weird API
shape and so, you know, IndexedDB like
0:12:03 famously never got used for anything
and then we didn't have Web SQL either.
0:12:07 And then meanwhile, the browser
vendors kept, well, people kept
0:12:11 trying to put SQLite in the browser
because SQLite is so awesome.
0:12:13 It's so useful, , and so people kept
looking for a way to do this both inside
0:12:17 browser vendor companies and outside.
0:12:19 Google had this team, a sub team
of Chrome, working on this thing
0:12:22 called NaCl, and that was like,
you know, an assembly language that
0:12:25 could run in the web, sandboxed.
0:12:27 And the predecessor to WASM.
0:12:29 One of the main, use cases, was we
could run SQLite in the browser.
0:12:33 And we wouldn't have to
standardize it, right?
0:12:35 Because the standard would
be lower level, right?
0:12:37 But nobody wanted to, the other
vendors didn't want to implement
0:12:41 Yeah, so then that didn't work.
0:12:42 And then they tried PNaCl, which was
like supposed to be like a more portable
0:12:45 version of it, but then that, they,
the vendors wouldn't implement that.
0:12:48 And for a little while people
were like, Oh, we can just
0:12:50 compile everything to JavaScript.
0:12:51 That was like, you know, asm.
0:12:53 js, and people tried
compiling SQLite to that.
0:12:57 And that, I mean, it kind of worked.
0:12:58 But then eventually Mozilla proposed
Wasm, which was like basically a
0:13:02 really closely related idea to NaCl.
0:13:04 And and then everyone got behind that.
0:13:07 And so then people started
putting SQLite in that.
0:13:09 And then, you know, humorously around
the same time Safari killed cross
0:13:15 site caching for privacy reasons.
0:13:17 So, using SQLite this way is like a
little bit hobbled because it means like
0:13:20 every app has to cache it themselves.
0:13:23 But yeah, it's been a, it's
been a long story and you know,
0:13:26 there's way more to it than that.
0:13:27 Why do the platforms grow so slowly?
0:13:29 There's like technical reasons and
there's sort of political reasons and
0:13:31 strategic reasons from the companies,
but like, I think also it's like,
0:13:34 There's this economic thing that happens.
0:13:36 I think like humans are sort
of lazy and risk averse.
0:13:39 You know, not in a bad way, just like,
no one uses storage on the web, right?
0:13:44 And so if you're building a new app on
the web, and say you want to build, I
0:13:48 don't know, a new competitor to Google
Slides or something like that, right?
0:13:52 Are you going to use storage?
0:13:53 It's like a, it's like a high risk
thing, because no one else does
0:14:00 Challenges of the Permissionless Web
0:14:01 So zooming out a little bit the
web is not the only platform.
0:14:04 We have native mobile
platforms, iOS, Android.
0:14:08 We have also native desktop
operating platforms.
0:14:10 So most of those have storage
mechanisms since otherwise, if I.
0:14:16 Reopen an app on my iPhone and it has
lost all my data that wouldn't be great.
0:14:21 Whereas that is the more
common experience on the web.
0:14:25 So why do web apps feel so
different compared to native apps?
0:14:30 Yeah.
0:14:31 I mean, this is a question as old as time.
0:14:33 I mean, people have been asking this
since I started programming on the web.
0:14:36 And I think it's this like
really deep and interesting.
0:14:39 Question.
0:14:40 So why is it hard to put
storage in the web platform?
0:14:42 Why has it taken so long?
0:14:43 A, a big part of it is just
the web is zero permission.
0:14:46 It's permissionless, right?
0:14:47 That's like the web's superpower.
0:14:49 That's what make, that's why we
still have the web and it, you know,
0:14:52 iOS is like a, on a, on technical
merits, a superior platform.
0:14:55 You can't deny it, but the web
has this one thing that no other
0:14:59 platform has, and that has made it
so powerful that it's permissionless.
0:15:02 You can send a link to your friend and
they see the picture of your cat, that is
0:15:06 something that doesn't happen on any other
platform and it's super, super important.
0:15:10 It's why I started programming for the
web and it's why probably many of us did.
0:15:14 It's like when you're a
kid and you got notepad.
0:15:16 exe, you know, and you know, an
FTP client, you can like write
0:15:19 some, put it on your webpage
and share it with your friends.
0:15:21 You don't need anyone's permission.
0:15:22 You don't need an account.
0:15:23 You don't need a credit card, but
this superpower is also the source
0:15:26 of all the web's difficulties.
0:15:28 Like the fact that the web is
permissionless means that it can't have
0:15:31 any permission that could be dangerous.
0:15:33 That could be a security issue
that could be privacy issue that
0:15:36 could hurt you or your computer.
0:15:38 And so it's different than a platform
that's more managed and so just
0:15:41 from a platform design perspective,
figuring out how to put storage in
0:15:44 browsers has been difficult, right?
0:15:45 Because you, you know, a
malicious app, you don't want
0:15:48 it filling up your disk, right?
0:15:49 Making the other apps not work right.
0:15:51 Or like consuming all of
the storage quota, right?
0:15:53 And from a privacy perspective, you don't
want people using the storage to like,
0:15:57 you know, track you or whatever, right?
0:15:59 Because of the way that the web
is permissionless, it has grown
0:16:02 an ecosystem of apps that are like
different than native apps, right?
0:16:05 Only recently people have started
using the web for like sort of
0:16:08 personal productivity apps like
note takers and stuff like that.
0:16:11 You know, like you think about like
traditional platforms, they tend to
0:16:15 focus on apps that are single user,
you know, like the bread and butter
0:16:19 of iOS is like single user apps.
0:16:20 Right?
0:16:21 All the apps that it's
shipped with, right?
0:16:22 Those are all things you use alone, right?
0:16:25 And storage is easy for
those kind of apps, right?
0:16:28 Desktop platforms have had
storage for a long time, right?
0:16:31 But because the web is permissionless,
it has tended to be strong in
0:16:36 collaborative applications, right?
0:16:38 And also apps that are huge,
where there's like way more data
0:16:41 that you could possibly fit.
0:16:42 On your device, right?
0:16:44 Google search, Google Maps, Gmail, right?
0:16:46 All of these products are like
things where you couldn't actually
0:16:48 run them on your device, right?
0:16:50 Like they need a lot
more computers to run.
0:16:52 Even assuming that you have storage,
like once we added gears, right?
0:16:56 Once you have that, even using it is hard
because you have to figure out how to use
0:16:59 it in a multi user, like, environment.
0:17:01 You have to figure out sync
and conflict resolution.
0:17:04 And then because the data can be
bigger than can fit on your device,
0:17:06 you have to figure out not just
sync, but partial sync, which is
0:17:09 like this whole other harder part.
0:17:11 And then you have to figure
out authorization and sync.
0:17:13 Like with iCloud, your own
data back and forth, right?
0:17:15 You have permissions to it.
0:17:17 But in, in like a classic web
app, you only have permissions
0:17:19 to a tiny subset of the data.
0:17:20 So you have to do partial
authorized sync, right?
0:17:23 And then on top of that, the storage
isn't reliable because the browsers
0:17:27 have to implement it in such a
way that that apps can't abuse it.
0:17:30 That means as an application developer
that it can disappear at any moment, which
0:17:33 is also different than a native platform.
0:17:35 So I not only have to build a much more
complicated syncing mechanism, I also
0:17:39 have to make that syncing mechanism
robust to the fact that the storage
0:17:42 underneath it can just disappear.
0:17:44 I think there are like legitimate
technical challenges and then on top
0:17:47 of that, I think there are sort of just
natural human challenges to to like doing
0:17:51 something that no one has done before.
0:17:53 Web storage
0:17:53 Right.
0:17:53 So before diving into those let's
maybe dig a little bit more
0:17:57 into the technical challenges.
0:17:59 So you've posed them as challenges
and given that over the last.
0:18:03 10, 20 years, the web has changed
significantly in, in terms of the things
0:18:09 that have been standardized et cetera.
0:18:11 So I think a few of those
challenges are always inherently
0:18:15 challenging due to the nature of
the web, which is permissionless.
0:18:20 But given some of the technological
improvements, I'm wondering which
0:18:24 of those challenges are much more
manageable now and why, and what are
0:18:28 those improvements that have been landing
and how do they make things easier now?
0:18:33 the main thing is browsers have
storage now, like, they didn't
0:18:36 have storage for the longest time.
0:18:38 I feel like my mission in life
is just like I'm shouting from
0:18:41 the mountaintop Hey, did you
know browsers have storage now?
0:18:45 I feel like largely
developers don't know this.
0:18:47 In fact, I was on a tweet thread
just yesterday where someone well
0:18:50 known in the web, in the software
development community, like, very
0:18:54 respected, was like, wait, browsers
have more than 5 megabytes of storage?
0:18:57 Like, yes, they do.
0:18:59 On most devices browsers have
like gigabyte of storage.
0:19:02 You know, , the actual
quota is complicated.
0:19:04 It's dependent on how much free space
you have on your device and what browser
0:19:07 you're using and like how many other apps
are using storage and blah, blah, blah.
0:19:11 But I mean, you can assume as a
web developer that you have access
0:19:14 to like hundreds of megabytes of
storage locally on the device, which
0:19:18 in almost all cases now is SSD.
0:19:20 It's like almost memory.
0:19:22 You know, we have a local cache,
persistent cache that can store
0:19:25 hundreds of megabytes of data.
0:19:26 And if you're not using this as a web
developer, you are leaving a massive
0:19:30 amount of performance on the table.
0:19:32 We have a whole community of like web
developers who are constantly talking
0:19:35 about how much performance matters to
them and how performance is the most
0:19:38 important thing and they have this
massive cache sitting on the device
0:19:42 that they're not using, so we have the
primitive, you can sort data in browsers.
0:19:46 But we now need to develop the patterns
and libraries and techniques and
0:19:51 mindshare for people to know that
they can use this and how to use it.
0:19:54 I fully agree.
0:19:55 This is exactly where I wanted to go to.
0:19:58 We have the primitives now, we had
some cruder primitives in the past.
0:20:02 But I think those primitives
are getting a lot better now.
0:20:05 They work more consistently
between browsers.
0:20:08 They're getting more performant.
0:20:09 Some restrictions are no longer
there, but as you say, now it's a
0:20:13 matter of building the layers on
top, building the libraries, building
0:20:17 good tooling, building things like.
0:20:19 Browser dev tools that work with us.
0:20:22 And so I think that's one major part.
0:20:24 And then the other major part is to
getting people, like you say, like you
0:20:29 go into mountaintop and shout it down.
0:20:32 This is what needs to happen as well.
0:20:33 Besides building great tools, since
otherwise people kind of stick
0:20:37 with the old way of doing things.
0:20:39 But maybe in the context of the storage
of the web maybe you want to draw a
0:20:46 quick bridge to what you're working on.
0:20:48 Roci Corp, Replicache and Reflect
0:20:48 Yeah, sure.
0:20:49 So I'm the founder of
this company, Roci Corp.
0:20:51 It's basically collection of my friends
from Google that worked on Chrome
0:20:55 mostly with me and and we loved the
work that we did there and like the
0:21:00 quality of work that we built and we
wanted to keep doing it on our own.
0:21:03 So we formed this small company.
0:21:05 We're fully distributed and we have two
products around multiplayer and local
0:21:09 first Replicache is client side only so
it's a library that you include in your
0:21:14 app and you can think of it sort of as
like a wrapper around local storage.
0:21:18 We actually use IndexedDB, not SQLite and
I think I think IndexedDB is slept on.
0:21:22 I think like it has a lot of
advantages and we're probably going
0:21:25 to continue to use it for a while.
0:21:27 But it's doesn't matter.
0:21:28 There's multiple storage mechanisms now
in browsers and they have trade offs.
0:21:31 So anyways, we have Replicache,
which is client side only, and it's a
0:21:34 wrapper around local storage that has a
synchronization protocol built into it.
0:21:38 A robust, high quality synchronization
protocol that can do partial sync,
0:21:41 that can do authorized sync that
can store hundreds of megabytes of
0:21:44 data locally is very performant.
0:21:46 That can do 60 frames per second,
like responsiveness client side.
0:21:50 And, you know, people build apps out
of this, you know, like, one of our
0:21:53 biggest prop proponents, like Dax,
is online today, talking about this
0:21:58 crazy app that he has built that's
competing with Vercel using Replicache.
0:22:03 And but you know, implementing
the backend for a synchronization
0:22:06 system is also challenging.
0:22:07 And so people asked us for
a hosted solution for this.
0:22:11 And so we also have Reflect,
which is the complete package that
0:22:15 includes the service that syncs.
0:22:17 And it's, basically the same
thing as Replicache, but with
0:22:20 but with the backend as well.
0:22:22 Got it.
0:22:22 So can you explain a little bit
more the cases when I would be
0:22:26 using Replicache as opposed to
when I'd be reaching for reflect?
0:22:31 Yeah so Replicache is like,
you want control of everything.
0:22:35 Like, as much as you can have.
0:22:37 Basically Replicache can
connect to not any backend
0:22:40 stack, but many backend stacks.
0:22:41 You can implement a Replicache connector
for basically any relational database,
0:22:44 for most of the document databases, you
know, you can even implement a backend
0:22:48 for, like, your custom distributed system.
0:22:50 So it's more effort, but it's more
flexible and adaptable, right?
0:22:53 Reflect is very opinionated.
0:22:55 It's a complete hosted service
that's tightly integrated and
0:22:58 it's designed to be very fast.
0:23:00 It leaves some, it's for, like,
when you're starting something
0:23:03 new, and you don't have a lot of
time, and you just want it to work.
0:23:06 Tabs are challenging
0:23:06 So I'd be curious to learn a little bit
more about the challenges that you were
0:23:10 facing building Replicache and building
Reflect as it relates to the challenges
0:23:16 you've mentioned before in regards to
storage and other challenges we might not
0:23:20 have talked about yet when it comes to
building such a technology for the web.
0:23:24 Yeah.
0:23:26 there's a lot of little things
that you discover when you set
0:23:29 out to do something new like this.
0:23:31 And a lot of times, you know, in
software engineering You know, a lot
0:23:34 of the work comes from like unexpected
places, you know, it's not the
0:23:37 algorithm, it's not the core algorithms
or the data structures or whatever.
0:23:39 It's like dealing with the practicalities.
0:23:42 Like one thing that is really a
quirk of the web that is another one
0:23:45 of the web superpowers, but really
makes this challenging is tabs.
0:23:49 Like, the web has tabs and tabs from
like a platform software developed,
0:23:54 like a software engineering perspective
are weird because they are different
0:23:57 execution environments, right?
0:23:58 It's as if.
0:24:00 You have an application, but it
has like, it has many different,
0:24:03 like, places where code can run.
0:24:05 Many, like, it's as if you had
a bunch of different processes.
0:24:07 They're not, tabs aren't really different
processes, but like, from a software
0:24:10 engineering perspective, they're kind
of like processes because they're
0:24:12 different execution environments that
can have different code in them, right?
0:24:15 Like, you could have different
versions of your app with different
0:24:18 code bases running in each tab.
0:24:19 Like, if the server updated
and and one tab updated, but
0:24:23 the other didn't, you know?
0:24:24 But they share storage.
0:24:26 So that is a weird thing.
0:24:28 Usually when platforms have a situation
like that, where you have processes
0:24:31 or threads, they also have locks
so that you can like protect the
0:24:34 storage and coordinate access to it.
0:24:36 But the web has kind of has like
a fledgling web locks API, but
0:24:40 it is very unused and tested.
0:24:42 And there's a lot of edge cases in it.
0:24:43 And we don't really trust it.
0:24:45 Like our company doesn't use it and
trust it because we investigated
0:24:48 a bunch of these edge cases and
they're sort of like underspecified.
0:24:52 I don't believe that they're
consistently implemented across browsers.
0:24:56 And we've even had people like on browser
teams like recommend that we don't use it.
0:24:59 You have to figure out a way to
deal with the fact that You have
0:25:02 this persistent storage, right?
0:25:04 And one tab can update and the
other tab cannot be updated.
0:25:07 And then what happens?
0:25:09 Right?
0:25:09 And There's always a problem
with these kind of systems of
0:25:12 like schema migrations, right?
0:25:13 You have to figure out schema migrations,
but it's harder on the web because you
0:25:17 have schema migration on the server
You have schema migration on the client
0:25:20 But then you have the problem that one
tab can update and like want to migrate
0:25:24 the schema forward to like the version
of the Storage that it wants, but the
0:25:28 other tab is like still back on the old
version, you know, like what does it do?
0:25:31 So these are just like
fun practical problems.
0:25:34 So I would actually love to learn a
little bit more about either of those.
0:25:38 And so are those challenges that you've
been facing and that you can fully take
0:25:44 care of on behalf of an application
developer, are you able to like go some
0:25:49 way, but still leave some of the hard.
0:25:52 trade offs to an application developer
and there's some path, some like bad
0:25:57 or even worse trade offs someone needs
to make as an application developer,
0:26:01 they ultimately have to choose.
0:26:04 So how we're able to work around those?
0:26:06 My view is that in order for storage
to be widely used on the web, it
0:26:11 has to be as easy as, easier than
like building a normal web app.
0:26:16 It has to be easier than
building today's web app, right?
0:26:18 And I think that we can get there and
the and the people who need to fill that
0:26:22 gap, who need to make it easier than
today's web apps are library developers.
0:26:26 Like, it's not gonna be browser
vendors because they move way too slow.
0:26:29 Like, it's gonna be library developers
because we have this , awesome
0:26:32 ecosystem of people furiously tr trying
different things to figure this out.
0:26:37 So we have completely solved the cross
tab thing, and I think our solution
0:26:40 to it is, I'm really proud of it.
0:26:42 Like we put a lot of work into it.
0:26:44 It's for this like tiny moment when your
app is updating we put this massive amount
0:26:47 of effort into this, like 10 seconds
at worst when your app is updating and
0:26:52 like two tabs have different versions
but we made it really like elegant.
0:26:56 And like, you don't
have to think about it.
0:26:58 Like basically what happens is
as a developer constructor for
0:27:03 Replicache, you specify the version
of the database that you want.
0:27:06 And that's an identifier that you choose.
0:27:08 So you say like, I want version
seven and you can create as many
0:27:11 different schema versions as you want
in Replicache, and they'll each be
0:27:14 isolated from each other, fully isolated.
0:27:16 And when we talk to the server, we
send in the request the version of the
0:27:21 schema that we're asking on behalf of.
0:27:23 So the server has to respond with
that version or say, I can't serve
0:27:26 that version, you need to reload.
0:27:27 But then internally to deal with that
moment when tabs are on different schema
0:27:32 versions, we actually fork the database
and we have both running at the same time.
0:27:37 So typically in Replicache,
the storage is shared, right?
0:27:41 So you make changes in one tab and
you see them instantly in the other
0:27:44 tab whether you're online or not.
0:27:45 But for this moment, when a schema
update is happening, they fork.
0:27:48 So the tabs can continue independently
and they can continue working.
0:27:51 You know, a concern is like, if you're
typing in a, in an input, you don't
0:27:54 want to just reload the app at that
moment to get the new code, right?
0:27:56 The user could lose their work
or just be frustrated, right?
0:27:59 So you want, you need to allow
the app to continue running for a
0:28:02 little while until it thinks that
it's the right time to update.
0:28:06 That sounds incredible.
0:28:07 And that sounds like
an absolute nightmare.
0:28:09 If like I, as an application developer,
it's hard enough to ship the app
0:28:15 version that I have, and then to even
like really think about that there
0:28:19 is this point of time where a user
has the old version up and running.
0:28:23 And to then just like throw multiple
tabs into the mix here as well.
0:28:28 So, I think whatever pain you
can take away from my application
0:28:32 developer here is amazing.
0:28:34 So yeah you've been mentioning the various
app schema versions and that does at
0:28:39 least locally speaking forks the database.
0:28:42 And I suppose then there's some mechanism
how the forks are eventually being.
0:28:48 joined or merged again, or how if the
different tabs are still being used,
0:28:55 how did those forks come together again?
0:28:57 Well, what happens is they're both
still talking to the same server, right?
0:29:01 So the they're local storage
forks but they're still talking
0:29:04 to a shared truth on the server.
0:29:06 And the server and when tab a makes a
request to the server, it says like,
0:29:10 hi, I, I want to talk and I'm talking
schema version seven and when tab
0:29:15 B sends a request to the server, he
says, I'm talking version eight and
0:29:18 the server can choose to speak both
versions if it wants, or it can choose
0:29:22 to tell seven, I can't talk to you.
0:29:23 I only know version eight but
that doesn't mean that tab seven
0:29:26 has to reload at that moment.
0:29:27 Tab seven can continue working
without a server connection, right?
0:29:30 Because it's local first.
0:29:32 And then it can decide to
reload when it's ready.
0:29:34 Let's say we have tab a and tab
B and they're happily working
0:29:39 in the same version right now.
0:29:41 Is there some communication mechanism
between those two tabs that that
0:29:45 doesn't rely on the server alone?
0:29:48 Yeah, under normal circumstances,
the storage is shared.
0:29:51 So you make changes in tab.
0:29:53 If you're off totally offline
with Replicache or reflect,
0:29:56 and you make changes in tab
a, you will see them in tab B.
0:29:58 They share storage, right?
0:30:00 It's just at this moment when an
upgrade happens, they fork momentarily.
0:30:04 Just to maintain like integrity of the
system, like, so that you don't have.
0:30:09 The schema changing
underneath one of the tabs.
0:30:11 And, you know, that is like a little bit
of a rough edge in the like, abstraction.
0:30:17 You know?
0:30:18 But, under normal circumstances, you're
never going to notice this as a developer.
0:30:22 And it's like, the cleanest
solution that we could come up with.
0:30:24 I agree.
0:30:25 I think it's not like that you're
rolling out a new release constantly.
0:30:29 I think the, still the majority
of the time where the app is being
0:30:32 used, that you're not upgrading.
0:30:35 And so for that little period of
time to have a simpler solution to
0:30:39 this very gnarly problem, sounds
like a very good move to me.
0:30:44 So in the case where it's not
currently upgrading, you mentioned
0:30:47 that those two different tabs.
0:30:50 Share storage.
0:30:51 Does that mean they share the same
IndexedDB database or is there even more
0:30:56 sharing, such as like sharing an array
buffer between those tabs, or what is
0:31:01 the communication mechanism between those?
0:31:03 Are you listening to changes in
IndexedDB, is there sort of like
0:31:08 a broadcast channel between those?
0:31:10 How does the tap interplay work?
0:31:13 I'm so glad you're asking these questions.
0:31:14 Like, I don't know if our listeners
will care about these details.
0:31:17 I hope they do.
0:31:18 Because this is like,
the fun part, you know?
0:31:20 But Yeah, this gets to another one of
the practical challenges that I am proud
0:31:23 of in our implementation that I, that
we put a lot of work into, which is
0:31:26 like we, it was very important to us.
0:31:29 And I know important to you too.
0:31:30 And a lot of other people in this space
that you have 60 frames per second
0:31:33 interactivity, like at, you know, that we
want people to be able to use Replicache
0:31:38 as if it's memory, you know, as if it's
your, as if it's your state model, like
0:31:42 one of the benefits that should come
out of adopting these tools is that you
0:31:44 don't need complex state management
libraries, you know, you have this like
0:31:48 database locally You should be able to
use that as your as your state but when
0:31:52 you look at that from like again from
like an engineering perspective, it's
0:31:55 actually not so easy because You know
storage local storage on SSD is fast.
0:32:01 Sure You know SQLite is fast IDB is
not fast, but you can like wrap it and
0:32:06 do things to it to make it fast but
it's nowhere near as fast as memory.
0:32:09 It's not 60 frames per second.
0:32:10 It's an order of magnitude slower, right?
0:32:12 So, so how do you bridge that gap, right?
0:32:15 And if you want to have cross tab
consistency, if part of the product design
0:32:19 is that you make changes in tab A and
they reflect in tab B, then you cannot
0:32:24 use storage alone as your communication
mechanism because it's too slow, right?
0:32:28 So you have to have memory inside the
tabs at some level, you have to have
0:32:31 memory like that has the state in the
tabs because that's the only way it can
0:32:34 be fast enough and then you again have a
synchronization problem like a distributed
0:32:38 system problem between the tabs, right?
0:32:40 They're changing independently.
0:32:41 So how do you resolve that?
0:32:43 There's like different, I think there's
different legitimate ways to address
0:32:45 this, but the way that we do it, which
is that we basically, we use the storage
0:32:49 as like, We, we run in memory, Replicache
runs in memory, like in the JavaScript
0:32:53 thread, in the main thread, right?
0:32:55 So it's right there next to your app.
0:32:57 It's crazy fast and it lazily
loads and stores to IDB.
0:33:02 And we have a, basically a
synchronization protocol between the
0:33:04 tabs which you can kind of think
of it roughly as like two Replicache
0:33:09 browsers, like sync via the server
and two Replicache tabs sync by IDB.
0:33:13 That's like the basic structure.
0:33:15 And yes, we need to have a way to know
when something has changed cross tabs.
0:33:18 And for that, we use broadcast channel.
0:33:21 But like, you know, it's the same
if you're familiar at all with
0:33:23 Replicache, the server doesn't
send data proactively to the client.
0:33:27 The server only sends a poke
that like a tap on the shoulder
0:33:30 that something has changed and
the client requests the changes.
0:33:33 And we kind of do the
same thing cross tab.
0:33:35 Like we, we use broadcast channel to
tell the other tab, Hey, IDB has changed.
0:33:39 And then.
0:33:40 That tab is like running as fast
as it can in memory and it has like
0:33:43 a background process to refresh
itself from storage periodically.
0:33:47 I'm very curious to learn more about
that background process as well.
0:33:52 Are you leveraging workers at all in
your implementation here, or is this
0:33:57 mostly running in the main thread?
0:33:59 And this is where given that you
have multiple tabs, multiple main
0:34:02 threads is most of Replicache
running in the main threads.
0:34:06 We don't use workers as part
of the implementation of
0:34:09 Replicache Currently at all.
0:34:11 you know, we, We want people to be able
to use Replicache as if it's memory,
0:34:15 it should be as fast as memory and, the
only way to do that is to be memory, you
0:34:19 know, you could have something running
in another thread, in another worker,
0:34:22 but then you're still gonna have to have
state and memory, right, so, What we
0:34:26 landed on was, we have Replicache as a
in, like an in memory main thread thing.
0:34:33 It has a background process that syncs
with IDB, but that is just like a periodic
0:34:37 task that's running on the main thread.
0:34:39 You can easily run Replicache
in a worker, and many people do.
0:34:42 People, like, people do
this to do full text search.
0:34:45 They run Replicache in another tab, they
do, you know, indexing in that, or they
0:34:50 run it in a worker, they do indexing
in that worker, and then they, like,
0:34:52 access that index from the main thread.
0:34:54 And because of the cross tab communication
that we have, it works fine across workers
0:34:58 too, workers in the main thread, you know,
but where to put workers in your stack is
0:35:03 like a, is a, is an application developer
question not a Replicache question
0:35:09 I think it's very possible that
we would implement workers.
0:35:11 We would add workers to various parts
of the implementation of Replicache,
0:35:15 like as an implementation detail, you
know, like there's some background
0:35:18 tasks that we need to do, like cleaning
up things, you know, that are heavy.
0:35:21 And it would be useful to have those
on a background thread to make sure
0:35:24 they don't interfere with the UI.
0:35:27 The one thing that like people
frequently ask, and it has come up over,
0:35:31 over the development of Replicache,
whether to use service workers.
0:35:35 and because it, it seems so tempting.
0:35:39 It's like this shared place that you
can run code, you know, across tabs.
0:35:42 But man, service workers are like
another part of the web platform.
0:35:45 That's just so hard to use.
0:35:46 You know, it's just so gnarly,
and I feel like almost nobody
0:35:49 knows how to use them, you know?
0:35:51 And like, there's so few examples
of them being used successfully.
0:35:54 And if we use service workers in
Replicache, it would have impact
0:35:57 on how people build their apps.
0:35:58 So we just haven't gone there.
0:36:00 Once you're just a little library that
you use in your JavaScript app, then
0:36:05 I think that keeps things way simpler
since I think very few JavaScript
0:36:09 developers are even aware of the
concept of a thread in the context
0:36:14 of building like their React app.
0:36:16 And so a worker is a thread, but once
you have a library or technology,
0:36:20 that spans, the main thread that spans
workers or service workers, then you
0:36:25 need to conceptually deal with that.
0:36:27 But it also becomes a tooling
and a bundling problem.
0:36:31 So this is where I think the best
technology that we have for those sorts
0:36:35 of patterns right now would be Vite
0:36:38 and my opinion
0:36:39 so have you had success or not so much
success with certain technologies?
0:36:45 We love Vite it's like my default.
0:36:48 It's kind of a funny story, like, when
I started RociCorp which was, like I
0:36:52 said now, almost four years ago I wasn't
up to date with like the web, like,
0:36:56 and like the popular open source tools.
0:36:59 And my friend was like,
you gotta check out Next.
0:37:02 js, it's like, so awesome,
like, you guys should figure
0:37:05 out how to integrate with Next.
0:37:05 js, and like, I started, like, working
with it, and I was like, oh, this is
0:37:08 like a really cool DX, but like, I'm
trying to, like, what is it, like,
0:37:11 what's the core value here, I couldn't
put my finger on it, like, it's like,
0:37:14 it's hosting, like, there's the the
thing where you have deploys that are
0:37:18 like, like, preview deploys, that's
really cool, but like, is that, I'm
0:37:20 trying to think, like, why is this so
exciting, and I finally realized, it's
0:37:24 like, the easiest way to set up React.
0:37:26 That's really like the back then, like
that's the core of it, you know, that's
0:37:29 how like it's like setting up a react
project is just so hard, like, and then
0:37:34 I, you know, I think V has taken the
has taken the crown on that front now,
0:37:39 Yeah, I think, so my take is that if
you're using Next and typically you
0:37:43 then deploy it on Vercel, I think that's
great for like anything that's like
0:37:48 a more on the, if there's a spectrum
from website to web app, then I think
0:37:53 this is rather where you start on the
website spectrum and make it more,
0:37:57 add more and more app like features.
0:38:00 But I think it becomes increasingly
hard if you want to build a
0:38:04 local first app with Next.
0:38:06 js as you want to introduce those
capabilities, as you want to introduce
0:38:10 really deep storage mechanisms or
once you want to work with workers.
0:38:14 I'm sure it's on their roadmap somewhere.
0:38:17 But I think they, they've just started
their journey on one side of the spectrum,
0:38:21 which is, I think, rather to the websites.
0:38:24 And that's great and
that works really well.
0:38:26 Server side rendering, React server
components is great for this use case.
0:38:31 But I think once you want to build web
apps that really feel more, almost like a
0:38:37 native app, I think this is where you need
to reach for a different tooling stack.
0:38:41 And I'm currently very happy with
Vite as it has support for workers
0:38:46 as a first class citizen, was a
bit rough over the last few years.
0:38:49 But it has gotten a lot better with every
release and I'm very happy using it.
0:38:55 And I've even seen a few libraries
also shipping workers out of the
0:38:59 box that work quite well with Vite
0:39:02 so an example here would
be the SQLite WASM built.
0:39:05 That also ships with some workers out
of the box, which works pretty well,
0:39:11 yeah we use it often and like it as well.
0:39:14 I don't have as much experience
with workers in particular just
0:39:17 because we haven't taken it on as
like an implementation detail yet.
0:39:20 But yeah, just overall we have a lot of
success with using it for our samples.
0:39:24 And like, you know, when you're
building this kind of stuff, you end
0:39:26 up making apps all the time, right?
0:39:28 So speaking of maybe
this is a good segue to.
0:39:32 How I would use Replicache or reflect
in, in my, let's say in my React app.
0:39:39 So I think you've been mentioning MobX.
0:39:42 Is that a typical technology that you
use Replicache with, or does Replicache
0:39:48 completely replace something like MobX?
0:39:51 MobX, Redux, Zustand, all those all
those sort of state technologies.
0:39:56 Are they complimentary or are they
rather being replaced by Replicache?
0:40:02 I think long, like long term they're
being replaced but the reality is
0:40:06 that Replicache isn't there yet.
0:40:07 Like these are, you know, very well
developed, like sophisticated tools,
0:40:11 you know, like that people have,
Developed, like to do legitimately
0:40:15 hard things, you know, like, you have
a fairly large data set in memory and
0:40:19 you're trying to update like little
bits of it reactively, you know, that's
0:40:21 like a legitimately hard problem.
0:40:23 And so Replicache has an API like A
subscription, API that's memory fast.
0:40:28 And I think it actually competes
well with like SQ lite based systems.
0:40:32 In many cases it's faster.
0:40:34 But.
0:40:35 I mean, if you're building something
like Dax is building, you know, that
0:40:38 has like a lot of data in it like 30,
000, 50, 000 records, you know, and,
0:40:43 you know, you're trying to do 60 frames
per second updates in there, and you
0:40:46 have a lot of, like, computation, like,
derived computation chains in memory,
0:40:50 like, we don't have the, we don't have
the APIs in Replicache yet that, that can
0:40:54 compete with, like, MobX or, like, Signia
from TLDraw, like, things like that.
0:41:00 And the cool thing is like, the
design of Replicache is complementary
0:41:03 to putting those things on top.
0:41:04 Like at the bottom of the Replicache
abstraction stack, you have a
0:41:07 key value store that's reactive.
0:41:09 You know, so you can like plug those
reactive changes, like, into your into
0:41:12 Zustand or whatever, and it'll work great.
0:41:15 It's interesting, like, different people
in the space started at different angles.
0:41:18 Like, I think that's something
you've been passionate about,
0:41:19 like, from the very beginning.
0:41:21 There's so many exciting things
happening in local first.
0:41:23 Like, other people have
started focusing there.
0:41:25 We started, like, a lot more on making
the synchronization correct and robust.
0:41:29 And making partial sync
work, authorized sync work.
0:41:31 You know, making the mass
storage, like, really fast.
0:41:34 And we still have to like finish up
the libraries legitimately, like the
0:41:37 API layer to make it really nice.
0:41:39 I think that it's going to be competitive
with like using those types of
0:41:42 tools, like, you know, next quarter.
0:41:43 Yeah.
0:41:44 I mean, Replicache has been, I think,
one of the first solutions really been
0:41:49 on the local first market in that way.
0:41:53 And so, and I think you, you have
been quite ahead there in terms of
0:41:57 the work on syncing and just having a.
0:42:01 A fully fledged thing out there that
developers can use to build on top of and
0:42:06 that shows I think most most of the local
first apps that have been built over the
0:42:11 past one or two years, I think, use your
technology and I think that's already.
0:42:16 driving some of the change that
I want to see for our apps.
0:42:20 So are there some apps that that
you're particularly excited about,
0:42:25 where you say, okay, this is
exactly what I wanted to help create
0:42:29 more of or help create more of?
0:42:31 Well, I mean, right now the
one that, that I'm like most
0:42:34 excited about probably is sst.
0:42:36 dev, Dax's thing that I've
mentioned a few times.
0:42:39 Like just because, I don't
know it's an example of like a
0:42:43 data intensive application that
is like public that you can try.
0:42:46 A lot of our, a lot of our customers
are like, you know, they're private
0:42:49 things that, you know, not easy
for people to access outside.
0:42:52 And yeah, we have a lot of.
0:42:56 Customers using Replicache for things
that are like in the building industry
0:42:59 or like service industry where like,
like we have a customer that is building
0:43:03 like a tool that people who build
houses like would use and, you know,
0:43:08 they go out in the field and there's
intermittent connectivity and, you
0:43:11 know, actually like building a house
is like a super data intensive thing.
0:43:15 You know, there's like
thousands of elements on the
0:43:17 checklist to a house, you know?
0:43:19 And like lots of people that have to
come through and look at it and then
0:43:21 there's back office things that happen
and like, so it's like a perfect use
0:43:24 case, but it's not something that you
can like use, you know, that you could
0:43:28 go try and use right now because,
you know, it's a private system.
0:43:31 So yeah, I think like sst.
0:43:32 dev is like the best example
right now that I'm excited about.
0:43:36 I'm equally excited about the things that
I can use myself, as well as the anecdotes
0:43:41 I'm hearing about other technologies
being created for other people.
0:43:46 So I think this is what I'm particularly
excited about Local First, that it
0:43:52 makes it easier to build technologies
for use cases that were just not that
0:43:58 Viable before to, to build technologies
with the tools that we had before.
0:44:02 So what you've been sharing about
the construction use case here, or
0:44:07 you've been also privately sharing
a few other use cases with me,
0:44:10 those sounds, sound incredible.
0:44:12 And this is exactly why I'm
excited that local first opens
0:44:18 Replicache and local-first
0:44:18 So if I'm looking on Replicache.
0:44:21 dev or Reflect.net on Replicache.
0:44:25 dev, for example, it says
the way to local first.
0:44:29 So I'm curious what local
first means for you.
0:44:32 I think there's a whole bunch
of terms flying around, whether
0:44:36 it's offline first, local first.
0:44:38 So can you share a little bit more about
how Replicache thinks about local first?
0:44:43 Yeah.
0:44:44 Yeah.
0:44:44 So there's obviously, there's a little
bit of controversy around, around
0:44:49 naming and like what local first means.
0:44:51 And I think this happens every single time
there's like a new catchphrase in tech.
0:44:55 Or really even in anything, like
even in music or other domains,
0:44:58 like people get worked up about
what qualifies as what term.
0:45:02 PVH.
0:45:03 I don't know what the H stands for.
0:45:04 Harden, Hardenberg?
0:45:05 Yeah, Hardenberg.
0:45:05 Oh, yeah, he lived down the street
from me in San Francisco and we
0:45:09 met up in coffee shop all the time
and and talked about Local First
0:45:12 and CRDTs and things like that.
0:45:14 And he coined Local First.
0:45:15 I think it was him, or maybe someone
on the team, maybe it's wrong to
0:45:18 attribute it to Peter solely, but
anyways they list, like, seven
0:45:22 ideals for Local First software.
0:45:24 I think it's seven.
0:45:24 And Replicache, like, does
not meet all of those ideals.
0:45:28 Right?
0:45:28 Like, in particular, there's like
the long now, I think, which is like,
0:45:32 you know, that you should be able to
keep using your client side software.
0:45:36 If the service it depends on
disappears like that, that like
0:45:39 replicates doesn't really do that
because it's a client server system.
0:45:42 And I think there's some others that
kind of point to like PDP, like in
0:45:45 order to implement one of the seven,
you would kind of have to be PDP.
0:45:49 And like replicates is
a client server system.
0:45:51 It's like designed for, you It's
designed for, like, the classic web
0:45:55 services that people, that are 99.
0:45:56 99 percent of the things
you use every day.
0:45:59 So, when we built Replicache,
we, like, specifically called it
0:46:02 Offline First for the longest time.
0:46:04 And we avoided calling it Local First,
you know, out of deference to that team.
0:46:08 Because they coined the term,
0:46:09 but, like, the thing that happened is,
like, people kept calling us Local First.
0:46:12 Like, like the users kept calling us
local first, you know, and like, at some
0:46:16 point we were just like, forget this,
you know, and also like other companies
0:46:19 started calling themselves local first
that were like the same design as us.
0:46:23 And it just the market seemed to
like consolidate around this term.
0:46:26 And I think it makes sense why it
happened because it describes what people
0:46:31 think of as this technology, right?
0:46:33 Local first, you access the
local storage first, and then
0:46:36 you fall back to the network.
0:46:37 That is what Replicache does.
0:46:39 That is what ElectricSQL does, that is
what all of these systems do, and like,
0:46:42 and so it's like a correct descriptive
name, and I think that's why people don't
0:46:46 understand the distinction, and and so
we just ended up like, giving in, and
0:46:50 like, deciding that we're local first too.
0:46:52 That, that makes a lot of sense.
0:46:54 Local first is like offline first,
but we have an additional capability.
0:46:58 It's not just like an app that only
works offline or can then like also work
0:47:03 with a server, but it's fundamentally
also giving you collaboration and I
0:47:08 think it's more of a spectrum of, yeah,
you've been mentioning the seven ideals.
0:47:12 And if some technologies can give a
foundation that adheres to all of those
0:47:19 seven ideals, great, but fundamentally.
0:47:22 The tools we were building and the
tools we're using help us to get from
0:47:26 A to B faster and it always depends.
0:47:30 So I think Replicache is striking some
very reasonable and attractive trade offs.
0:47:35 And if you don't have that
client server architecture,
0:47:39 if you don't have that server.
0:47:41 Then you are also left alone with
some very hard problems that you don't
0:47:46 really need for many applications.
0:47:48 So I'm very excited about how you
thought about those trade offs.
0:47:53 And I think local first is a big
umbrella and I'm excited that, that
0:47:57 replication and reflect is a part of that.
0:48:00 Oh, thanks, man.
0:48:01 That's nice to hear.
0:48:02 Peter invited me to like
the local first party in St.
0:48:05 Louis, like at strange loop
last year or this year.
0:48:09 And so I was like, Oh I'm in the club.
0:48:12 I got invited to the local first party.
0:48:14 I think this is definitely a goal.
0:48:15 Let's bring as many people in here,
particularly like people, like with your
0:48:20 great technology background, I think
you've been rooting for those ideals, like
0:48:25 way longer than most people have started
to really think so crisply about those,
0:48:31 so before we are wrapping up, do you have
anything else that you want to mention?
0:48:36 I mean, I'm going to plug Replicache and
Reflect, but before I do that I think that
0:48:41 we're just, it's a really exciting time.
0:48:42 Like, I think that we have been working
on these technologies now for so long,
0:48:47 like some of us, you know, and like, there
have been so many things to, to solve.
0:48:52 But it really feels like it's turning
a corner and I think that more and
0:48:55 more people in 2024 are going to
be thinking, you know, I think it's
0:49:00 time to build something local first
and or at least play with this.
0:49:04 And there's just a lot of really
great options out there right now.
0:49:07 And it's and it seems like
it's growing every day.
0:49:10 So yeah, if you're thinking
about building something local
0:49:12 first check out Replicache.
0:49:14 dev.
0:49:15 That's the client side
only project that we have.
0:49:17 And if you just want to get up and
running quick and and not do all the
0:49:20 setup yourself check out Reflect.net.
0:49:22 It's fully managed and hosted service.
0:49:25 That sounds great.
0:49:26 I might just play around with
that over the holidays myself.
0:49:30 So yeah, Aaron, thank you
so much for taking the time.
0:49:33 We have quite a time zone difference.
0:49:35 I'm here like in Berlin where it's
already quite late and you're in beautiful
0:49:39 Hawaii with the very background.
0:49:42 So thank you so much for taking
the time and sharing everything.
0:49:46 All right.
0:49:46 Yeah.
0:49:47 I'm really looking forward to
hearing the rest of these too.
0:49:49 I'm sure you'll get some really
interesting people on here.
0:49:51 Perfect.
0:49:53 Thank you for listening to
the Local First FM podcast.
0:49:56 If you've enjoyed this episode and haven't
done so already, please subscribe and
0:50:00 leave a review wherever you're listening.
0:50:03 Please also consider telling your
friends about it, if you think they
0:50:06 could be interested in Local First.
0:50:08 Thank you again to Expo and Crab
Nebula for supporting this podcast.
0:50:12 See you next time.