WEBVTT 1 00:00:05.360 --> 00:00:09.240 Hey, folks, welcome back to another episode of JavaScript Jabber. 2 00:00:09.599 --> 00:00:12.800 This week on our panel, we have a j O'Neill Yoh. 3 00:00:12.640 --> 00:00:18.160 Yeah, coming at you live from the sickness. Oh no, 4 00:00:18.239 --> 00:00:20.800 I'm feeling better today. Yesterday I was a little under 5 00:00:20.839 --> 00:00:23.000 the weather. I just slept all day and I feel good. 6 00:00:23.000 --> 00:00:23.960 I'm just a little groggy. 7 00:00:24.559 --> 00:00:27.480 I still have some turkey soup from Thanksgiving. Maybe i'll 8 00:00:27.519 --> 00:00:27.960 drop by. 9 00:00:28.760 --> 00:00:31.079 I'm Charles Max from. 10 00:00:31.000 --> 00:00:34.920 Top End Devs and this week where we have a 11 00:00:34.960 --> 00:00:36.200 special guest, it's ONNSE. 12 00:00:37.520 --> 00:00:39.200 Sorry I don't have your last name in front of me. 13 00:00:39.240 --> 00:00:41.880 I usually my last name is Ko, but that's like 14 00:00:42.000 --> 00:00:45.119 even more difficult. Don't worry about it. Nice toy. You 15 00:00:45.159 --> 00:00:46.719 guys very happy to be here. 16 00:00:47.439 --> 00:00:50.119 Yeah, the foreign names kind of throw us off. Sometimes 17 00:00:51.359 --> 00:00:53.920 you want to introduce yourself real quick. I mean, I 18 00:00:53.960 --> 00:00:56.000 have jazz dot tools is something you work on. 19 00:00:56.039 --> 00:01:00.880 But yeah, sure, So I'm like, broadly speaking, a full 20 00:01:00.920 --> 00:01:03.880 stex software engineer. Have worked kind of as a freelancer 21 00:01:03.960 --> 00:01:06.799 most of my life. I'm originally from Germany. I live 22 00:01:06.840 --> 00:01:09.840 in the UK now and I kind of just kept 23 00:01:10.040 --> 00:01:12.799 building apps for different companies, always kind of taking them 24 00:01:12.799 --> 00:01:16.359 from zero to one and just felt like I'm always 25 00:01:16.439 --> 00:01:19.359 doing the same stuff and I never really had a 26 00:01:19.400 --> 00:01:21.879 good answer to how to solve that problem until I 27 00:01:21.959 --> 00:01:24.680 ran into what is now known as local First, and 28 00:01:24.719 --> 00:01:27.879 that kind of became Jazz. That's like my mini origin 29 00:01:27.959 --> 00:01:28.680 story on that. 30 00:01:30.200 --> 00:01:30.640 Awesome. 31 00:01:30.799 --> 00:01:33.439 So, so are you the main person behind Jazz. 32 00:01:34.040 --> 00:01:36.959 Yeah. So I've been working on it for a bit 33 00:01:37.040 --> 00:01:40.200 over four and a half years now, and then since 34 00:01:40.439 --> 00:01:43.439 this summer it's a company and I raised some funding 35 00:01:43.480 --> 00:01:45.120 and so on. But before that it was just like 36 00:01:45.680 --> 00:01:47.599 my side main project. 37 00:01:48.439 --> 00:01:48.719 Nice. 38 00:01:48.840 --> 00:01:49.159 Nice. 39 00:01:50.480 --> 00:01:53.640 So I just have to ask, just right off the bat, 40 00:01:53.680 --> 00:01:56.560 because you said local first, you go to jazz dot 41 00:01:56.640 --> 00:02:00.760 tools dot or jazz dot tools. I almost added to that, 42 00:02:00.799 --> 00:02:02.959 but guys, there's no dot com. It's Jazz dot tools 43 00:02:03.439 --> 00:02:09.080 on the internet, and it says local first, and of 44 00:02:09.120 --> 00:02:11.280 course my brain goes through is it one of these 45 00:02:11.319 --> 00:02:12.280 eighty different things? 46 00:02:12.319 --> 00:02:13.960 So do you want to just kind. 47 00:02:13.840 --> 00:02:16.639 Of explain give us some context of what kind of 48 00:02:16.639 --> 00:02:18.840 apps we're looking at and what you mean by local 49 00:02:18.919 --> 00:02:23.159 verst so that we're not talking about things different things 50 00:02:23.159 --> 00:02:24.960 that people are thinking, oh it's this, and then we're 51 00:02:25.000 --> 00:02:25.960 talking about this other thing. 52 00:02:26.840 --> 00:02:29.000 Yeah. Sure, So, like local first is kind of a 53 00:02:29.080 --> 00:02:33.439 new term and a new sphere, Like everyone who is 54 00:02:33.479 --> 00:02:36.240 into it seems to have bumped into it their own way, 55 00:02:37.439 --> 00:02:40.240 and it means because it's so early in the movement, 56 00:02:40.240 --> 00:02:42.680 it means a lot of different things to different people, right, 57 00:02:43.039 --> 00:02:48.120 And I think what everyone has in common in terms 58 00:02:48.159 --> 00:02:50.520 of how they would define it as like you move 59 00:02:50.560 --> 00:02:53.319 away from the traditional stack model where you have a 60 00:02:53.360 --> 00:02:56.120 back end and a front end and most of the 61 00:02:56.120 --> 00:02:59.479 authoritypive state lifts in your database and the beckend interacts 62 00:02:59.520 --> 00:03:01.960 with that, and the front then kind of sense requests 63 00:03:02.000 --> 00:03:04.520 to the back end. You move away from that to 64 00:03:04.560 --> 00:03:08.479 a new model where you try to keep as much 65 00:03:08.560 --> 00:03:11.120 state as possible or maybe even all state in the 66 00:03:11.199 --> 00:03:15.039 client and you just write youI around that as if 67 00:03:15.039 --> 00:03:17.759 you were building basically an old school offline app that 68 00:03:17.960 --> 00:03:21.560 just writes to memory too disc but then that state 69 00:03:21.639 --> 00:03:24.479 gets synced to other participants because of course you still 70 00:03:24.520 --> 00:03:27.400 want to interact with other users, maybe even have real 71 00:03:27.400 --> 00:03:30.039 time multiplayer that sort of stuff. So you kind of 72 00:03:30.560 --> 00:03:32.719 the way I like to look at it is it 73 00:03:32.759 --> 00:03:35.599 is that we're so used to the traditional stack as like, 74 00:03:35.680 --> 00:03:38.240 obviously that's how you build web apps, but if you 75 00:03:38.240 --> 00:03:40.719 think about it, what the stacks do is they just 76 00:03:40.919 --> 00:03:44.479 facilitate sharing state between users, and the way they do 77 00:03:44.520 --> 00:03:49.000 that traditionally is by having like centralized authoritative state. And 78 00:03:49.360 --> 00:03:51.879 with local first, you just turn that problem around and 79 00:03:51.919 --> 00:03:55.560 you like, what if everyone kept state locally and then 80 00:03:55.560 --> 00:03:57.400 how do we sink between participants? 81 00:03:58.520 --> 00:04:03.719 So this reminds me a little bit of how things 82 00:04:03.759 --> 00:04:08.080 like web RTC works, right, where you can have a 83 00:04:08.080 --> 00:04:10.360 lot of times there's a server that kind of coordinates, 84 00:04:10.360 --> 00:04:13.319 so people will hit the server first and say. 85 00:04:13.199 --> 00:04:14.759 You know who else can I connect to? 86 00:04:14.919 --> 00:04:17.639 But then you can do peer to peer video, right, 87 00:04:18.000 --> 00:04:22.199 Or you've got other peer to peer apps where kind 88 00:04:22.199 --> 00:04:25.360 of like BitTorrent, I guess right, where if you know 89 00:04:25.480 --> 00:04:28.120 where the other participants are, you can go ahead and 90 00:04:28.199 --> 00:04:31.079 share in this case as parts of a file. 91 00:04:31.240 --> 00:04:33.160 But it's the same idea, right. 92 00:04:33.800 --> 00:04:36.360 Yeah, And like I really like this comparison because that 93 00:04:36.480 --> 00:04:39.600 lets us get into more precisely what it is, because 94 00:04:40.000 --> 00:04:43.480 something like web ARTC or BitTorrent that's mostly about the 95 00:04:43.519 --> 00:04:46.279 transport mechanism, like how do you find the other peers? 96 00:04:46.839 --> 00:04:49.560 Local first is kind of like almost orthogonal to that 97 00:04:49.639 --> 00:04:51.839 you can do local first in a peer to peer way. 98 00:04:51.920 --> 00:04:55.000 But you can also do it with some centralized sinking infrastructure, 99 00:04:55.040 --> 00:04:58.759 which is what Jazz tools implements. For example, what local 100 00:04:58.800 --> 00:05:04.600 first is about is mostly solving the problem of well, 101 00:05:04.959 --> 00:05:07.079 if you write against the state as if it was 102 00:05:07.160 --> 00:05:11.120 local state, what should happen if multiple people added the 103 00:05:11.160 --> 00:05:14.600 same piece of content. Again, in the traditional stack model, 104 00:05:15.199 --> 00:05:18.519 this problem doesn't really exist because it just depends whoever's 105 00:05:18.720 --> 00:05:22.160 request comes first, and then there's one central state. In 106 00:05:22.160 --> 00:05:24.759 this case, you have distributed state, and how do you 107 00:05:25.560 --> 00:05:28.120 solve for conflicts and distributed state? And what you get 108 00:05:28.160 --> 00:05:32.759 then is something that works very similarly to GIT. And again, 109 00:05:33.560 --> 00:05:38.399 different local first frameworks or services do different things, but 110 00:05:38.759 --> 00:05:40.920 what seems to be the most common is to rely 111 00:05:41.120 --> 00:05:45.360 on a technology called conflict free replicated data Types or 112 00:05:45.399 --> 00:05:48.360 CORDTS for short. That's the term that's starting to be 113 00:05:48.399 --> 00:05:52.480 thrown around more. That's an idea that JAZZ is based 114 00:05:52.519 --> 00:05:54.519 on that many others are based on. And the way 115 00:05:54.519 --> 00:05:57.279 I like to illustrate that is that it's very much 116 00:05:57.560 --> 00:06:01.399 like GIT in that have your local state that you 117 00:06:01.519 --> 00:06:04.480 work with, and then you share your edits with other 118 00:06:04.560 --> 00:06:08.399 people and there's something akin to merging and contract resolution. 119 00:06:09.439 --> 00:06:12.439 The difference to get is that it's much more fine 120 00:06:12.480 --> 00:06:14.959 grained well, and get you kind of do pretty large 121 00:06:15.000 --> 00:06:18.079 commits right over, like maybe an hour's worth of time 122 00:06:18.160 --> 00:06:21.759 or something for crdts. Imagine if you made these commits 123 00:06:21.759 --> 00:06:25.839 smaller and smaller until like every single keystroke and every 124 00:06:25.879 --> 00:06:29.600 single edit of an object property becomes a commit, and 125 00:06:29.639 --> 00:06:33.839 then that's what you think to Actually, objects no longer 126 00:06:34.000 --> 00:06:36.759 are like their current state, but they're just represented by 127 00:06:36.759 --> 00:06:39.120 the entire history of everything that ever happened to them. 128 00:06:39.439 --> 00:06:41.240 And again, I have to be careful here not to 129 00:06:41.279 --> 00:06:46.040 get too specific to how jazz works, how jazz interpret crdts, 130 00:06:46.439 --> 00:06:50.560 but this is like a common story. And what Jazz 131 00:06:50.560 --> 00:06:54.399 does basically is you as the application developer. It gives 132 00:06:54.399 --> 00:06:56.839 you an API that makes these objects look like simple, 133 00:06:56.920 --> 00:06:59.480 mutable objects that you can write to and read from 134 00:07:00.160 --> 00:07:03.560 the hood. It converts these edits into changes in the history, 135 00:07:03.639 --> 00:07:06.879 and then kind of reconciles that history with everyone else 136 00:07:06.920 --> 00:07:09.399 who's interested in the same object based on their edits. 137 00:07:09.519 --> 00:07:11.199 Does that start to give you an idea? 138 00:07:12.040 --> 00:07:12.240 Right? 139 00:07:12.319 --> 00:07:14.680 It sounds a little bit more like Google docs, where 140 00:07:14.759 --> 00:07:17.639 you might have multiple people editing the same file or 141 00:07:17.680 --> 00:07:21.680 the same dock at the same time. And as they type, 142 00:07:21.800 --> 00:07:25.439 shows up on my page, and as I type, it 143 00:07:25.439 --> 00:07:28.160 shows up on their page. And if we're typing over 144 00:07:28.199 --> 00:07:31.959 the same space, then yeah, it's got to figure out, Okay. 145 00:07:32.399 --> 00:07:35.319 How do we figure out whose edits. 146 00:07:35.120 --> 00:07:38.800 Or what exactly? And it's kind of clear how that's 147 00:07:38.879 --> 00:07:41.240 useful in something like Google Docs where you have real 148 00:07:41.360 --> 00:07:45.199 time communication. But the way I like to think about it, 149 00:07:45.279 --> 00:07:47.480 and to get back to your original question of like 150 00:07:47.560 --> 00:07:50.319 what kinds of app is that for? There are a 151 00:07:50.360 --> 00:07:52.000 lot of people who are saying, like, look, there's this 152 00:07:52.120 --> 00:07:54.959 new niche of local first apps where this kind of 153 00:07:55.040 --> 00:07:57.439 way of building apps is particularly suited, and you can 154 00:07:57.480 --> 00:08:01.480 see that with your Google Docs example. But my approach 155 00:08:01.519 --> 00:08:03.920 there is to be like, no, this is actually a 156 00:08:03.959 --> 00:08:06.439 better way to build any kind of app, and the 157 00:08:06.480 --> 00:08:09.120 real time multiplayer is kind of just the extreme case, 158 00:08:09.160 --> 00:08:12.519 and anything less interactive than that can still be solved 159 00:08:12.519 --> 00:08:15.519 with the same pattern. And one of the major other 160 00:08:15.560 --> 00:08:17.879 features that you get from local first is that it 161 00:08:17.959 --> 00:08:22.160 is offline first, because you can write against you state locally. 162 00:08:22.199 --> 00:08:24.480 Even if you don't have a connection, your app keeps working, 163 00:08:24.560 --> 00:08:28.040 and you just think when you come back online, and 164 00:08:28.079 --> 00:08:30.800 you can kind of imagine the spectrum of like really intense, 165 00:08:30.839 --> 00:08:34.519 really interactive real time multiplayer on the one end, and 166 00:08:34.559 --> 00:08:38.399 like being completely offline on the other hand, and then 167 00:08:38.519 --> 00:08:40.639 in the middle you have something more like a traditional 168 00:08:40.679 --> 00:08:44.840 app where you have like some multi user collaborative app 169 00:08:44.919 --> 00:08:47.559 like a productivity app, or maybe a social network where 170 00:08:47.559 --> 00:08:51.360 you have some frequency of interaction. And so far we 171 00:08:51.440 --> 00:08:55.360 needed very different ways of building apps and frameworks for 172 00:08:55.440 --> 00:08:58.879 each of these cases. But Cordts and the idea of 173 00:08:58.960 --> 00:09:01.519 local first is actually something that lets you solve all 174 00:09:01.559 --> 00:09:05.240 of these cases with one abstraction. And what's nice there 175 00:09:05.279 --> 00:09:08.200 is that you don't have to choose what kind of 176 00:09:08.240 --> 00:09:10.440 app you're going to build because some parts of your 177 00:09:10.440 --> 00:09:13.320 app some features might be more real time, some features 178 00:09:13.399 --> 00:09:17.159 might be like less frequent updates, less collaborative, more personal, 179 00:09:17.200 --> 00:09:19.960 and so on. And that's kind of what really got 180 00:09:20.000 --> 00:09:22.200 me into the idea and where I'm like, oh, this 181 00:09:22.679 --> 00:09:24.279 can actually solve a lot of things. 182 00:09:25.519 --> 00:09:32.360 So one thing I often ask is what is this 183 00:09:33.240 --> 00:09:36.480 not a good use case for? Like when would I 184 00:09:36.679 --> 00:09:40.159 not want to use this? Because I think hearing we 185 00:09:40.200 --> 00:09:44.879 can use this for anything is a little bit it's 186 00:09:44.960 --> 00:09:48.000 not helpful to know, like we can use it for anything. 187 00:09:48.039 --> 00:09:50.120 So I think sometimes knowing what we shouldn't use it 188 00:09:50.159 --> 00:09:53.600 for helps us to better understand why it's actually really useful. 189 00:09:53.639 --> 00:09:56.120 So when would I not want to be using local 190 00:09:56.159 --> 00:09:57.559 first or jazz? 191 00:09:58.600 --> 00:10:01.720 So I'm going to give you a really annoying first answer, 192 00:10:01.759 --> 00:10:04.720 which is nothing and and kind of like the counter question, 193 00:10:04.840 --> 00:10:09.360 like what is React not good for? Within web? Absolutely? 194 00:10:09.440 --> 00:10:13.840 Say, you know you are knowing the wrong man about that. 195 00:10:15.399 --> 00:10:16.799 What's what's your favorite pick? 196 00:10:18.080 --> 00:10:18.279 Yeah? 197 00:10:18.440 --> 00:10:22.320 Mhmm, what's your favorite pick other than React? No? 198 00:10:22.440 --> 00:10:23.639 I don't. I don't like React? 199 00:10:25.120 --> 00:10:25.720 What what would you? 200 00:10:26.240 --> 00:10:26.399 What? 201 00:10:26.399 --> 00:10:27.600 What would what would you? 202 00:10:27.720 --> 00:10:30.519 I just so, so, first of all, I mostly do 203 00:10:30.879 --> 00:10:34.039 back end or library so I do. I do tons 204 00:10:34.080 --> 00:10:36.919 of front end code, but my front end code is 205 00:10:36.919 --> 00:10:41.039 is in libraries where your people are are used using 206 00:10:41.039 --> 00:10:42.720 it as a as a library. It doesn't matter whether 207 00:10:42.759 --> 00:10:47.159 it's back in the front But when I do JavaScript 208 00:10:47.200 --> 00:10:49.639 on the front end, I just use JavaScript. Now, like 209 00:10:49.679 --> 00:10:52.879 the dom is so good good, I'm not. I'm not 210 00:10:53.000 --> 00:10:56.639 building things that are large enough or I don't even 211 00:10:56.679 --> 00:10:59.960 know things exist that are large enough that just JavaScript 212 00:11:00.039 --> 00:11:02.240 as it is isn't good enough these days? 213 00:11:02.399 --> 00:11:04.200 Fair fair enough, fair enough? Okay. 214 00:11:04.519 --> 00:11:08.240 It's very similar to AJS where I use a framework 215 00:11:08.279 --> 00:11:11.759 called Stimulus, and then I use another library called Turbo, 216 00:11:11.879 --> 00:11:14.159 which is a lot like HTMX and. 217 00:11:15.759 --> 00:11:18.759 So interesting. So it very gives me a way to 218 00:11:18.879 --> 00:11:24.480 organize my dom calls. 219 00:11:23.200 --> 00:11:25.639 Cool Okay, So yeah, my comparison there would have gone 220 00:11:25.720 --> 00:11:28.360 nowhere because I'm used to to talking to very different 221 00:11:28.360 --> 00:11:30.360 people who are very into React. So I would ask 222 00:11:30.399 --> 00:11:32.200 them back, like, well, what is React good for? And 223 00:11:32.279 --> 00:11:34.840 they would say, well, any kind of That's kind of 224 00:11:34.840 --> 00:11:36.279 what I was saying at. 225 00:11:36.240 --> 00:11:39.240 To React is really good for things that have infinite scrolls. 226 00:11:39.840 --> 00:11:42.360 That's what React was designed for. That's what it's really 227 00:11:42.360 --> 00:11:42.799 great at. 228 00:11:43.720 --> 00:11:46.879 It it so my my thing, and maybe this will 229 00:11:46.879 --> 00:11:49.240 give you a better way to answer this, right, is 230 00:11:49.279 --> 00:11:50.759 I feel like there are trade offs? 231 00:11:51.000 --> 00:11:51.919 Right of course? 232 00:11:52.240 --> 00:11:55.600 Sorry, that was the first like annoying part of my answer. 233 00:11:55.639 --> 00:11:58.240 To be more precise, like, I think a better way 234 00:11:58.320 --> 00:12:00.919 to say it is that events should. I want it 235 00:12:00.960 --> 00:12:02.519 to be good for any kind of app. 236 00:12:02.799 --> 00:12:02.919 Right. 237 00:12:04.080 --> 00:12:06.360 The reason it might not be right now is because 238 00:12:06.360 --> 00:12:09.799 we're early, and because specifically for Jazz tools, we decided 239 00:12:09.840 --> 00:12:15.159 to prior tie certain features over others. So, for example, 240 00:12:16.519 --> 00:12:20.679 if you have an app where you definitely need authoritative 241 00:12:20.799 --> 00:12:24.799 centralized state, like you're building a bank or something like that, 242 00:12:25.000 --> 00:12:28.279 and there can only be one balance of your account 243 00:12:28.320 --> 00:12:31.480 at any time. You you could actually build us on 244 00:12:31.519 --> 00:12:34.600 top of jazz that you can implement authoritative state with 245 00:12:35.559 --> 00:12:37.720 a local first framework, but it's going to be more 246 00:12:37.759 --> 00:12:39.480 awkward than the traditional. 247 00:12:39.000 --> 00:12:42.840 Thing because you have you have a tighter constraint. You 248 00:12:42.879 --> 00:12:44.519 have to make sure that everything lines up on the 249 00:12:44.519 --> 00:12:45.519 front end back end. 250 00:12:46.879 --> 00:12:51.000 It's it's basically like what you do then, is you 251 00:12:51.159 --> 00:12:54.480 re implement something like requests on top of the local 252 00:12:54.559 --> 00:12:58.759 first state, which sounds elaborate but actually has some nice 253 00:12:58.840 --> 00:13:02.240 drawbacks because you're basic get optimistic updates on the front 254 00:13:02.320 --> 00:13:04.279 end for free. But that's kind of that's a way 255 00:13:04.320 --> 00:13:06.039 more advanced topic that I want to get into at 256 00:13:06.039 --> 00:13:11.399 this point. Another thing is like if you need some 257 00:13:11.480 --> 00:13:14.440 of the more advanced bread and butter database features like 258 00:13:15.039 --> 00:13:18.399 in DCS over huge amounts of data, full text search, 259 00:13:18.519 --> 00:13:21.120 that's something that we haven't implemented as features yet, but 260 00:13:21.159 --> 00:13:24.960 they're not like impossible to do with local first. So 261 00:13:25.000 --> 00:13:27.600 this is an interesting example to kind of start giving 262 00:13:27.600 --> 00:13:30.960 you an idea of what kind of apps it's already 263 00:13:30.960 --> 00:13:33.120 really good for. Maybe where the boundary is like. 264 00:13:35.559 --> 00:13:37.000 Using index dB. 265 00:13:37.840 --> 00:13:40.600 Yes, that's what we use for in browser persistence. We're 266 00:13:40.639 --> 00:13:44.480 currently moving to OPFs, which lets us write directly to 267 00:13:45.000 --> 00:13:47.639 like an isolated file system on the client where we 268 00:13:47.679 --> 00:13:49.120 implement and storyteller. 269 00:13:50.120 --> 00:13:52.080 Is that implemented in browsers. 270 00:13:51.639 --> 00:13:54.159 Out Yes, that's widely supported. Not a lot of people 271 00:13:54.200 --> 00:13:56.360 know about it. The nice thing is if you use 272 00:13:56.399 --> 00:13:59.639 something like Jazz, that's like, I guess that's a major 273 00:13:59.679 --> 00:14:01.600 important point. If you use something like Jazz, you don't 274 00:14:01.600 --> 00:14:04.120 need to worry about the persistence and about the networking. 275 00:14:04.200 --> 00:14:08.120 You just manipulate objects basically, right, and it can have 276 00:14:08.159 --> 00:14:11.480 different storage implementations under the hood. It could communicate over 277 00:14:11.519 --> 00:14:14.360 web sockets, web party see in the future maybe something 278 00:14:14.440 --> 00:14:20.120 like quick and what that lets you do is like 279 00:14:20.279 --> 00:14:23.360 really quickly build apps on the abstraction level of like 280 00:14:25.080 --> 00:14:27.039 what do users do in my app and what kind 281 00:14:27.080 --> 00:14:29.240 of objects do they interact with? That's kind of all 282 00:14:29.279 --> 00:14:32.919 you have to think about and what you like. Because 283 00:14:32.960 --> 00:14:37.080 of the performance characteristics of local first, what you get 284 00:14:37.120 --> 00:14:39.720 away with very often if you have apps with like 285 00:14:39.759 --> 00:14:43.399 small teams where a couple people interact, you can literally 286 00:14:43.519 --> 00:14:47.639 keep all the data belonging to that team locally on 287 00:14:47.639 --> 00:14:52.519 each device. The only reason it's hard to scale, for example, 288 00:14:52.559 --> 00:14:56.399 productivity apps is because in a traditional model, the central 289 00:14:56.480 --> 00:14:58.919 database kind of needs to keep the data for every 290 00:14:58.919 --> 00:15:02.279 single team, which might be millions of them. With local first, 291 00:15:03.799 --> 00:15:05.799 each of the team's devices just needs to keep the 292 00:15:05.840 --> 00:15:08.399 state for the whole team. And Linear is actually a 293 00:15:08.399 --> 00:15:10.440 good example of an app they build their whole own 294 00:15:10.639 --> 00:15:14.679 local first technology and infrastructure. They keep all of your 295 00:15:14.759 --> 00:15:17.840 team's issues locally on the clent, and that gives you 296 00:15:18.000 --> 00:15:22.960 incredibly fast you X interaction on the client. We see 297 00:15:23.000 --> 00:15:25.399 with a lot of Jazz apps where people ask us like, look, 298 00:15:25.399 --> 00:15:27.440 I want to implement search in my app, so for that, 299 00:15:27.559 --> 00:15:30.320 I need an index, right and so far in every 300 00:15:30.360 --> 00:15:34.320 case you can literally just brute force your way over 301 00:15:34.360 --> 00:15:37.399 every single object in memory, and it's way faster than 302 00:15:37.440 --> 00:15:40.159 any like search feature against an API that that you've 303 00:15:40.159 --> 00:15:42.080 seen in any other app. That's that's kind of what 304 00:15:42.120 --> 00:15:44.399 it's already really good at. Obviously. 305 00:15:44.480 --> 00:15:48.279 Yeah, I've noticed that, like so many times, people you know, 306 00:15:48.320 --> 00:15:51.320 they're thinking too much about optimization and they don't realize 307 00:15:52.080 --> 00:15:54.879 if you don't optimize this, like optimizing it in many 308 00:15:54.879 --> 00:15:57.559 cases makes it slower because then you're adding all the 309 00:15:57.600 --> 00:16:01.480 overhead of the algorithm in the sifting, and like if 310 00:16:01.480 --> 00:16:04.080 it's less than ten thousand items, if maybe one hundred 311 00:16:04.080 --> 00:16:07.879 thousand items, just like brute force it it's the fastest way. 312 00:16:08.799 --> 00:16:13.559 Well, where we start talking about trade offs, right, yeah, hey, 313 00:16:13.600 --> 00:16:16.000 this is really good up to this point and then 314 00:16:17.000 --> 00:16:20.360 not so great or in the other case, it's you know, 315 00:16:20.679 --> 00:16:24.240 now you're over this threshold, so now your optimal case 316 00:16:24.879 --> 00:16:26.960 is to use the tool, right. 317 00:16:26.840 --> 00:16:29.679 So so so let me draw the picture a bit 318 00:16:29.720 --> 00:16:32.120 further than so, what if you start having data sets 319 00:16:32.159 --> 00:16:35.519 that don't fit on a single client's device anymore. And 320 00:16:36.240 --> 00:16:39.799 that's also where we start seeing differences between Jazz tools 321 00:16:39.799 --> 00:16:42.679 and some of the other local first solutions because they 322 00:16:42.679 --> 00:16:45.320 are very much what I would call like sink the world, 323 00:16:45.399 --> 00:16:47.480 like you actually have to keep the entire state and 324 00:16:47.559 --> 00:16:50.720 the client, whereas Jazz from the beginning was built to 325 00:16:50.879 --> 00:16:54.559 support granular sync, where what it does by default that 326 00:16:54.639 --> 00:16:57.679 it just thinks whatever objects you're trying to display right now, 327 00:16:57.919 --> 00:17:00.559 and then over time you kind of accumulate everything that's 328 00:17:00.720 --> 00:17:04.880 important to that user, and you can like a big 329 00:17:05.000 --> 00:17:06.799 things again if you don't need them anymore. But that 330 00:17:06.920 --> 00:17:09.559 means that you can now have like a local first 331 00:17:09.599 --> 00:17:12.400 experience for the data that you're actually interested in, but 332 00:17:12.519 --> 00:17:15.799 you can still work with potentially infinite data sets, and 333 00:17:15.839 --> 00:17:21.119 then you can build You can build indices against tens 334 00:17:21.119 --> 00:17:23.400 of millions of objects, for example on a server work 335 00:17:23.440 --> 00:17:26.359 and then the index itself again becomes a sinkable object, 336 00:17:26.400 --> 00:17:30.240 so the client can create the index locally, see which 337 00:17:30.279 --> 00:17:32.519 objects it might need to load, and all of that 338 00:17:32.640 --> 00:17:37.359 is it's like not one extreme or the other. If 339 00:17:37.359 --> 00:17:41.720 you make local first granularly sinkable, you can actually create 340 00:17:43.119 --> 00:17:45.720 request and networking patterns under the hood that are very 341 00:17:45.759 --> 00:17:50.240 similar to traditional stacks with APIs. But again, you as 342 00:17:50.240 --> 00:17:52.279 a developer don't have to think about that. You just 343 00:17:52.319 --> 00:17:54.640 think about which objects do you want to have and 344 00:17:55.119 --> 00:17:57.880 kind of request them as needed, and it loads whatever 345 00:17:57.920 --> 00:17:58.319 you need. 346 00:18:00.920 --> 00:18:05.440 So personally, I just like to work with JSON and 347 00:18:05.640 --> 00:18:11.319 functions like I don't ever use I literally have never 348 00:18:11.519 --> 00:18:17.319 used JavaScript classes except for experimentally to learn about them. 349 00:18:17.359 --> 00:18:21.680 I have never shipped code with a JavaScript class because 350 00:18:21.720 --> 00:18:26.279 I just find that and I mean, to some degree 351 00:18:26.279 --> 00:18:29.119 it's the concept of functional programming, like the less state 352 00:18:29.200 --> 00:18:31.920 you have to deal with, the better off you are 353 00:18:31.960 --> 00:18:33.759 the easier it is to test. If I can just 354 00:18:33.799 --> 00:18:37.119 take here's a plane object, here's a plane function. I 355 00:18:37.200 --> 00:18:40.759 put the object and some options into the function. I 356 00:18:40.759 --> 00:18:43.799 get the same result out every time. You know, it's 357 00:18:43.880 --> 00:18:45.960 very grug brain dev type stuff. 358 00:18:48.039 --> 00:18:50.160 And I like. 359 00:18:51.440 --> 00:18:57.079 The rest ish APIs. I like rest ish APIs because 360 00:18:57.079 --> 00:18:59.960 they're very very simple to reason about. Like if I 361 00:19:00.000 --> 00:19:03.559 I open up my network console, I can see what's happening. 362 00:19:03.599 --> 00:19:06.680 I know what's going on. I like SQL databases because 363 00:19:06.720 --> 00:19:12.160 they're very simple and proven. And I personally am am 364 00:19:12.200 --> 00:19:15.400 pretty resistant to things that require a lot of state 365 00:19:15.480 --> 00:19:21.960 management or require a lot of bespoke code structure. So 366 00:19:23.200 --> 00:19:27.519 is this something I mean, it sounds like it sounds 367 00:19:27.559 --> 00:19:31.599 like from what I'm hearing, this is very opinionated. It's 368 00:19:31.640 --> 00:19:34.240 like you buy into this way of doing it and 369 00:19:34.279 --> 00:19:36.680 you're going to adopt it, which I think is great. 370 00:19:38.880 --> 00:19:42.400 It's probably not something that I personally latch onto. But 371 00:19:42.440 --> 00:19:45.079 I do really really believe that, you know, if you're 372 00:19:45.079 --> 00:19:48.599 gonna if you're gonna make something really great, yeah, integrate 373 00:19:48.680 --> 00:19:50.359 it and just tell people they have to buy in. 374 00:19:51.920 --> 00:19:55.640 But I'm I'm not sure if I'm representing that correctly. 375 00:19:55.799 --> 00:19:58.920 Is this like a very streamlined, top to bottom solution. 376 00:19:59.519 --> 00:20:02.000 Or is this something where I can kind of take 377 00:20:02.680 --> 00:20:06.119 the approach of just plain objects and plain functions and 378 00:20:06.799 --> 00:20:11.920 build an application where I'm essentially replacing my res diish 379 00:20:12.640 --> 00:20:15.039 calls with jazz Ish calls. 380 00:20:16.119 --> 00:20:18.839 Right, so you're mentioning a bunch of important things there, 381 00:20:18.839 --> 00:20:24.200 and let me maybe start from what jazz consists of. 382 00:20:24.240 --> 00:20:26.519 It's kind of two layers. It's Jazz, which is like 383 00:20:26.799 --> 00:20:30.200 the opinionated framework, and then below that a protocol which 384 00:20:30.839 --> 00:20:33.279 is called CO Jason. I haven't written much about that yet. 385 00:20:33.319 --> 00:20:35.559 It's because it's so far it's just like internals of 386 00:20:35.640 --> 00:20:38.799 the framework, but it will be an open standard which 387 00:20:38.920 --> 00:20:44.319 defines how what I'm calling CO values work. Which these 388 00:20:44.359 --> 00:20:47.799 are your new primitives, and they are very much like 389 00:20:47.880 --> 00:20:52.599 they're supposed to be, just like collaborative Jason. You have objects, 390 00:20:52.640 --> 00:20:56.200 you have lists, and a bunch of other things for 391 00:20:56.359 --> 00:20:59.480 like text and rich text. But it's basically what if 392 00:21:00.079 --> 00:21:02.880 what if? Yeah, what if Jason was just collaborative? And 393 00:21:02.960 --> 00:21:06.240 that's your abstraction. It like, if you read it, it 394 00:21:06.279 --> 00:21:09.000 looks just like Plaine Jason. If you write to it, 395 00:21:09.039 --> 00:21:12.319 you kind of have the choice between two different APIs, 396 00:21:12.599 --> 00:21:15.200 and that's where we get into the higher level opinionated thing. 397 00:21:15.640 --> 00:21:20.640 What Jazz implements is something very similar to and like react. 398 00:21:20.640 --> 00:21:23.039 People with no libraries like mobs, where like you know 399 00:21:23.119 --> 00:21:26.799 and React, even with like just used with use state, 400 00:21:26.920 --> 00:21:30.319 you get like the current readable version of the state 401 00:21:30.359 --> 00:21:34.720