1 00:00:00,049 --> 00:00:03,729 the main thing is browsers have storage now, like, they didn't 2 00:00:03,729 --> 00:00:04,779 have storage for the longest time. 3 00:00:04,789 --> 00:00:08,240 I feel like my mission in life is just like I'm shouting from 4 00:00:08,240 --> 00:00:12,180 the mountaintop Hey, did you know browsers have storage now 5 00:00:13,120 --> 00:00:15,360 Welcome to the localfirst.fm podcast. 6 00:00:15,570 --> 00:00:19,380 I'm your host Johannes Schickling, and I'm a web developer, a startup founder, and 7 00:00:19,380 --> 00:00:21,150 love the craft of software engineering. 8 00:00:21,580 --> 00:00:25,860 For the past few years, I've been on a journey to build a modern, high quality 9 00:00:25,860 --> 00:00:27,790 music app using web technologies. 10 00:00:28,030 --> 00:00:32,240 And in doing so, I've been falling down the rabbit hole of local first software. 11 00:00:32,740 --> 00:00:35,780 This podcast is your invitation to join me on that journey. 12 00:00:36,415 --> 00:00:40,515 In this episode, I'm speaking to Aaron Boodman, who's the founder of Rocicorp, 13 00:00:41,015 --> 00:00:45,465 the company behind local first products, such as Replicache and Reflect.net. 14 00:00:46,415 --> 00:00:50,985 This conversation covers a wide range of topics, starting from how his work on 15 00:00:50,985 --> 00:00:53,125 Google Gears has led to Google Chrome. 16 00:00:53,435 --> 00:00:55,295 And many of today's web standards. 17 00:00:55,975 --> 00:00:59,925 Later, we're diving into what Replicache is and how it's implemented. 18 00:01:00,468 --> 00:01:03,968 Also a big thank you to Expo and Crab Nebula for supporting 19 00:01:03,968 --> 00:01:07,708 this podcast and supporting the local first ecosystem as a whole. 20 00:01:08,298 --> 00:01:10,248 And now my interview with Aaron. 21 00:01:12,766 --> 00:01:14,416 Welcome Aaron to the show. 22 00:01:14,726 --> 00:01:16,716 Thank you so much for joining today. 23 00:01:16,896 --> 00:01:18,866 Would you mind briefly introducing yourself? 24 00:01:19,466 --> 00:01:20,086 Yeah, sure. 25 00:01:20,220 --> 00:01:21,020 okay, , My name's Aaron. 26 00:01:21,460 --> 00:01:26,900 I am most recently the founder of Reflect.net which is a hosted service for 27 00:01:26,900 --> 00:01:32,230 multiplayer and And for local first style apps, my company also built Replicache 28 00:01:32,370 --> 00:01:34,750 which is a variation of that product. 29 00:01:35,370 --> 00:01:38,030 And I kind of have a long history in the web. 30 00:01:38,030 --> 00:01:40,090 I've been doing open source on the web for a really long time. 31 00:01:40,150 --> 00:01:44,220 I started in like, I don't know, 2002, 2001. 32 00:01:44,240 --> 00:01:46,100 And yeah that's me. 33 00:01:46,935 --> 00:01:47,455 Awesome. 34 00:01:47,585 --> 00:01:50,905 Thank you so much for making time and coming on the show. 35 00:01:50,955 --> 00:01:54,545 Would you mind sharing a little bit of like your arc of what brought 36 00:01:54,545 --> 00:01:56,675 you to local first software today? 37 00:01:57,095 --> 00:01:57,765 Yeah, sure. 38 00:01:57,815 --> 00:01:59,045 I'll try to give a short history. 39 00:02:00,035 --> 00:02:03,235 You know, I started out my career just doing JavaScript libraries, UI libraries. 40 00:02:03,305 --> 00:02:07,035 Actually, a bunch of my oldest friends and co workers we were a member of this 41 00:02:07,045 --> 00:02:08,935 community online called dhtmlcentral. 42 00:02:09,165 --> 00:02:13,135 com, which was like back in the very dark ages of the web, like before GitHub, 43 00:02:13,805 --> 00:02:17,305 before really open source like hit its stride and we would share JavaScript 44 00:02:17,365 --> 00:02:21,895 on there, and we built UI components and things like that, and we were 45 00:02:21,895 --> 00:02:27,240 just really excited about, you know, pushing this, Tiny, terrible platform 46 00:02:27,570 --> 00:02:29,450 to build, like, real apps with it. 47 00:02:29,550 --> 00:02:32,950 One of my friends built, like, a whole windowing, like, toolkit, like, with 48 00:02:33,240 --> 00:02:37,780 all the window components, like, in JavaScript, like, in 2000, I don't know, 49 00:02:37,780 --> 00:02:39,520 it must have been, like, 2001 in there. 50 00:02:39,980 --> 00:02:44,260 And, you know, over time, you know, the web grew and we found 51 00:02:44,260 --> 00:02:45,270 ourselves at big companies. 52 00:02:45,270 --> 00:02:49,600 I found myself at Google helping them do do their JavaScript products, right? 53 00:02:50,030 --> 00:02:54,540 And, you know, it was always like this huge fight to get 54 00:02:54,560 --> 00:02:55,970 anything in browsers at that time. 55 00:02:56,060 --> 00:02:58,250 Like, like, browsers just would never add any features. 56 00:02:58,250 --> 00:02:59,920 Like, there's no incentive for them to do it. 57 00:03:00,440 --> 00:03:03,670 And so, this opportunity at Google came up to work on this thing called Gears. 58 00:03:04,110 --> 00:03:09,610 Which was this crazy idea to, like, add a plug in to browsers that added APIs. 59 00:03:09,640 --> 00:03:12,420 Like, usually plug ins, they're like a graphical thing, you know. 60 00:03:12,490 --> 00:03:14,330 They like, they add some sort of UI feature. 61 00:03:14,330 --> 00:03:17,080 But this was an idea to add a plug in that had no UI features. 62 00:03:17,230 --> 00:03:18,550 All it did was add web APIs. 63 00:03:18,975 --> 00:03:21,345 So that, like, we could actually build stuff with browsers that 64 00:03:21,345 --> 00:03:22,535 was, like, good, you know? 65 00:03:22,535 --> 00:03:26,085 And and it was just such a cool, like, bold idea. 66 00:03:26,585 --> 00:03:28,805 And so I jumped on that, and the first, one of the very first 67 00:03:28,805 --> 00:03:30,425 things we built was a database. 68 00:03:31,345 --> 00:03:34,575 aNd the reason that we wanted to put a database in browsers was because, at that 69 00:03:34,575 --> 00:03:39,145 time, you know, you could only store five megabytes of data in a browser, you know? 70 00:03:39,425 --> 00:03:44,235 And so, if you think about it, the web is just, like, fundamentally hobbled. 71 00:03:44,830 --> 00:03:46,000 By not having storage. 72 00:03:46,220 --> 00:03:47,860 Like, you think about what makes an app. 73 00:03:48,110 --> 00:03:50,520 You know, we have this constant annoying debate on the web. 74 00:03:50,750 --> 00:03:52,440 SPA, MPA, blah, blah, blah, blah, blah. 75 00:03:52,910 --> 00:03:54,190 Just step back and think to yourself. 76 00:03:54,280 --> 00:03:56,470 Like, what are the ingredients of a native app? 77 00:03:56,750 --> 00:03:57,520 What makes it tick? 78 00:03:57,660 --> 00:03:58,770 What makes it a native app? 79 00:03:59,200 --> 00:04:00,300 And there's not that much to it. 80 00:04:00,300 --> 00:04:04,440 It's processing, memory, network, storage, UI. 81 00:04:04,880 --> 00:04:05,290 You know? 82 00:04:05,400 --> 00:04:06,190 Those are the ingredients. 83 00:04:06,230 --> 00:04:06,610 You know? 84 00:04:07,050 --> 00:04:10,010 The web until recently didn't have storage and that's like 85 00:04:10,010 --> 00:04:10,850 an important ingredient. 86 00:04:10,850 --> 00:04:14,280 If you don't have storage you're doomed to be a dumb app, a dumb client. 87 00:04:15,410 --> 00:04:16,410 completely agree. 88 00:04:16,780 --> 00:04:22,030 So before going a bit more into today's storage mechanisms, what was , back then 89 00:04:22,040 --> 00:04:26,930 for Gears, what was the inspiration, was there any sort of existing database 90 00:04:27,250 --> 00:04:28,980 that you looked at where you said, okay. 91 00:04:29,260 --> 00:04:33,510 It would be great to have something similar to this, but for the web, or 92 00:04:33,510 --> 00:04:35,460 did you mostly design this from scratch? 93 00:04:36,060 --> 00:04:39,110 Well, the API that we the actual database that we used was SQLite, 94 00:04:39,555 --> 00:04:43,585 which at that time felt very mature, even then, at that time. 95 00:04:43,585 --> 00:04:44,375 You know, I think, 96 00:04:45,015 --> 00:04:48,455 I'm pretty sure that SQLite started, I want to say, in 2000. 97 00:04:48,515 --> 00:04:50,575 And this was 2007 that we were doing this in. 98 00:04:51,145 --> 00:04:53,405 It was a really, it's kind of an obvious thing. 99 00:04:53,585 --> 00:04:56,145 Already SQLite was in everything at that point, you know? 100 00:04:56,305 --> 00:04:57,755 And, or it felt like it was in everything. 101 00:04:58,215 --> 00:05:01,265 And it's embedded, fast, robust. 102 00:05:01,625 --> 00:05:04,465 But, you know, it wasn't an appropriate API for the web. 103 00:05:05,065 --> 00:05:07,325 The cool thing about working on Gears was like a lot of the people 104 00:05:07,325 --> 00:05:09,695 that were doing the platform design were like JavaScript developers. 105 00:05:09,735 --> 00:05:11,585 And then we had a bunch of like sort of more gnarly C++ 106 00:05:11,945 --> 00:05:12,945 people working on the guts. 107 00:05:13,685 --> 00:05:18,195 And we, you know, we wanted to do APIs that fit in the web from both like a 108 00:05:18,195 --> 00:05:20,015 security and a usability point of view. 109 00:05:20,455 --> 00:05:25,805 So we wrapped SQLite in you know, a simple, but what we felt was 110 00:05:25,805 --> 00:05:27,625 like fairly webby abstraction. 111 00:05:28,025 --> 00:05:30,195 So what was the path forward from there? 112 00:05:30,235 --> 00:05:34,555 So I can't say that I've built something on top of Google Gears. 113 00:05:34,915 --> 00:05:40,770 But I, I've, I know of quite a few database-like abstractions for the 114 00:05:40,770 --> 00:05:45,470 web for example, thinking of web SQL, which I also think is built on top of 115 00:05:45,470 --> 00:05:51,210 SQLite was that sort of an evolution of what you built back then, or take 116 00:05:51,210 --> 00:05:56,230 me from back then, from the first steps of bringing SQLite to the web to 117 00:05:56,270 --> 00:05:58,340 the various chapters up until today. 118 00:05:58,950 --> 00:06:00,010 Yeah, absolutely. 119 00:06:00,070 --> 00:06:04,370 Gears had a short and glorious life. 120 00:06:04,430 --> 00:06:05,920 I think it did not last long. 121 00:06:06,310 --> 00:06:09,076 We launched it in I believe. 122 00:06:09,196 --> 00:06:10,706 And it was dead by 2010. 123 00:06:11,706 --> 00:06:15,906 And what happened was It was this very, in retrospect, it was this 124 00:06:15,906 --> 00:06:17,666 very high risk strategy for Google. 125 00:06:17,676 --> 00:06:20,356 We were trying to force change on the web. 126 00:06:20,366 --> 00:06:24,296 Like, Google needed the web to be better, like, in order to do its applications. 127 00:06:24,306 --> 00:06:28,576 And and, what happened when we launched Gears was, like, the other 128 00:06:28,576 --> 00:06:29,646 browser vendors, like, hated it. 129 00:06:29,816 --> 00:06:32,986 And, like, like, legitimately, or all, at that time, Google 130 00:06:32,986 --> 00:06:33,926 did not have a browser, right? 131 00:06:33,926 --> 00:06:35,366 So, the browser vendors hated it. 132 00:06:35,866 --> 00:06:38,066 And, you know, they felt threatened by it, you know? 133 00:06:38,096 --> 00:06:42,891 And I think there were also, Fair and good like standardization arguments, 134 00:06:43,071 --> 00:06:47,141 but I think the reality was like they were the people who made the web 135 00:06:47,141 --> 00:06:50,051 platform and this was like someone coming and trying to like force things 136 00:06:50,051 --> 00:06:51,451 on them sort of against their will. 137 00:06:51,871 --> 00:06:53,371 Whether the will was like fair or not. 138 00:06:53,411 --> 00:06:55,631 And and so there was a lot of backlash. 139 00:06:55,631 --> 00:06:59,141 We Had hoped that we would distribute gears with browsers. 140 00:06:59,626 --> 00:07:03,416 Safari, like, they outright said no I think Firefox said no, and 141 00:07:03,416 --> 00:07:07,476 basically, like, around that same time, Google was starting Chrome. 142 00:07:07,526 --> 00:07:10,156 And there was strategic questions of how the two fit together. 143 00:07:10,686 --> 00:07:12,356 And basically how do we advance the web? 144 00:07:12,736 --> 00:07:16,436 And it just became really clear that the way to do that was to have a browser. 145 00:07:16,716 --> 00:07:19,296 Because like, browser vendors were the ones with a seat at the table. 146 00:07:19,796 --> 00:07:23,226 And it just, it was obvious that we would, as a company, we would have 147 00:07:23,226 --> 00:07:24,406 more leverage doing it that way. 148 00:07:24,876 --> 00:07:26,276 At first, we put Gears in Chrome. 149 00:07:26,726 --> 00:07:28,876 So the first thing was Chrome launched and we put Gears in Chrome. 150 00:07:29,366 --> 00:07:31,526 And then, a little while later, we shut down Gears. 151 00:07:32,006 --> 00:07:35,936 But, even with, like, just the few properties using Gears, it was 152 00:07:35,936 --> 00:07:38,056 obvious that the web needed this. 153 00:07:38,076 --> 00:07:45,116 And there's a guy at Google who was HTML5 spec named Hixie, Ian Hickson and he 154 00:07:45,116 --> 00:07:46,246 just worked right down the hall from me. 155 00:07:46,296 --> 00:07:49,096 And he was like, we have to standardize this. 156 00:07:49,116 --> 00:07:50,076 We have to specify it. 157 00:07:50,951 --> 00:07:55,041 His philosophy was like, The web is what browser vendors ship, you know, 158 00:07:55,041 --> 00:07:59,261 that's just the reality, you know, and Chrome has shipped this and then 159 00:07:59,331 --> 00:08:02,481 shortly thereafter like Safari was working on shipping it and he was 160 00:08:02,481 --> 00:08:04,671 like we have to have a spec for this. 161 00:08:04,671 --> 00:08:06,561 Otherwise, no one's, it's not gonna be interoperable. 162 00:08:06,941 --> 00:08:11,351 So he wrote it down and he designed the web SQL API, web SQL database, which 163 00:08:11,351 --> 00:08:13,781 was a JavaScript API around SQLite. 164 00:08:14,091 --> 00:08:15,611 Which was inspired by Gears. 165 00:08:16,001 --> 00:08:17,951 I helped, like, edit the spec. 166 00:08:18,341 --> 00:08:20,461 And That took us to WebSQL database. 167 00:08:20,781 --> 00:08:24,071 The story actually has this long and sad history Beyond that, because, you 168 00:08:24,071 --> 00:08:26,801 know, of course, WebSQL got killed too. 169 00:08:27,506 --> 00:08:34,876 Yeah, well, as, as many products and great ideas within Google, but looking at the 170 00:08:34,936 --> 00:08:41,276 looking at it as a glass half full, I think each of those has brought new ideas 171 00:08:41,306 --> 00:08:43,736 and started new things that I outlived. 172 00:08:44,316 --> 00:08:45,456 The initial products. 173 00:08:45,776 --> 00:08:50,156 So I think now SQLite is far from being done. 174 00:08:50,616 --> 00:08:56,176 So it's really like a technology of the decades and is still getting better. 175 00:08:56,196 --> 00:09:01,006 And I think we should do entire shows also just on SQLite and local first. 176 00:09:01,660 --> 00:09:05,630 Were there any other ideas that are sort of noteworthy that came 177 00:09:05,650 --> 00:09:09,540 out of the gears project that also made it in today's browsers. 178 00:09:10,190 --> 00:09:12,370 Yeah, absolutely, you know, geolocation. 179 00:09:12,650 --> 00:09:13,660 We shipped geolocation. 180 00:09:13,670 --> 00:09:16,720 We were the first way that you could get access to geolocation programmatically 181 00:09:16,720 --> 00:09:21,160 in web browsers and the API and the guy who designed that API was like on my team 182 00:09:21,160 --> 00:09:26,050 and the API that ended up in browsers is almost like word for word the same API 183 00:09:26,470 --> 00:09:33,000 and Workers so the very first version of Gears had three APIs offline boot, like 184 00:09:33,000 --> 00:09:34,660 the inability to boot a web app offline. 185 00:09:35,195 --> 00:09:38,375 So it had a sort of equivalent, something a little bit like AppCache. 186 00:09:38,855 --> 00:09:42,335 And then it had workers, so that you could do sync processing in the 187 00:09:42,335 --> 00:09:43,865 background without blocking the UI thread. 188 00:09:44,345 --> 00:09:46,995 And it had a database based on SQLite. 189 00:09:47,695 --> 00:09:49,685 And all three of those are the first release, and all three of 190 00:09:49,685 --> 00:09:51,135 those APIs became web standards. 191 00:09:51,305 --> 00:09:54,655 You know, not the exact same API, but they directly influenced, I mean, 192 00:09:54,655 --> 00:09:57,495 basically, Hixie was like, we better write this down, because people 193 00:09:57,495 --> 00:09:58,345 are going to start implementing it. 194 00:09:58,345 --> 00:09:58,625 So. 195 00:09:59,180 --> 00:10:04,440 In that way, Gears definitely had the impact that Google and that, you know, 196 00:10:04,450 --> 00:10:08,330 I hoped it would have, that it did move the web forward a lot, really fast. 197 00:10:08,760 --> 00:10:09,540 That's incredible. 198 00:10:09,540 --> 00:10:12,920 You had like all of those foundational ideas already back then. 199 00:10:12,990 --> 00:10:18,740 And I feel like now, what is it like definitely more than 10 years later, 200 00:10:19,050 --> 00:10:24,740 the web still feels like to just about discover those bigger primitives that 201 00:10:24,740 --> 00:10:29,170 we can actually use storage to build real web apps, that we can use workers 202 00:10:29,180 --> 00:10:33,340 to make things more performant and kind of spare the main thread a bit. 203 00:10:33,630 --> 00:10:35,560 To keep the app more responsive. 204 00:10:35,870 --> 00:10:41,500 So all of those capabilities that you all kept thinking of way, way back, 205 00:10:41,770 --> 00:10:45,370 I feel like step by step that the web is finally waking up to those. 206 00:10:45,860 --> 00:10:50,340 So I think storage is really like the main thing on your mind there. 207 00:10:50,860 --> 00:10:53,690 Yeah, I mean, there's so much to talk about, I'll try not to ramble, , you said 208 00:10:53,710 --> 00:10:55,680 10 years, it's been more than 15 years. 209 00:10:55,870 --> 00:10:59,020 Like, it's 2023, we launched Gears in 2007. 210 00:10:59,630 --> 00:11:01,900 So it is crazy how long these things take. 211 00:11:02,288 --> 00:11:04,898 it hasn't been a, it has not been a straight line it wasn't 212 00:11:04,898 --> 00:11:06,228 Google that , killed WebSQL. 213 00:11:06,228 --> 00:11:08,738 It was actually Firefox kind of, and Microsoft. 214 00:11:09,008 --> 00:11:11,268 Like, basically, the browser vendors wouldn't implement it. 215 00:11:11,288 --> 00:11:13,678 They were afraid that it would not be able to be standardized. 216 00:11:14,328 --> 00:11:15,918 Which I think is not really true. 217 00:11:15,928 --> 00:11:18,248 We could have done that but it would, there was a fear and it, 218 00:11:18,258 --> 00:11:19,448 I think it was a legitimate fear. 219 00:11:19,728 --> 00:11:21,188 But I think ultimately we could have done that. 220 00:11:21,678 --> 00:11:25,728 And so we sort of randomly got IndexedDB out of the deal instead. 221 00:11:26,178 --> 00:11:30,208 And it, you know, the vendors were looking for an alternative 222 00:11:30,298 --> 00:11:32,018 that was standardizable, right? 223 00:11:32,068 --> 00:11:35,228 And so this thing sort of emerged. 224 00:11:35,258 --> 00:11:38,558 And like one of the, one of the like participants in the W3C list or the 225 00:11:38,558 --> 00:11:40,918 H, the WhatWG list proposed this. 226 00:11:40,938 --> 00:11:43,028 And it was like, it fit. 227 00:11:43,743 --> 00:11:48,483 The sort of strategic goals of the other vendors, but, and so it got specified and 228 00:11:48,493 --> 00:11:52,623 implemented really quick, but just one of those things where it wasn't coming from 229 00:11:52,623 --> 00:11:56,313 a place of people actually using it, you know, and wanting to build things with it. 230 00:11:56,333 --> 00:11:59,873 And so it just has this just like always happens when you do that, like, 231 00:11:59,883 --> 00:12:03,253 it just has this really weird API shape and so, you know, IndexedDB like 232 00:12:03,253 --> 00:12:06,963 famously never got used for anything and then we didn't have Web SQL either. 233 00:12:07,783 --> 00:12:11,673 And then meanwhile, the browser vendors kept, well, people kept 234 00:12:11,673 --> 00:12:13,923 trying to put SQLite in the browser because SQLite is so awesome. 235 00:12:13,923 --> 00:12:17,893 It's so useful, , and so people kept looking for a way to do this both inside 236 00:12:17,953 --> 00:12:19,763 browser vendor companies and outside. 237 00:12:19,833 --> 00:12:22,543 Google had this team, a sub team of Chrome, working on this thing 238 00:12:22,543 --> 00:12:25,533 called NaCl, and that was like, you know, an assembly language that 239 00:12:25,533 --> 00:12:26,743 could run in the web, sandboxed. 240 00:12:27,303 --> 00:12:29,203 And the predecessor to WASM. 241 00:12:29,463 --> 00:12:32,703 One of the main, use cases, was we could run SQLite in the browser. 242 00:12:33,333 --> 00:12:35,093 And we wouldn't have to standardize it, right? 243 00:12:35,093 --> 00:12:36,833 Because the standard would be lower level, right? 244 00:12:37,323 --> 00:12:40,093 But nobody wanted to, the other vendors didn't want to implement 245 00:12:41,392 --> 00:12:42,802 Yeah, so then that didn't work. 246 00:12:42,862 --> 00:12:45,392 And then they tried PNaCl, which was like supposed to be like a more portable 247 00:12:45,402 --> 00:12:48,122 version of it, but then that, they, the vendors wouldn't implement that. 248 00:12:48,122 --> 00:12:50,752 And for a little while people were like, Oh, we can just 249 00:12:50,752 --> 00:12:51,942 compile everything to JavaScript. 250 00:12:51,982 --> 00:12:53,802 That was like, you know, asm. 251 00:12:53,802 --> 00:12:56,762 js, and people tried compiling SQLite to that. 252 00:12:57,282 --> 00:12:58,392 And that, I mean, it kind of worked. 253 00:12:58,992 --> 00:13:02,312 But then eventually Mozilla proposed Wasm, which was like basically a 254 00:13:02,372 --> 00:13:04,462 really closely related idea to NaCl. 255 00:13:04,942 --> 00:13:07,432 And and then everyone got behind that. 256 00:13:07,482 --> 00:13:09,922 And so then people started putting SQLite in that. 257 00:13:09,952 --> 00:13:15,352 And then, you know, humorously around the same time Safari killed cross 258 00:13:15,352 --> 00:13:17,072 site caching for privacy reasons. 259 00:13:17,612 --> 00:13:20,892 So, using SQLite this way is like a little bit hobbled because it means like 260 00:13:20,892 --> 00:13:22,602 every app has to cache it themselves. 261 00:13:23,192 --> 00:13:26,452 But yeah, it's been a, it's been a long story and you know, 262 00:13:26,502 --> 00:13:27,592 there's way more to it than that. 263 00:13:27,592 --> 00:13:29,232 Why do the platforms grow so slowly? 264 00:13:29,252 --> 00:13:31,862 There's like technical reasons and there's sort of political reasons and 265 00:13:31,862 --> 00:13:34,272 strategic reasons from the companies, but like, I think also it's like, 266 00:13:34,872 --> 00:13:36,702 There's this economic thing that happens. 267 00:13:36,752 --> 00:13:39,322 I think like humans are sort of lazy and risk averse. 268 00:13:39,652 --> 00:13:44,022 You know, not in a bad way, just like, no one uses storage on the web, right? 269 00:13:44,052 --> 00:13:48,162 And so if you're building a new app on the web, and say you want to build, I 270 00:13:48,162 --> 00:13:52,022 don't know, a new competitor to Google Slides or something like that, right? 271 00:13:52,562 --> 00:13:53,792 Are you going to use storage? 272 00:13:53,822 --> 00:13:57,222 It's like a, it's like a high risk thing, because no one else does 273 00:13:57,222 --> 00:14:00,112 it, and that alone makes it high risk, because it's like unknown. 274 00:14:01,079 --> 00:14:04,799 So zooming out a little bit the web is not the only platform. 275 00:14:04,839 --> 00:14:08,209 We have native mobile platforms, iOS, Android. 276 00:14:08,209 --> 00:14:10,699 We have also native desktop operating platforms. 277 00:14:10,749 --> 00:14:15,859 So most of those have storage mechanisms since otherwise, if I. 278 00:14:16,339 --> 00:14:21,169 Reopen an app on my iPhone and it has lost all my data that wouldn't be great. 279 00:14:21,599 --> 00:14:25,009 Whereas that is the more common experience on the web. 280 00:14:25,499 --> 00:14:30,269 So why do web apps feel so different compared to native apps? 281 00:14:30,879 --> 00:14:31,089 Yeah. 282 00:14:31,149 --> 00:14:33,159 I mean, this is a question as old as time. 283 00:14:33,249 --> 00:14:36,459 I mean, people have been asking this since I started programming on the web. 284 00:14:36,509 --> 00:14:39,239 And I think it's this like really deep and interesting. 285 00:14:39,609 --> 00:14:40,089 Question. 286 00:14:40,169 --> 00:14:42,689 So why is it hard to put storage in the web platform? 287 00:14:42,689 --> 00:14:43,619 Why has it taken so long? 288 00:14:43,754 --> 00:14:46,289 A, a big part of it is just the web is zero permission. 289 00:14:46,289 --> 00:14:47,549 It's permissionless, right? 290 00:14:47,729 --> 00:14:49,109 That's like the web's superpower. 291 00:14:49,409 --> 00:14:52,049 That's what make, that's why we still have the web and it, you know, 292 00:14:52,169 --> 00:14:55,289 iOS is like a, on a, on technical merits, a superior platform. 293 00:14:55,619 --> 00:14:59,112 You can't deny it, but the web has this one thing that no other 294 00:14:59,112 --> 00:15:01,987 platform has, and that has made it so powerful that it's permissionless. 295 00:15:02,682 --> 00:15:06,392 You can send a link to your friend and they see the picture of your cat, that is 296 00:15:06,392 --> 00:15:09,962 something that doesn't happen on any other platform and it's super, super important. 297 00:15:10,012 --> 00:15:14,342 It's why I started programming for the web and it's why probably many of us did. 298 00:15:14,342 --> 00:15:16,972 It's like when you're a kid and you got notepad. 299 00:15:16,972 --> 00:15:19,922 exe, you know, and you know, an FTP client, you can like write 300 00:15:19,922 --> 00:15:21,332 some, put it on your webpage and share it with your friends. 301 00:15:21,342 --> 00:15:22,322 You don't need anyone's permission. 302 00:15:22,322 --> 00:15:23,132 You don't need an account. 303 00:15:23,142 --> 00:15:26,042 You don't need a credit card, but this superpower is also the source 304 00:15:26,042 --> 00:15:27,585 of all the web's difficulties. 305 00:15:28,015 --> 00:15:31,415 Like the fact that the web is permissionless means that it can't have 306 00:15:31,485 --> 00:15:33,125 any permission that could be dangerous. 307 00:15:33,505 --> 00:15:36,065 That could be a security issue that could be privacy issue that 308 00:15:36,065 --> 00:15:37,795 could hurt you or your computer. 309 00:15:38,165 --> 00:15:41,975 And so it's different than a platform that's more managed and so just 310 00:15:41,975 --> 00:15:44,675 from a platform design perspective, figuring out how to put storage in 311 00:15:44,675 --> 00:15:45,835 browsers has been difficult, right? 312 00:15:45,835 --> 00:15:48,135 Because you, you know, a malicious app, you don't want 313 00:15:48,135 --> 00:15:49,355 it filling up your disk, right? 314 00:15:49,685 --> 00:15:51,155 Making the other apps not work right. 315 00:15:51,505 --> 00:15:53,385 Or like consuming all of the storage quota, right? 316 00:15:53,925 --> 00:15:57,135 And from a privacy perspective, you don't want people using the storage to like, 317 00:15:57,185 --> 00:15:58,805 you know, track you or whatever, right? 318 00:15:59,245 --> 00:16:02,775 Because of the way that the web is permissionless, it has grown 319 00:16:02,815 --> 00:16:05,575 an ecosystem of apps that are like different than native apps, right? 320 00:16:05,885 --> 00:16:08,795 Only recently people have started using the web for like sort of 321 00:16:08,795 --> 00:16:11,155 personal productivity apps like note takers and stuff like that. 322 00:16:11,735 --> 00:16:15,535 You know, like you think about like traditional platforms, they tend to 323 00:16:15,535 --> 00:16:19,005 focus on apps that are single user, you know, like the bread and butter 324 00:16:19,005 --> 00:16:20,630 of iOS is like single user apps. 325 00:16:20,990 --> 00:16:21,270 Right? 326 00:16:21,300 --> 00:16:22,850 All the apps that it's shipped with, right? 327 00:16:22,850 --> 00:16:24,840 Those are all things you use alone, right? 328 00:16:25,220 --> 00:16:27,830 And storage is easy for those kind of apps, right? 329 00:16:28,270 --> 00:16:30,690 Desktop platforms have had storage for a long time, right? 330 00:16:31,190 --> 00:16:36,220 But because the web is permissionless, it has tended to be strong in 331 00:16:36,220 --> 00:16:38,020 collaborative applications, right? 332 00:16:38,220 --> 00:16:41,340 And also apps that are huge, where there's like way more data 333 00:16:41,430 --> 00:16:42,560 that you could possibly fit. 334 00:16:42,905 --> 00:16:43,965 On your device, right? 335 00:16:44,015 --> 00:16:46,275 Google search, Google Maps, Gmail, right? 336 00:16:46,325 --> 00:16:48,475 All of these products are like things where you couldn't actually 337 00:16:48,475 --> 00:16:50,025 run them on your device, right? 338 00:16:50,055 --> 00:16:51,625 Like they need a lot more computers to run. 339 00:16:52,175 --> 00:16:55,665 Even assuming that you have storage, like once we added gears, right? 340 00:16:56,125 --> 00:16:59,985 Once you have that, even using it is hard because you have to figure out how to use 341 00:16:59,985 --> 00:17:01,735 it in a multi user, like, environment. 342 00:17:01,795 --> 00:17:03,665 You have to figure out sync and conflict resolution. 343 00:17:04,075 --> 00:17:06,575 And then because the data can be bigger than can fit on your device, 344 00:17:06,575 --> 00:17:09,345 you have to figure out not just sync, but partial sync, which is 345 00:17:09,345 --> 00:17:10,695 like this whole other harder part. 346 00:17:11,085 --> 00:17:13,215 And then you have to figure out authorization and sync. 347 00:17:13,275 --> 00:17:15,855 Like with iCloud, your own data back and forth, right? 348 00:17:15,855 --> 00:17:16,685 You have permissions to it. 349 00:17:17,065 --> 00:17:19,685 But in, in like a classic web app, you only have permissions 350 00:17:19,685 --> 00:17:20,705 to a tiny subset of the data. 351 00:17:20,705 --> 00:17:23,355 So you have to do partial authorized sync, right? 352 00:17:23,745 --> 00:17:27,055 And then on top of that, the storage isn't reliable because the browsers 353 00:17:27,065 --> 00:17:30,425 have to implement it in such a way that that apps can't abuse it. 354 00:17:30,825 --> 00:17:33,815 That means as an application developer that it can disappear at any moment, which 355 00:17:33,815 --> 00:17:35,475 is also different than a native platform. 356 00:17:35,675 --> 00:17:39,375 So I not only have to build a much more complicated syncing mechanism, I also 357 00:17:39,375 --> 00:17:42,905 have to make that syncing mechanism robust to the fact that the storage 358 00:17:42,905 --> 00:17:44,015 underneath it can just disappear. 359 00:17:44,305 --> 00:17:47,045 I think there are like legitimate technical challenges and then on top 360 00:17:47,045 --> 00:17:51,535 of that, I think there are sort of just natural human challenges to to like doing 361 00:17:51,535 --> 00:17:52,785 something that no one has done before. 362 00:17:53,202 --> 00:17:53,562 Right. 363 00:17:53,582 --> 00:17:57,675 So before diving into those let's maybe dig a little bit more 364 00:17:57,685 --> 00:17:59,405 into the technical challenges. 365 00:17:59,425 --> 00:18:03,505 So you've posed them as challenges and given that over the last. 366 00:18:03,745 --> 00:18:09,365 10, 20 years, the web has changed significantly in, in terms of the things 367 00:18:09,365 --> 00:18:11,135 that have been standardized et cetera. 368 00:18:11,505 --> 00:18:15,875 So I think a few of those challenges are always inherently 369 00:18:15,875 --> 00:18:19,215 challenging due to the nature of the web, which is permissionless. 370 00:18:20,040 --> 00:18:24,150 But given some of the technological improvements, I'm wondering which 371 00:18:24,150 --> 00:18:28,271 of those challenges are much more manageable now and why, and what are 372 00:18:28,291 --> 00:18:32,701 those improvements that have been landing and how do they make things easier now? 373 00:18:33,261 --> 00:18:36,941 the main thing is browsers have storage now, like, they didn't 374 00:18:36,941 --> 00:18:37,991 have storage for the longest time. 375 00:18:38,001 --> 00:18:41,451 I feel like my mission in life is just like I'm shouting from 376 00:18:41,451 --> 00:18:45,391 the mountaintop Hey, did you know browsers have storage now? 377 00:18:45,721 --> 00:18:47,411 I feel like largely developers don't know this. 378 00:18:47,421 --> 00:18:50,717 In fact, I was on a tweet thread just yesterday where someone well 379 00:18:50,717 --> 00:18:54,237 known in the web, in the software development community, like, very 380 00:18:54,237 --> 00:18:57,387 respected, was like, wait, browsers have more than 5 megabytes of storage? 381 00:18:57,737 --> 00:18:58,717 Like, yes, they do. 382 00:18:59,017 --> 00:19:01,447 On most devices browsers have like gigabyte of storage. 383 00:19:02,027 --> 00:19:04,697 You know, , the actual quota is complicated. 384 00:19:04,697 --> 00:19:07,327 It's dependent on how much free space you have on your device and what browser 385 00:19:07,327 --> 00:19:11,377 you're using and like how many other apps are using storage and blah, blah, blah. 386 00:19:11,767 --> 00:19:14,637 But I mean, you can assume as a web developer that you have access 387 00:19:14,637 --> 00:19:18,867 to like hundreds of megabytes of storage locally on the device, which 388 00:19:18,907 --> 00:19:20,487 in almost all cases now is SSD. 389 00:19:20,527 --> 00:19:21,757 It's like almost memory. 390 00:19:22,157 --> 00:19:25,147 You know, we have a local cache, persistent cache that can store 391 00:19:25,147 --> 00:19:26,117 hundreds of megabytes of data. 392 00:19:26,542 --> 00:19:30,432 And if you're not using this as a web developer, you are leaving a massive 393 00:19:30,432 --> 00:19:31,612 amount of performance on the table. 394 00:19:32,032 --> 00:19:35,362 We have a whole community of like web developers who are constantly talking 395 00:19:35,362 --> 00:19:38,252 about how much performance matters to them and how performance is the most 396 00:19:38,252 --> 00:19:42,412 important thing and they have this massive cache sitting on the device 397 00:19:42,422 --> 00:19:45,922 that they're not using, so we have the primitive, you can sort data in browsers. 398 00:19:46,612 --> 00:19:51,232 But we now need to develop the patterns and libraries and techniques and 399 00:19:51,232 --> 00:19:54,262 mindshare for people to know that they can use this and how to use it. 400 00:19:54,827 --> 00:19:55,867 I fully agree. 401 00:19:55,877 --> 00:19:58,167 This is exactly where I wanted to go to. 402 00:19:58,177 --> 00:20:02,157 We have the primitives now, we had some cruder primitives in the past. 403 00:20:02,207 --> 00:20:05,187 But I think those primitives are getting a lot better now. 404 00:20:05,187 --> 00:20:08,137 They work more consistently between browsers. 405 00:20:08,138 --> 00:20:09,357 They're getting more performant. 406 00:20:09,677 --> 00:20:13,477 Some restrictions are no longer there, but as you say, now it's a 407 00:20:13,477 --> 00:20:17,797 matter of building the layers on top, building the libraries, building 408 00:20:17,807 --> 00:20:19,417 good tooling, building things like. 409 00:20:19,847 --> 00:20:22,157 Browser dev tools that work with us. 410 00:20:22,547 --> 00:20:24,807 And so I think that's one major part. 411 00:20:24,907 --> 00:20:29,557 And then the other major part is to getting people, like you say, like you 412 00:20:29,557 --> 00:20:32,287 go into mountaintop and shout it down. 413 00:20:32,297 --> 00:20:33,907 This is what needs to happen as well. 414 00:20:33,907 --> 00:20:37,427 Besides building great tools, since otherwise people kind of stick 415 00:20:37,427 --> 00:20:39,487 with the old way of doing things. 416 00:20:39,877 --> 00:20:46,067 But maybe in the context of the storage of the web maybe you want to draw a 417 00:20:46,067 --> 00:20:47,952 quick bridge to what you're working on. 418 00:20:48,837 --> 00:20:49,347 Yeah, sure. 419 00:20:49,348 --> 00:20:51,298 So I'm the founder of this company, Roci Corp. 420 00:20:51,398 --> 00:20:55,138 It's basically collection of my friends from Google that worked on Chrome 421 00:20:55,468 --> 00:21:00,788 mostly with me and and we loved the work that we did there and like the 422 00:21:00,788 --> 00:21:03,588 quality of work that we built and we wanted to keep doing it on our own. 423 00:21:03,588 --> 00:21:05,338 So we formed this small company. 424 00:21:05,338 --> 00:21:09,878 We're fully distributed and we have two products around multiplayer and local 425 00:21:09,878 --> 00:21:14,538 first Replicache is client side only so it's a library that you include in your 426 00:21:14,548 --> 00:21:18,428 app and you can think of it sort of as like a wrapper around local storage. 427 00:21:18,768 --> 00:21:22,628 We actually use IndexedDB, not SQLite and I think I think IndexedDB is slept on. 428 00:21:22,708 --> 00:21:25,808 I think like it has a lot of advantages and we're probably going 429 00:21:25,818 --> 00:21:27,158 to continue to use it for a while. 430 00:21:27,158 --> 00:21:28,268 But it's doesn't matter. 431 00:21:28,268 --> 00:21:31,458 There's multiple storage mechanisms now in browsers and they have trade offs. 432 00:21:31,568 --> 00:21:34,928 So anyways, we have Replicache, which is client side only, and it's a 433 00:21:34,928 --> 00:21:38,308 wrapper around local storage that has a synchronization protocol built into it. 434 00:21:38,558 --> 00:21:41,698 A robust, high quality synchronization protocol that can do partial sync, 435 00:21:41,988 --> 00:21:44,598 that can do authorized sync that can store hundreds of megabytes of 436 00:21:44,598 --> 00:21:45,988 data locally is very performant. 437 00:21:46,408 --> 00:21:49,788 That can do 60 frames per second, like responsiveness client side. 438 00:21:50,218 --> 00:21:53,928 And, you know, people build apps out of this, you know, like, one of our 439 00:21:53,958 --> 00:21:58,838 biggest prop proponents, like Dax, is online today, talking about this 440 00:21:58,858 --> 00:22:03,228 crazy app that he has built that's competing with Vercel using Replicache. 441 00:22:03,558 --> 00:22:06,568 And but you know, implementing the backend for a synchronization 442 00:22:06,568 --> 00:22:07,598 system is also challenging. 443 00:22:07,918 --> 00:22:11,258 And so people asked us for a hosted solution for this. 444 00:22:11,258 --> 00:22:15,238 And so we also have Reflect, which is the complete package that 445 00:22:15,238 --> 00:22:17,038 includes the service that syncs. 446 00:22:17,638 --> 00:22:20,548 And it's, basically the same thing as Replicache, but with 447 00:22:20,878 --> 00:22:21,758 but with the backend as well. 448 00:22:22,348 --> 00:22:22,668 Got it. 449 00:22:22,938 --> 00:22:26,538 So can you explain a little bit more the cases when I would be 450 00:22:26,538 --> 00:22:31,038 using Replicache as opposed to when I'd be reaching for reflect? 451 00:22:31,648 --> 00:22:35,778 Yeah so Replicache is like, you want control of everything. 452 00:22:35,818 --> 00:22:37,068 Like, as much as you can have. 453 00:22:37,118 --> 00:22:40,028 Basically Replicache can connect to not any backend 454 00:22:40,028 --> 00:22:41,308 stack, but many backend stacks. 455 00:22:41,358 --> 00:22:44,598 You can implement a Replicache connector for basically any relational database, 456 00:22:44,608 --> 00:22:48,028 for most of the document databases, you know, you can even implement a backend 457 00:22:48,028 --> 00:22:49,748 for, like, your custom distributed system. 458 00:22:50,188 --> 00:22:53,348 So it's more effort, but it's more flexible and adaptable, right? 459 00:22:53,448 --> 00:22:54,878 Reflect is very opinionated. 460 00:22:55,228 --> 00:22:58,758 It's a complete hosted service that's tightly integrated and 461 00:22:58,758 --> 00:22:59,928 it's designed to be very fast. 462 00:23:00,418 --> 00:23:03,198 It leaves some, it's for, like, when you're starting something 463 00:23:03,198 --> 00:23:05,978 new, and you don't have a lot of time, and you just want it to work. 464 00:23:06,478 --> 00:23:10,828 So I'd be curious to learn a little bit more about the challenges that you were 465 00:23:10,828 --> 00:23:16,078 facing building Replicache and building Reflect as it relates to the challenges 466 00:23:16,098 --> 00:23:20,758 you've mentioned before in regards to storage and other challenges we might not 467 00:23:20,768 --> 00:23:24,878 have talked about yet when it comes to building such a technology for the web. 468 00:23:24,893 --> 00:23:26,863 Yeah. 469 00:23:26,973 --> 00:23:29,753 there's a lot of little things that you discover when you set 470 00:23:29,753 --> 00:23:31,173 out to do something new like this. 471 00:23:31,673 --> 00:23:34,173 And a lot of times, you know, in software engineering You know, a lot 472 00:23:34,173 --> 00:23:37,263 of the work comes from like unexpected places, you know, it's not the 473 00:23:37,263 --> 00:23:39,883 algorithm, it's not the core algorithms or the data structures or whatever. 474 00:23:39,883 --> 00:23:41,393 It's like dealing with the practicalities. 475 00:23:42,043 --> 00:23:45,863 Like one thing that is really a quirk of the web that is another one 476 00:23:45,863 --> 00:23:48,803 of the web superpowers, but really makes this challenging is tabs. 477 00:23:49,353 --> 00:23:53,983 Like, the web has tabs and tabs from like a platform software developed, 478 00:23:54,033 --> 00:23:57,093 like a software engineering perspective are weird because they are different 479 00:23:57,093 --> 00:23:58,593 execution environments, right? 480 00:23:58,593 --> 00:23:59,243 It's as if. 481 00:24:00,058 --> 00:24:03,218 You have an application, but it has like, it has many different, 482 00:24:03,328 --> 00:24:04,838 like, places where code can run. 483 00:24:05,128 --> 00:24:07,118 Many, like, it's as if you had a bunch of different processes. 484 00:24:07,668 --> 00:24:10,588 They're not, tabs aren't really different processes, but like, from a software 485 00:24:10,588 --> 00:24:12,318 engineering perspective, they're kind of like processes because they're 486 00:24:12,318 --> 00:24:15,258 different execution environments that can have different code in them, right? 487 00:24:15,608 --> 00:24:18,188 Like, you could have different versions of your app with different 488 00:24:18,188 --> 00:24:19,618 code bases running in each tab. 489 00:24:19,628 --> 00:24:23,108 Like, if the server updated and and one tab updated, but 490 00:24:23,128 --> 00:24:24,228 the other didn't, you know? 491 00:24:24,638 --> 00:24:25,938 But they share storage. 492 00:24:26,538 --> 00:24:28,278 So that is a weird thing. 493 00:24:28,288 --> 00:24:31,178 Usually when platforms have a situation like that, where you have processes 494 00:24:31,178 --> 00:24:34,768 or threads, they also have locks so that you can like protect the 495 00:24:34,768 --> 00:24:36,108 storage and coordinate access to it. 496 00:24:36,438 --> 00:24:40,498 But the web has kind of has like a fledgling web locks API, but 497 00:24:40,498 --> 00:24:42,678 it is very unused and tested. 498 00:24:42,678 --> 00:24:43,798 And there's a lot of edge cases in it. 499 00:24:43,798 --> 00:24:44,888 And we don't really trust it. 500 00:24:45,488 --> 00:24:48,658 Like our company doesn't use it and trust it because we investigated 501 00:24:48,658 --> 00:24:52,158 a bunch of these edge cases and they're sort of like underspecified. 502 00:24:52,508 --> 00:24:55,428 I don't believe that they're consistently implemented across browsers. 503 00:24:56,208 --> 00:24:59,508 And we've even had people like on browser teams like recommend that we don't use it. 504 00:24:59,898 --> 00:25:02,848 You have to figure out a way to deal with the fact that You have 505 00:25:02,848 --> 00:25:04,368 this persistent storage, right? 506 00:25:04,518 --> 00:25:07,878 And one tab can update and the other tab cannot be updated. 507 00:25:07,958 --> 00:25:08,668 And then what happens? 508 00:25:09,028 --> 00:25:09,318 Right? 509 00:25:09,798 --> 00:25:12,363 And There's always a problem with these kind of systems of 510 00:25:12,363 --> 00:25:13,743 like schema migrations, right? 511 00:25:13,743 --> 00:25:17,833 You have to figure out schema migrations, but it's harder on the web because you 512 00:25:17,833 --> 00:25:20,663 have schema migration on the server You have schema migration on the client 513 00:25:20,913 --> 00:25:24,723 But then you have the problem that one tab can update and like want to migrate 514 00:25:24,723 --> 00:25:28,083 the schema forward to like the version of the Storage that it wants, but the 515 00:25:28,083 --> 00:25:31,493 other tab is like still back on the old version, you know, like what does it do? 516 00:25:31,493 --> 00:25:33,413 So these are just like fun practical problems. 517 00:25:34,173 --> 00:25:38,253 So I would actually love to learn a little bit more about either of those. 518 00:25:38,303 --> 00:25:44,023 And so are those challenges that you've been facing and that you can fully take 519 00:25:44,033 --> 00:25:49,593 care of on behalf of an application developer, are you able to like go some 520 00:25:49,593 --> 00:25:52,033 way, but still leave some of the hard. 521 00:25:52,643 --> 00:25:57,803 trade offs to an application developer and there's some path, some like bad 522 00:25:57,813 --> 00:26:01,563 or even worse trade offs someone needs to make as an application developer, 523 00:26:01,673 --> 00:26:03,843 they ultimately have to choose. 524 00:26:04,333 --> 00:26:06,513 So how we're able to work around those? 525 00:26:06,910 --> 00:26:11,330 My view is that in order for storage to be widely used on the web, it 526 00:26:11,330 --> 00:26:16,100 has to be as easy as, easier than like building a normal web app. 527 00:26:16,100 --> 00:26:18,400 It has to be easier than building today's web app, right? 528 00:26:18,780 --> 00:26:22,710 And I think that we can get there and the and the people who need to fill that 529 00:26:22,710 --> 00:26:26,340 gap, who need to make it easier than today's web apps are library developers. 530 00:26:26,760 --> 00:26:29,520 Like, it's not gonna be browser vendors because they move way too slow. 531 00:26:29,820 --> 00:26:32,930 Like, it's gonna be library developers because we have this , awesome 532 00:26:32,930 --> 00:26:36,905 ecosystem of people furiously tr trying different things to figure this out. 533 00:26:37,275 --> 00:26:40,655 So we have completely solved the cross tab thing, and I think our solution 534 00:26:40,655 --> 00:26:42,335 to it is, I'm really proud of it. 535 00:26:42,335 --> 00:26:43,685 Like we put a lot of work into it. 536 00:26:44,245 --> 00:26:47,535 It's for this like tiny moment when your app is updating we put this massive amount 537 00:26:47,535 --> 00:26:52,265 of effort into this, like 10 seconds at worst when your app is updating and 538 00:26:52,265 --> 00:26:56,715 like two tabs have different versions but we made it really like elegant. 539 00:26:56,735 --> 00:26:58,015 And like, you don't have to think about it. 540 00:26:58,025 --> 00:27:03,395 Like basically what happens is as a developer constructor for 541 00:27:03,395 --> 00:27:06,345 Replicache, you specify the version of the database that you want. 542 00:27:06,345 --> 00:27:07,755 And that's an identifier that you choose. 543 00:27:08,310 --> 00:27:11,270 So you say like, I want version seven and you can create as many 544 00:27:11,270 --> 00:27:14,820 different schema versions as you want in Replicache, and they'll each be 545 00:27:14,820 --> 00:27:16,270 isolated from each other, fully isolated. 546 00:27:16,770 --> 00:27:21,200 And when we talk to the server, we send in the request the version of the 547 00:27:21,200 --> 00:27:22,970 schema that we're asking on behalf of. 548 00:27:23,370 --> 00:27:26,150 So the server has to respond with that version or say, I can't serve 549 00:27:26,160 --> 00:27:27,210 that version, you need to reload. 550 00:27:27,780 --> 00:27:32,210 But then internally to deal with that moment when tabs are on different schema 551 00:27:32,210 --> 00:27:37,170 versions, we actually fork the database and we have both running at the same time. 552 00:27:37,660 --> 00:27:41,140 So typically in Replicache, the storage is shared, right? 553 00:27:41,140 --> 00:27:44,020 So you make changes in one tab and you see them instantly in the other 554 00:27:44,020 --> 00:27:45,400 tab whether you're online or not. 555 00:27:45,860 --> 00:27:48,280 But for this moment, when a schema update is happening, they fork. 556 00:27:48,630 --> 00:27:51,610 So the tabs can continue independently and they can continue working. 557 00:27:51,660 --> 00:27:54,540 You know, a concern is like, if you're typing in a, in an input, you don't 558 00:27:54,540 --> 00:27:56,870 want to just reload the app at that moment to get the new code, right? 559 00:27:56,900 --> 00:27:59,170 The user could lose their work or just be frustrated, right? 560 00:27:59,650 --> 00:28:02,860 So you want, you need to allow the app to continue running for a 561 00:28:02,860 --> 00:28:05,980 little while until it thinks that it's the right time to update. 562 00:28:06,305 --> 00:28:07,595 That sounds incredible. 563 00:28:07,605 --> 00:28:09,755 And that sounds like an absolute nightmare. 564 00:28:09,785 --> 00:28:15,115 If like I, as an application developer, it's hard enough to ship the app 565 00:28:15,115 --> 00:28:19,505 version that I have, and then to even like really think about that there 566 00:28:19,555 --> 00:28:23,705 is this point of time where a user has the old version up and running. 567 00:28:23,735 --> 00:28:27,755 And to then just like throw multiple tabs into the mix here as well. 568 00:28:28,065 --> 00:28:32,310 So, I think whatever pain you can take away from my application 569 00:28:32,310 --> 00:28:33,850 developer here is amazing. 570 00:28:34,310 --> 00:28:39,560 So yeah you've been mentioning the various app schema versions and that does at 571 00:28:39,560 --> 00:28:42,360 least locally speaking forks the database. 572 00:28:42,820 --> 00:28:48,535 And I suppose then there's some mechanism how the forks are eventually being. 573 00:28:48,965 --> 00:28:54,805 joined or merged again, or how if the different tabs are still being used, 574 00:28:55,025 --> 00:28:57,225 how did those forks come together again? 575 00:28:57,915 --> 00:29:01,005 Well, what happens is they're both still talking to the same server, right? 576 00:29:01,365 --> 00:29:04,305 So the they're local storage forks but they're still talking 577 00:29:04,305 --> 00:29:05,875 to a shared truth on the server. 578 00:29:06,290 --> 00:29:10,620 And the server and when tab a makes a request to the server, it says like, 579 00:29:10,620 --> 00:29:15,080 hi, I, I want to talk and I'm talking schema version seven and when tab 580 00:29:15,090 --> 00:29:18,210 B sends a request to the server, he says, I'm talking version eight and 581 00:29:18,210 --> 00:29:22,540 the server can choose to speak both versions if it wants, or it can choose 582 00:29:22,540 --> 00:29:23,950 to tell seven, I can't talk to you. 583 00:29:23,950 --> 00:29:26,690 I only know version eight but that doesn't mean that tab seven 584 00:29:26,700 --> 00:29:27,790 has to reload at that moment. 585 00:29:27,860 --> 00:29:30,860 Tab seven can continue working without a server connection, right? 586 00:29:30,910 --> 00:29:31,700 Because it's local first. 587 00:29:32,560 --> 00:29:34,550 And then it can decide to reload when it's ready. 588 00:29:34,823 --> 00:29:39,173 Let's say we have tab a and tab B and they're happily working 589 00:29:39,173 --> 00:29:40,553 in the same version right now. 590 00:29:41,083 --> 00:29:45,853 Is there some communication mechanism between those two tabs that that 591 00:29:45,853 --> 00:29:47,773 doesn't rely on the server alone? 592 00:29:48,363 --> 00:29:51,119 Yeah, under normal circumstances, the storage is shared. 593 00:29:51,569 --> 00:29:53,279 So you make changes in tab. 594 00:29:53,299 --> 00:29:55,639 If you're off totally offline with Replicache or reflect, 595 00:29:56,109 --> 00:29:58,469 and you make changes in tab a, you will see them in tab B. 596 00:29:58,889 --> 00:29:59,979 They share storage, right? 597 00:30:00,379 --> 00:30:04,339 It's just at this moment when an upgrade happens, they fork momentarily. 598 00:30:04,929 --> 00:30:09,339 Just to maintain like integrity of the system, like, so that you don't have. 599 00:30:09,699 --> 00:30:11,279 The schema changing underneath one of the tabs. 600 00:30:11,979 --> 00:30:17,429 And, you know, that is like a little bit of a rough edge in the like, abstraction. 601 00:30:17,749 --> 00:30:18,129 You know? 602 00:30:18,489 --> 00:30:22,039 But, under normal circumstances, you're never going to notice this as a developer. 603 00:30:22,099 --> 00:30:24,289 And it's like, the cleanest solution that we could come up with. 604 00:30:24,819 --> 00:30:25,369 I agree. 605 00:30:25,409 --> 00:30:29,529 I think it's not like that you're rolling out a new release constantly. 606 00:30:29,569 --> 00:30:32,789 I think the, still the majority of the time where the app is being 607 00:30:32,789 --> 00:30:34,599 used, that you're not upgrading. 608 00:30:35,029 --> 00:30:39,839 And so for that little period of time to have a simpler solution to 609 00:30:39,839 --> 00:30:43,719 this very gnarly problem, sounds like a very good move to me. 610 00:30:44,039 --> 00:30:47,939 So in the case where it's not currently upgrading, you mentioned 611 00:30:47,949 --> 00:30:50,129 that those two different tabs. 612 00:30:50,414 --> 00:30:51,514 Share storage. 613 00:30:51,624 --> 00:30:56,844 Does that mean they share the same IndexedDB database or is there even more 614 00:30:56,844 --> 00:31:01,734 sharing, such as like sharing an array buffer between those tabs, or what is 615 00:31:01,734 --> 00:31:03,734 the communication mechanism between those? 616 00:31:03,754 --> 00:31:08,124 Are you listening to changes in IndexedDB, is there sort of like 617 00:31:08,124 --> 00:31:10,124 a broadcast channel between those? 618 00:31:10,434 --> 00:31:12,894 How does the tap interplay work? 619 00:31:13,427 --> 00:31:14,817 I'm so glad you're asking these questions. 620 00:31:14,887 --> 00:31:17,277 Like, I don't know if our listeners will care about these details. 621 00:31:17,277 --> 00:31:17,837 I hope they do. 622 00:31:18,067 --> 00:31:19,757 Because this is like, the fun part, you know? 623 00:31:20,127 --> 00:31:23,307 But Yeah, this gets to another one of the practical challenges that I am proud 624 00:31:23,307 --> 00:31:26,807 of in our implementation that I, that we put a lot of work into, which is 625 00:31:26,807 --> 00:31:29,177 like we, it was very important to us. 626 00:31:29,177 --> 00:31:30,397 And I know important to you too. 627 00:31:30,397 --> 00:31:33,537 And a lot of other people in this space that you have 60 frames per second 628 00:31:33,547 --> 00:31:38,217 interactivity, like at, you know, that we want people to be able to use Replicache 629 00:31:38,237 --> 00:31:42,397 as if it's memory, you know, as if it's your, as if it's your state model, like 630 00:31:42,397 --> 00:31:44,977 one of the benefits that should come out of adopting these tools is that you 631 00:31:44,977 --> 00:31:48,767 don't need complex state management libraries, you know, you have this like 632 00:31:48,767 --> 00:31:52,817 database locally You should be able to use that as your as your state but when 633 00:31:52,817 --> 00:31:55,857 you look at that from like again from like an engineering perspective, it's 634 00:31:55,857 --> 00:32:01,497 actually not so easy because You know storage local storage on SSD is fast. 635 00:32:01,697 --> 00:32:05,957 Sure You know SQLite is fast IDB is not fast, but you can like wrap it and 636 00:32:06,007 --> 00:32:09,327 do things to it to make it fast but it's nowhere near as fast as memory. 637 00:32:09,427 --> 00:32:10,577 It's not 60 frames per second. 638 00:32:10,637 --> 00:32:12,427 It's an order of magnitude slower, right? 639 00:32:12,597 --> 00:32:15,287 So, so how do you bridge that gap, right? 640 00:32:15,447 --> 00:32:19,887 And if you want to have cross tab consistency, if part of the product design 641 00:32:19,897 --> 00:32:24,617 is that you make changes in tab A and they reflect in tab B, then you cannot 642 00:32:24,617 --> 00:32:27,937 use storage alone as your communication mechanism because it's too slow, right? 643 00:32:28,302 --> 00:32:31,742 So you have to have memory inside the tabs at some level, you have to have 644 00:32:31,742 --> 00:32:34,902 memory like that has the state in the tabs because that's the only way it can 645 00:32:34,902 --> 00:32:38,772 be fast enough and then you again have a synchronization problem like a distributed 646 00:32:38,772 --> 00:32:40,712 system problem between the tabs, right? 647 00:32:40,732 --> 00:32:41,742 They're changing independently. 648 00:32:41,742 --> 00:32:42,662 So how do you resolve that? 649 00:32:43,152 --> 00:32:45,932 There's like different, I think there's different legitimate ways to address 650 00:32:45,942 --> 00:32:49,485 this, but the way that we do it, which is that we basically, we use the storage 651 00:32:49,515 --> 00:32:53,815 as like, We, we run in memory, Replicache runs in memory, like in the JavaScript 652 00:32:53,825 --> 00:32:55,455 thread, in the main thread, right? 653 00:32:55,825 --> 00:32:57,195 So it's right there next to your app. 654 00:32:57,235 --> 00:33:01,865 It's crazy fast and it lazily loads and stores to IDB. 655 00:33:02,365 --> 00:33:04,685 And we have a, basically a synchronization protocol between the 656 00:33:04,855 --> 00:33:09,515 tabs which you can kind of think of it roughly as like two Replicache 657 00:33:09,535 --> 00:33:13,465 browsers, like sync via the server and two Replicache tabs sync by IDB. 658 00:33:13,735 --> 00:33:14,845 That's like the basic structure. 659 00:33:15,260 --> 00:33:18,870 And yes, we need to have a way to know when something has changed cross tabs. 660 00:33:18,910 --> 00:33:20,760 And for that, we use broadcast channel. 661 00:33:21,290 --> 00:33:23,940 But like, you know, it's the same if you're familiar at all with 662 00:33:23,940 --> 00:33:26,650 Replicache, the server doesn't send data proactively to the client. 663 00:33:27,060 --> 00:33:30,350 The server only sends a poke that like a tap on the shoulder 664 00:33:30,360 --> 00:33:33,020 that something has changed and the client requests the changes. 665 00:33:33,600 --> 00:33:35,490 And we kind of do the same thing cross tab. 666 00:33:35,630 --> 00:33:39,180 Like we, we use broadcast channel to tell the other tab, Hey, IDB has changed. 667 00:33:39,610 --> 00:33:40,040 And then. 668 00:33:40,435 --> 00:33:43,875 That tab is like running as fast as it can in memory and it has like 669 00:33:43,875 --> 00:33:47,365 a background process to refresh itself from storage periodically. 670 00:33:47,785 --> 00:33:51,855 I'm very curious to learn more about that background process as well. 671 00:33:52,205 --> 00:33:57,075 Are you leveraging workers at all in your implementation here, or is this 672 00:33:57,075 --> 00:33:59,015 mostly running in the main thread? 673 00:33:59,085 --> 00:34:02,365 And this is where given that you have multiple tabs, multiple main 674 00:34:02,365 --> 00:34:05,785 threads is most of Replicache running in the main threads. 675 00:34:06,780 --> 00:34:09,200 We don't use workers as part of the implementation of 676 00:34:09,200 --> 00:34:10,890 Replicache Currently at all. 677 00:34:11,430 --> 00:34:15,110 you know, we, We want people to be able to use Replicache as if it's memory, 678 00:34:15,110 --> 00:34:19,690 it should be as fast as memory and, the only way to do that is to be memory, you 679 00:34:19,690 --> 00:34:22,910 know, you could have something running in another thread, in another worker, 680 00:34:22,910 --> 00:34:26,540 but then you're still gonna have to have state and memory, right, so, What we 681 00:34:26,850 --> 00:34:33,180 landed on was, we have Replicache as a in, like an in memory main thread thing. 682 00:34:33,620 --> 00:34:37,930 It has a background process that syncs with IDB, but that is just like a periodic 683 00:34:37,930 --> 00:34:39,170 task that's running on the main thread. 684 00:34:39,740 --> 00:34:42,800 You can easily run Replicache in a worker, and many people do. 685 00:34:42,830 --> 00:34:45,250 People, like, people do this to do full text search. 686 00:34:45,610 --> 00:34:50,130 They run Replicache in another tab, they do, you know, indexing in that, or they 687 00:34:50,130 --> 00:34:52,700 run it in a worker, they do indexing in that worker, and then they, like, 688 00:34:52,730 --> 00:34:54,300 access that index from the main thread. 689 00:34:54,800 --> 00:34:58,990 And because of the cross tab communication that we have, it works fine across workers 690 00:34:58,990 --> 00:35:03,820 too, workers in the main thread, you know, but where to put workers in your stack is 691 00:35:03,820 --> 00:35:08,330 like a, is a, is an application developer question not a Replicache question 692 00:35:09,065 --> 00:35:11,825 I think it's very possible that we would implement workers. 693 00:35:11,925 --> 00:35:15,605 We would add workers to various parts of the implementation of Replicache, 694 00:35:15,605 --> 00:35:18,235 like as an implementation detail, you know, like there's some background 695 00:35:18,235 --> 00:35:21,455 tasks that we need to do, like cleaning up things, you know, that are heavy. 696 00:35:21,495 --> 00:35:24,945 And it would be useful to have those on a background thread to make sure 697 00:35:24,945 --> 00:35:26,125 they don't interfere with the UI. 698 00:35:27,125 --> 00:35:31,705 The one thing that like people frequently ask, and it has come up over, 699 00:35:31,735 --> 00:35:35,225 over the development of Replicache, whether to use service workers. 700 00:35:35,225 --> 00:35:39,110 and because it, it seems so tempting. 701 00:35:39,110 --> 00:35:41,840 It's like this shared place that you can run code, you know, across tabs. 702 00:35:42,330 --> 00:35:45,230 But man, service workers are like another part of the web platform. 703 00:35:45,230 --> 00:35:46,560 That's just so hard to use. 704 00:35:46,630 --> 00:35:49,920 You know, it's just so gnarly, and I feel like almost nobody 705 00:35:49,920 --> 00:35:51,230 knows how to use them, you know? 706 00:35:51,670 --> 00:35:54,050 And like, there's so few examples of them being used successfully. 707 00:35:54,090 --> 00:35:57,110 And if we use service workers in Replicache, it would have impact 708 00:35:57,110 --> 00:35:58,150 on how people build their apps. 709 00:35:58,770 --> 00:35:59,940 So we just haven't gone there. 710 00:36:00,090 --> 00:36:05,040 Once you're just a little library that you use in your JavaScript app, then 711 00:36:05,070 --> 00:36:09,760 I think that keeps things way simpler since I think very few JavaScript 712 00:36:09,780 --> 00:36:14,000 developers are even aware of the concept of a thread in the context 713 00:36:14,030 --> 00:36:15,850 of building like their React app. 714 00:36:16,210 --> 00:36:20,640 And so a worker is a thread, but once you have a library or technology, 715 00:36:20,915 --> 00:36:25,685 that spans, the main thread that spans workers or service workers, then you 716 00:36:25,685 --> 00:36:27,285 need to conceptually deal with that. 717 00:36:27,385 --> 00:36:31,165 But it also becomes a tooling and a bundling problem. 718 00:36:31,535 --> 00:36:35,625 So this is where I think the best technology that we have for those sorts 719 00:36:35,625 --> 00:36:37,855 of patterns right now would be Vite 720 00:36:38,035 --> 00:36:39,195 and my opinion 721 00:36:39,625 --> 00:36:44,675 so have you had success or not so much success with certain technologies? 722 00:36:45,585 --> 00:36:47,915 We love Vite it's like my default. 723 00:36:48,445 --> 00:36:52,335 It's kind of a funny story, like, when I started RociCorp which was, like I 724 00:36:52,335 --> 00:36:56,895 said now, almost four years ago I wasn't up to date with like the web, like, 725 00:36:56,895 --> 00:36:59,035 and like the popular open source tools. 726 00:36:59,665 --> 00:37:02,455 And my friend was like, you gotta check out Next. 727 00:37:02,455 --> 00:37:05,035 js, it's like, so awesome, like, you guys should figure 728 00:37:05,035 --> 00:37:05,775 out how to integrate with Next. 729 00:37:05,775 --> 00:37:08,725 js, and like, I started, like, working with it, and I was like, oh, this is 730 00:37:08,735 --> 00:37:11,715 like a really cool DX, but like, I'm trying to, like, what is it, like, 731 00:37:11,725 --> 00:37:14,365 what's the core value here, I couldn't put my finger on it, like, it's like, 732 00:37:14,635 --> 00:37:18,035 it's hosting, like, there's the the thing where you have deploys that are 733 00:37:18,035 --> 00:37:20,925 like, like, preview deploys, that's really cool, but like, is that, I'm 734 00:37:20,925 --> 00:37:24,225 trying to think, like, why is this so exciting, and I finally realized, it's 735 00:37:24,225 --> 00:37:26,365 like, the easiest way to set up React. 736 00:37:26,810 --> 00:37:29,540 That's really like the back then, like that's the core of it, you know, that's 737 00:37:29,540 --> 00:37:34,150 how like it's like setting up a react project is just so hard, like, and then 738 00:37:34,180 --> 00:37:38,350 I, you know, I think V has taken the has taken the crown on that front now, 739 00:37:39,125 --> 00:37:43,685 Yeah, I think, so my take is that if you're using Next and typically you 740 00:37:43,735 --> 00:37:48,285 then deploy it on Vercel, I think that's great for like anything that's like 741 00:37:48,285 --> 00:37:53,255 a more on the, if there's a spectrum from website to web app, then I think 742 00:37:53,255 --> 00:37:57,595 this is rather where you start on the website spectrum and make it more, 743 00:37:57,875 --> 00:37:59,905 add more and more app like features. 744 00:38:00,425 --> 00:38:04,165 But I think it becomes increasingly hard if you want to build a 745 00:38:04,165 --> 00:38:06,015 local first app with Next. 746 00:38:06,015 --> 00:38:10,035 js as you want to introduce those capabilities, as you want to introduce 747 00:38:10,035 --> 00:38:14,565 really deep storage mechanisms or once you want to work with workers. 748 00:38:14,895 --> 00:38:17,075 I'm sure it's on their roadmap somewhere. 749 00:38:17,105 --> 00:38:21,965 But I think they, they've just started their journey on one side of the spectrum, 750 00:38:21,965 --> 00:38:24,045 which is, I think, rather to the websites. 751 00:38:24,275 --> 00:38:26,575 And that's great and that works really well. 752 00:38:26,585 --> 00:38:30,935 Server side rendering, React server components is great for this use case. 753 00:38:31,355 --> 00:38:37,095 But I think once you want to build web apps that really feel more, almost like a 754 00:38:37,165 --> 00:38:41,595 native app, I think this is where you need to reach for a different tooling stack. 755 00:38:41,605 --> 00:38:46,035 And I'm currently very happy with Vite as it has support for workers 756 00:38:46,055 --> 00:38:49,305 as a first class citizen, was a bit rough over the last few years. 757 00:38:49,440 --> 00:38:54,780 But it has gotten a lot better with every release and I'm very happy using it. 758 00:38:55,250 --> 00:38:59,630 And I've even seen a few libraries also shipping workers out of the 759 00:38:59,630 --> 00:39:01,970 box that work quite well with Vite 760 00:39:02,280 --> 00:39:05,260 so an example here would be the SQLite WASM built. 761 00:39:05,915 --> 00:39:10,745 That also ships with some workers out of the box, which works pretty well, 762 00:39:11,628 --> 00:39:14,318 yeah we use it often and like it as well. 763 00:39:14,318 --> 00:39:17,218 I don't have as much experience with workers in particular just 764 00:39:17,218 --> 00:39:20,338 because we haven't taken it on as like an implementation detail yet. 765 00:39:20,703 --> 00:39:24,153 But yeah, just overall we have a lot of success with using it for our samples. 766 00:39:24,153 --> 00:39:26,303 And like, you know, when you're building this kind of stuff, you end 767 00:39:26,303 --> 00:39:27,973 up making apps all the time, right? 768 00:39:28,577 --> 00:39:32,327 So speaking of maybe this is a good segue to. 769 00:39:32,742 --> 00:39:38,612 How I would use Replicache or reflect in, in my, let's say in my React app. 770 00:39:39,042 --> 00:39:42,112 So I think you've been mentioning MobX. 771 00:39:42,882 --> 00:39:48,172 Is that a typical technology that you use Replicache with, or does Replicache 772 00:39:48,182 --> 00:39:50,522 completely replace something like MobX? 773 00:39:51,232 --> 00:39:56,682 MobX, Redux, Zustand, all those all those sort of state technologies. 774 00:39:56,772 --> 00:40:01,582 Are they complimentary or are they rather being replaced by Replicache? 775 00:40:02,552 --> 00:40:06,012 I think long, like long term they're being replaced but the reality is 776 00:40:06,012 --> 00:40:07,762 that Replicache isn't there yet. 777 00:40:07,782 --> 00:40:11,272 Like these are, you know, very well developed, like sophisticated tools, 778 00:40:11,322 --> 00:40:15,482 you know, like that people have, Developed, like to do legitimately 779 00:40:15,482 --> 00:40:19,257 hard things, you know, like, you have a fairly large data set in memory and 780 00:40:19,257 --> 00:40:21,567 you're trying to update like little bits of it reactively, you know, that's 781 00:40:21,572 --> 00:40:22,797 like a legitimately hard problem. 782 00:40:23,217 --> 00:40:28,242 And so Replicache has an API like A subscription, API that's memory fast. 783 00:40:28,632 --> 00:40:32,982 And I think it actually competes well with like SQ lite based systems. 784 00:40:32,982 --> 00:40:34,122 In many cases it's faster. 785 00:40:34,482 --> 00:40:34,842 But. 786 00:40:35,317 --> 00:40:38,457 I mean, if you're building something like Dax is building, you know, that 787 00:40:38,467 --> 00:40:43,097 has like a lot of data in it like 30, 000, 50, 000 records, you know, and, 788 00:40:43,197 --> 00:40:46,117 you know, you're trying to do 60 frames per second updates in there, and you 789 00:40:46,117 --> 00:40:49,827 have a lot of, like, computation, like, derived computation chains in memory, 790 00:40:50,157 --> 00:40:54,767 like, we don't have the, we don't have the APIs in Replicache yet that, that can 791 00:40:54,767 --> 00:40:59,907 compete with, like, MobX or, like, Signia from TLDraw, like, things like that. 792 00:41:00,217 --> 00:41:03,877 And the cool thing is like, the design of Replicache is complementary 793 00:41:03,877 --> 00:41:04,867 to putting those things on top. 794 00:41:04,877 --> 00:41:07,387 Like at the bottom of the Replicache abstraction stack, you have a 795 00:41:07,387 --> 00:41:08,517 key value store that's reactive. 796 00:41:09,007 --> 00:41:12,727 You know, so you can like plug those reactive changes, like, into your into 797 00:41:12,847 --> 00:41:15,407 Zustand or whatever, and it'll work great. 798 00:41:15,797 --> 00:41:18,357 It's interesting, like, different people in the space started at different angles. 799 00:41:18,357 --> 00:41:19,987 Like, I think that's something you've been passionate about, 800 00:41:19,987 --> 00:41:20,937 like, from the very beginning. 801 00:41:21,017 --> 00:41:23,287 There's so many exciting things happening in local first. 802 00:41:23,287 --> 00:41:25,087 Like, other people have started focusing there. 803 00:41:25,087 --> 00:41:28,797 We started, like, a lot more on making the synchronization correct and robust. 804 00:41:29,327 --> 00:41:31,507 And making partial sync work, authorized sync work. 805 00:41:31,817 --> 00:41:33,847 You know, making the mass storage, like, really fast. 806 00:41:34,287 --> 00:41:37,806 And we still have to like finish up the libraries legitimately, like the 807 00:41:37,807 --> 00:41:39,477 API layer to make it really nice. 808 00:41:39,557 --> 00:41:42,117 I think that it's going to be competitive with like using those types of 809 00:41:42,117 --> 00:41:43,627 tools, like, you know, next quarter. 810 00:41:43,927 --> 00:41:44,247 Yeah. 811 00:41:44,257 --> 00:41:48,877 I mean, Replicache has been, I think, one of the first solutions really been 812 00:41:49,197 --> 00:41:53,007 on the local first market in that way. 813 00:41:53,427 --> 00:41:57,647 And so, and I think you, you have been quite ahead there in terms of 814 00:41:57,677 --> 00:42:00,817 the work on syncing and just having a. 815 00:42:01,112 --> 00:42:06,682 A fully fledged thing out there that developers can use to build on top of and 816 00:42:06,682 --> 00:42:11,012 that shows I think most most of the local first apps that have been built over the 817 00:42:11,012 --> 00:42:16,302 past one or two years, I think, use your technology and I think that's already. 818 00:42:16,592 --> 00:42:19,862 driving some of the change that I want to see for our apps. 819 00:42:20,342 --> 00:42:24,982 So are there some apps that that you're particularly excited about, 820 00:42:25,322 --> 00:42:29,262 where you say, okay, this is exactly what I wanted to help create 821 00:42:29,272 --> 00:42:30,862 more of or help create more of? 822 00:42:31,872 --> 00:42:34,702 Well, I mean, right now the one that, that I'm like most 823 00:42:34,702 --> 00:42:36,482 excited about probably is sst. 824 00:42:36,482 --> 00:42:38,712 dev, Dax's thing that I've mentioned a few times. 825 00:42:39,282 --> 00:42:43,252 Like just because, I don't know it's an example of like a 826 00:42:43,402 --> 00:42:46,352 data intensive application that is like public that you can try. 827 00:42:46,832 --> 00:42:49,522 A lot of our, a lot of our customers are like, you know, they're private 828 00:42:49,532 --> 00:42:52,862 things that, you know, not easy for people to access outside. 829 00:42:52,862 --> 00:42:55,212 And yeah, we have a lot of. 830 00:42:56,017 --> 00:42:59,237 Customers using Replicache for things that are like in the building industry 831 00:42:59,917 --> 00:43:03,937 or like service industry where like, like we have a customer that is building 832 00:43:03,937 --> 00:43:08,797 like a tool that people who build houses like would use and, you know, 833 00:43:08,797 --> 00:43:11,797 they go out in the field and there's intermittent connectivity and, you 834 00:43:11,797 --> 00:43:15,497 know, actually like building a house is like a super data intensive thing. 835 00:43:15,497 --> 00:43:17,677 You know, there's like thousands of elements on the 836 00:43:17,677 --> 00:43:19,147 checklist to a house, you know? 837 00:43:19,607 --> 00:43:21,847 And like lots of people that have to come through and look at it and then 838 00:43:21,847 --> 00:43:24,957 there's back office things that happen and like, so it's like a perfect use 839 00:43:24,957 --> 00:43:28,327 case, but it's not something that you can like use, you know, that you could 840 00:43:28,327 --> 00:43:31,147 go try and use right now because, you know, it's a private system. 841 00:43:31,147 --> 00:43:32,567 So yeah, I think like sst. 842 00:43:32,567 --> 00:43:35,877 dev is like the best example right now that I'm excited about. 843 00:43:36,467 --> 00:43:41,897 I'm equally excited about the things that I can use myself, as well as the anecdotes 844 00:43:41,927 --> 00:43:46,487 I'm hearing about other technologies being created for other people. 845 00:43:46,537 --> 00:43:52,367 So I think this is what I'm particularly excited about Local First, that it 846 00:43:52,667 --> 00:43:58,027 makes it easier to build technologies for use cases that were just not that 847 00:43:58,077 --> 00:44:02,467 Viable before to, to build technologies with the tools that we had before. 848 00:44:02,777 --> 00:44:07,227 So what you've been sharing about the construction use case here, or 849 00:44:07,247 --> 00:44:10,577 you've been also privately sharing a few other use cases with me, 850 00:44:10,827 --> 00:44:12,647 those sounds, sound incredible. 851 00:44:12,667 --> 00:44:16,417 And this is exactly why I'm excited that local first opens 852 00:44:16,467 --> 00:44:18,287 a whole new area of the web. 853 00:44:18,797 --> 00:44:21,837 So if I'm looking on Replicache. 854 00:44:21,857 --> 00:44:25,367 dev or Reflect.net on Replicache. 855 00:44:25,387 --> 00:44:28,947 dev, for example, it says the way to local first. 856 00:44:29,237 --> 00:44:32,847 So I'm curious what local first means for you. 857 00:44:32,887 --> 00:44:36,407 I think there's a whole bunch of terms flying around, whether 858 00:44:36,407 --> 00:44:38,477 it's offline first, local first. 859 00:44:38,727 --> 00:44:43,247 So can you share a little bit more about how Replicache thinks about local first? 860 00:44:43,857 --> 00:44:44,117 Yeah. 861 00:44:44,257 --> 00:44:44,597 Yeah. 862 00:44:44,657 --> 00:44:49,147 So there's obviously, there's a little bit of controversy around, around 863 00:44:49,147 --> 00:44:51,157 naming and like what local first means. 864 00:44:51,407 --> 00:44:54,737 And I think this happens every single time there's like a new catchphrase in tech. 865 00:44:55,277 --> 00:44:58,467 Or really even in anything, like even in music or other domains, 866 00:44:58,467 --> 00:45:02,177 like people get worked up about what qualifies as what term. 867 00:45:02,177 --> 00:45:02,987 PVH. 868 00:45:03,007 --> 00:45:04,197 I don't know what the H stands for. 869 00:45:04,337 --> 00:45:05,087 Harden, Hardenberg? 870 00:45:05,137 --> 00:45:05,717 Yeah, Hardenberg. 871 00:45:05,737 --> 00:45:09,277 Oh, yeah, he lived down the street from me in San Francisco and we 872 00:45:09,277 --> 00:45:12,327 met up in coffee shop all the time and and talked about Local First 873 00:45:12,327 --> 00:45:13,457 and CRDTs and things like that. 874 00:45:14,027 --> 00:45:15,937 And he coined Local First. 875 00:45:15,937 --> 00:45:18,847 I think it was him, or maybe someone on the team, maybe it's wrong to 876 00:45:18,847 --> 00:45:22,017 attribute it to Peter solely, but anyways they list, like, seven 877 00:45:22,017 --> 00:45:23,857 ideals for Local First software. 878 00:45:24,027 --> 00:45:24,657 I think it's seven. 879 00:45:24,757 --> 00:45:28,027 And Replicache, like, does not meet all of those ideals. 880 00:45:28,322 --> 00:45:28,612 Right? 881 00:45:28,632 --> 00:45:32,182 Like, in particular, there's like the long now, I think, which is like, 882 00:45:32,552 --> 00:45:36,582 you know, that you should be able to keep using your client side software. 883 00:45:36,582 --> 00:45:39,992 If the service it depends on disappears like that, that like 884 00:45:39,992 --> 00:45:42,252 replicates doesn't really do that because it's a client server system. 885 00:45:42,852 --> 00:45:45,732 And I think there's some others that kind of point to like PDP, like in 886 00:45:45,742 --> 00:45:48,722 order to implement one of the seven, you would kind of have to be PDP. 887 00:45:49,222 --> 00:45:51,202 And like replicates is a client server system. 888 00:45:51,242 --> 00:45:55,252 It's like designed for, you It's designed for, like, the classic web 889 00:45:55,252 --> 00:45:56,712 services that people, that are 99. 890 00:45:56,712 --> 00:45:59,822 99 percent of the things you use every day. 891 00:45:59,822 --> 00:46:02,912 So, when we built Replicache, we, like, specifically called it 892 00:46:02,942 --> 00:46:04,622 Offline First for the longest time. 893 00:46:04,722 --> 00:46:08,382 And we avoided calling it Local First, you know, out of deference to that team. 894 00:46:08,402 --> 00:46:09,442 Because they coined the term, 895 00:46:09,492 --> 00:46:12,502 but, like, the thing that happened is, like, people kept calling us Local First. 896 00:46:12,982 --> 00:46:16,582 Like, like the users kept calling us local first, you know, and like, at some 897 00:46:16,592 --> 00:46:19,492 point we were just like, forget this, you know, and also like other companies 898 00:46:19,762 --> 00:46:22,932 started calling themselves local first that were like the same design as us. 899 00:46:23,442 --> 00:46:26,192 And it just the market seemed to like consolidate around this term. 900 00:46:26,602 --> 00:46:31,432 And I think it makes sense why it happened because it describes what people 901 00:46:31,452 --> 00:46:33,222 think of as this technology, right? 902 00:46:33,232 --> 00:46:36,672 Local first, you access the local storage first, and then 903 00:46:36,672 --> 00:46:37,542 you fall back to the network. 904 00:46:37,542 --> 00:46:38,692 That is what Replicache does. 905 00:46:39,072 --> 00:46:42,792 That is what ElectricSQL does, that is what all of these systems do, and like, 906 00:46:42,812 --> 00:46:46,022 and so it's like a correct descriptive name, and I think that's why people don't 907 00:46:46,022 --> 00:46:50,532 understand the distinction, and and so we just ended up like, giving in, and 908 00:46:50,532 --> 00:46:52,532 like, deciding that we're local first too. 909 00:46:52,872 --> 00:46:54,192 That, that makes a lot of sense. 910 00:46:54,302 --> 00:46:58,262 Local first is like offline first, but we have an additional capability. 911 00:46:58,262 --> 00:47:03,442 It's not just like an app that only works offline or can then like also work 912 00:47:03,442 --> 00:47:08,162 with a server, but it's fundamentally also giving you collaboration and I 913 00:47:08,172 --> 00:47:12,842 think it's more of a spectrum of, yeah, you've been mentioning the seven ideals. 914 00:47:12,932 --> 00:47:19,082 And if some technologies can give a foundation that adheres to all of those 915 00:47:19,092 --> 00:47:22,082 seven ideals, great, but fundamentally. 916 00:47:22,272 --> 00:47:26,852 The tools we were building and the tools we're using help us to get from 917 00:47:26,862 --> 00:47:29,972 A to B faster and it always depends. 918 00:47:30,022 --> 00:47:35,042 So I think Replicache is striking some very reasonable and attractive trade offs. 919 00:47:35,482 --> 00:47:39,312 And if you don't have that client server architecture, 920 00:47:39,312 --> 00:47:40,812 if you don't have that server. 921 00:47:41,212 --> 00:47:46,452 Then you are also left alone with some very hard problems that you don't 922 00:47:46,462 --> 00:47:48,362 really need for many applications. 923 00:47:48,672 --> 00:47:52,602 So I'm very excited about how you thought about those trade offs. 924 00:47:53,052 --> 00:47:57,742 And I think local first is a big umbrella and I'm excited that, that 925 00:47:57,742 --> 00:48:00,282 replication and reflect is a part of that. 926 00:48:00,892 --> 00:48:01,632 Oh, thanks, man. 927 00:48:01,992 --> 00:48:02,822 That's nice to hear. 928 00:48:02,947 --> 00:48:05,747 Peter invited me to like the local first party in St. 929 00:48:05,747 --> 00:48:09,507 Louis, like at strange loop last year or this year. 930 00:48:09,607 --> 00:48:12,017 And so I was like, Oh I'm in the club. 931 00:48:12,197 --> 00:48:13,617 I got invited to the local first party. 932 00:48:14,217 --> 00:48:15,887 I think this is definitely a goal. 933 00:48:15,907 --> 00:48:20,547 Let's bring as many people in here, particularly like people, like with your 934 00:48:20,617 --> 00:48:25,427 great technology background, I think you've been rooting for those ideals, like 935 00:48:25,567 --> 00:48:30,797 way longer than most people have started to really think so crisply about those, 936 00:48:31,237 --> 00:48:36,137 so before we are wrapping up, do you have anything else that you want to mention? 937 00:48:36,647 --> 00:48:41,207 I mean, I'm going to plug Replicache and Reflect, but before I do that I think that 938 00:48:41,207 --> 00:48:42,937 we're just, it's a really exciting time. 939 00:48:42,937 --> 00:48:47,217 Like, I think that we have been working on these technologies now for so long, 940 00:48:47,257 --> 00:48:51,847 like some of us, you know, and like, there have been so many things to, to solve. 941 00:48:52,182 --> 00:48:55,872 But it really feels like it's turning a corner and I think that more and 942 00:48:55,872 --> 00:49:00,582 more people in 2024 are going to be thinking, you know, I think it's 943 00:49:00,582 --> 00:49:03,912 time to build something local first and or at least play with this. 944 00:49:04,462 --> 00:49:07,032 And there's just a lot of really great options out there right now. 945 00:49:07,532 --> 00:49:09,782 And it's and it seems like it's growing every day. 946 00:49:10,132 --> 00:49:12,832 So yeah, if you're thinking about building something local 947 00:49:12,832 --> 00:49:14,342 first check out Replicache. 948 00:49:14,362 --> 00:49:14,472 dev. 949 00:49:15,107 --> 00:49:16,927 That's the client side only project that we have. 950 00:49:17,247 --> 00:49:20,687 And if you just want to get up and running quick and and not do all the 951 00:49:20,687 --> 00:49:22,427 setup yourself check out Reflect.net. 952 00:49:22,507 --> 00:49:24,907 It's fully managed and hosted service. 953 00:49:25,497 --> 00:49:26,347 That sounds great. 954 00:49:26,397 --> 00:49:29,477 I might just play around with that over the holidays myself. 955 00:49:30,057 --> 00:49:33,557 So yeah, Aaron, thank you so much for taking the time. 956 00:49:33,627 --> 00:49:35,357 We have quite a time zone difference. 957 00:49:35,397 --> 00:49:39,307 I'm here like in Berlin where it's already quite late and you're in beautiful 958 00:49:39,327 --> 00:49:42,089 Hawaii with the very background. 959 00:49:42,569 --> 00:49:45,949 So thank you so much for taking the time and sharing everything. 960 00:49:46,559 --> 00:49:46,909 All right. 961 00:49:46,959 --> 00:49:47,299 Yeah. 962 00:49:47,379 --> 00:49:49,289 I'm really looking forward to hearing the rest of these too. 963 00:49:49,349 --> 00:49:50,989 I'm sure you'll get some really interesting people on here. 964 00:49:51,834 --> 00:49:52,334 Perfect. 965 00:49:53,558 --> 00:49:56,208 Thank you for listening to the Local First FM podcast. 966 00:49:56,428 --> 00:50:00,628 If you've enjoyed this episode and haven't done so already, please subscribe and 967 00:50:00,628 --> 00:50:02,428 leave a review wherever you're listening. 968 00:50:03,198 --> 00:50:06,068 Please also consider telling your friends about it, if you think they 969 00:50:06,068 --> 00:50:07,588 could be interested in Local First. 970 00:50:08,438 --> 00:50:12,088 Thank you again to Expo and Crab Nebula for supporting this podcast. 971 00:50:12,358 --> 00:50:13,158 See you next time.