WEBVTT 1 00:00:05.160 --> 00:00:10.000 Hello everybody, and welcome to another exciting episode of JavaScript 2 00:00:10.039 --> 00:00:15.599 jabber Z on Today's Toys. I've always wanted to say 3 00:00:15.640 --> 00:00:19.359 the Z, but I refrain just letting loose. Today today 4 00:00:20.800 --> 00:00:25.000 we have with us Steve Yo. 5 00:00:25.160 --> 00:00:26.640 I'm one of the I guess I'm one of the 6 00:00:26.960 --> 00:00:31.879 zombies in JavaScript jabber Z. Right, isn't that World war Z? 7 00:00:32.039 --> 00:00:33.000 Is that what you're going for? 8 00:00:33.520 --> 00:00:38.079 Well, it's more like vegeta and gohan but close. Sorry, 9 00:00:38.119 --> 00:00:41.039 they're they're kind of undead. They are undead, they are 10 00:00:41.039 --> 00:00:44.640 technically undead. They are technically zombies. Uh, I am, I'm 11 00:00:44.640 --> 00:00:47.719 gonna be your your what No? I host goes last, okay, 12 00:00:48.359 --> 00:00:50.000 and then Kyle ed get a pie. 13 00:00:50.960 --> 00:00:55.799 Hello, Hello, everyone, got to be back and I am 14 00:00:55.960 --> 00:00:58.640 your host today A j O'Neill yo yo yo, coming 15 00:00:58.679 --> 00:01:03.119 at you from Oh my goodness. I bought this stinky 16 00:01:03.399 --> 00:01:05.640 thing fly catcher thing, and it's stinking up the whole 17 00:01:05.640 --> 00:01:07.359 shed and I've got to have the shed door open 18 00:01:08.040 --> 00:01:08.439 a gen. 19 00:01:09.400 --> 00:01:10.439 But does it catch flies? 20 00:01:13.519 --> 00:01:14.200 You know that that? 21 00:01:14.319 --> 00:01:16.159 I don't know, But the flies haven't been bugging me, 22 00:01:16.239 --> 00:01:18.519 so I think I think it's uh, it's working. And 23 00:01:18.560 --> 00:01:19.920 obviously I'm not really a gen. 24 00:01:20.040 --> 00:01:20.280 I just. 25 00:01:20.879 --> 00:01:23.040 I just I've been hooked on too much primagen lately, 26 00:01:23.079 --> 00:01:27.200 and so I you know, not mock imitation is the 27 00:01:27.239 --> 00:01:29.680 serious form thought it anyway. Okay, so let's get into this. 28 00:01:30.680 --> 00:01:33.640 First question I have for you is for those of 29 00:01:33.680 --> 00:01:37.120 you that don't know, no even before that you're now 30 00:01:37.439 --> 00:01:40.519 get if i X. What was why did you change 31 00:01:40.519 --> 00:01:41.959 from getti fi to get if i X. 32 00:01:43.400 --> 00:01:46.760 So I had I still have the getafy account, and 33 00:01:46.799 --> 00:01:51.439 I just sort of I did a switcheroo where I 34 00:01:51.480 --> 00:01:54.280 created a new account and then swapped the two user 35 00:01:54.359 --> 00:01:56.519 names so that the followers that used to be on 36 00:01:56.599 --> 00:01:59.840 gettifi are now on getifi X. But there is still 37 00:02:00.040 --> 00:02:03.000 a getify account, so that's not it's reserved so that 38 00:02:03.040 --> 00:02:07.920 nobody else is using it. What actually happened was employment. 39 00:02:08.240 --> 00:02:10.879 A couple of years ago. The company that I was 40 00:02:10.919 --> 00:02:17.479 working for was concerned that I was that I needed 41 00:02:17.479 --> 00:02:20.400 to make sure to represent them and so or be 42 00:02:20.560 --> 00:02:24.159 clear in my social media representation. So at that time 43 00:02:24.240 --> 00:02:28.840 I switched my Twitter handle from getifi to getifi at 44 00:02:28.879 --> 00:02:32.680 and then the name of that company. And then I 45 00:02:32.759 --> 00:02:35.479 worked there for ten months or something like that, and 46 00:02:35.479 --> 00:02:37.759 then I was not working there and I was going 47 00:02:37.800 --> 00:02:40.199 to switch back to just straight up Getify, but then 48 00:02:40.400 --> 00:02:43.000 we had already had the rename of Twitter to X 49 00:02:43.159 --> 00:02:45.199 and I was like, oh, well, let's go with this. 50 00:02:45.400 --> 00:02:48.800 So I just went back to Getifi X. But again 51 00:02:48.840 --> 00:02:52.400 I still have that other Getifi account, so one or 52 00:02:52.400 --> 00:02:54.560 the other, but I mean the active one that I'm 53 00:02:54.639 --> 00:02:56.360 using is the getifi X account. 54 00:02:57.000 --> 00:02:58.680 Okay, cool? And I think that's how a lot of 55 00:02:58.680 --> 00:03:00.639 people know you. But for those that don't know you, 56 00:03:02.520 --> 00:03:04.439 how did you get to be so famous? And why 57 00:03:04.439 --> 00:03:05.120 don't they know you? 58 00:03:06.960 --> 00:03:11.879 Why? Why? Why? Well, so if we go back to 59 00:03:13.319 --> 00:03:16.039 a long, long time ago, in a land far away 60 00:03:18.159 --> 00:03:21.439 mid to late two thousands, like two thousand and seven, 61 00:03:21.560 --> 00:03:24.879 eight nine, that timeframe, that was kind of the first 62 00:03:25.879 --> 00:03:31.159 rise of JavaScript. We'd had frameworks like MuTools and Dojo, 63 00:03:31.280 --> 00:03:35.360 and then j Querry came along and Doug Crockford wrote 64 00:03:35.360 --> 00:03:37.639 a book in two thousand and eight called JavaScript The 65 00:03:37.639 --> 00:03:39.879 Good Parts, and we began to see kind of a 66 00:03:39.919 --> 00:03:45.319 renaissance re imagining of JavaScript around that time. I had 67 00:03:45.439 --> 00:03:49.159 made an earlier bet, many years before that, that I 68 00:03:49.280 --> 00:03:51.719 was going to want to be an expert in JavaScript 69 00:03:51.759 --> 00:03:54.000 because people are going to want expertise, And that was 70 00:03:54.039 --> 00:03:56.560 going to be a good career path. That turned out 71 00:03:56.560 --> 00:03:58.560 to be a good bet, But I made that early 72 00:03:58.560 --> 00:04:02.879 bet on JavaScript started focusing on that, and so by 73 00:04:02.919 --> 00:04:06.360 that time that JavaScript started to take over in the 74 00:04:06.400 --> 00:04:10.479 more public sense, and we started to have you know, 75 00:04:10.639 --> 00:04:13.159 JS comp I remember in two thousand and nine the 76 00:04:13.159 --> 00:04:16.279 first JAS comf in DC. We started to have conferences 77 00:04:16.279 --> 00:04:20.240 around JavaScript, and there started to be job descriptions around JavaScript, 78 00:04:20.800 --> 00:04:24.199 and I had some pretty strong thoughts. Having already spent 79 00:04:24.279 --> 00:04:25.639 quite a bit of time with the language, I had 80 00:04:25.639 --> 00:04:28.720 some pretty strong thoughts about it, so I started trying 81 00:04:28.720 --> 00:04:32.519 to participate. The first thing I was known for was 82 00:04:32.920 --> 00:04:37.839 a dynamic scriptloader called lab jas that came out in 83 00:04:37.920 --> 00:04:42.000 early two thousand and nine and got pretty big. Was 84 00:04:42.079 --> 00:04:45.439 used on quite a few big sites like Twitter and 85 00:04:45.560 --> 00:04:48.720 Vimeo and Zappos and a few others, and so that's 86 00:04:48.800 --> 00:04:51.040 kind of the first way that people knew me. You 87 00:04:51.120 --> 00:04:55.000 fast forward another couple of years and all the fame 88 00:04:55.079 --> 00:04:59.759 of a tiny two kilobyte library had faded. I'm saying 89 00:04:59.759 --> 00:05:03.759 that tongue in cheek, but that had faded. I had 90 00:05:03.800 --> 00:05:08.040 started to do some conference talks around various JavaScript and 91 00:05:08.040 --> 00:05:11.519 performance aspects, but I really felt like, I had some 92 00:05:11.639 --> 00:05:13.920 things I wanted to say about the language itself, and 93 00:05:14.000 --> 00:05:17.759 I started writing the you Don't Know JS books, and 94 00:05:17.839 --> 00:05:21.360 that is how most people have heard of me. Is 95 00:05:21.519 --> 00:05:26.839 the sixth volume set, the sixth volume of the first edition. 96 00:05:27.439 --> 00:05:31.600 Second edition is a little more complicated in its status 97 00:05:31.680 --> 00:05:35.720 and length. But I came back, So the first edition 98 00:05:35.879 --> 00:05:38.680 was released in twenty fourteen and twenty fifteen. Then I 99 00:05:38.720 --> 00:05:41.240 came back in twenty twenty and started the second edition, 100 00:05:41.959 --> 00:05:44.240 and those are kind of on the shelf now, not 101 00:05:44.279 --> 00:05:49.079 really actively being developed. But that's yeah, two editions of 102 00:05:49.120 --> 00:05:53.639 a six book series. Basically, okay, cool, all right, Yeah, 103 00:05:53.639 --> 00:05:57.839 and say I should say specifically just so that people 104 00:05:57.879 --> 00:06:00.680 are aware if you haven't heard me say this before 105 00:06:01.240 --> 00:06:04.319 the title of the book series obviously has several different 106 00:06:04.360 --> 00:06:06.759 layers of meeting. There's obviously a bit of a tongue 107 00:06:06.759 --> 00:06:09.480 in cheek kind of joke about the old you Don't 108 00:06:09.480 --> 00:06:12.319 Know Jack trivia game and some other things like that, 109 00:06:13.839 --> 00:06:17.000 But it was never intended to be an insulting name 110 00:06:17.079 --> 00:06:19.360 the way many people took it. It was actually intended 111 00:06:19.360 --> 00:06:24.839 to be a challenge to approach JavaScript with a more 112 00:06:24.920 --> 00:06:28.319 open mind and a more active I'm going to always 113 00:06:28.319 --> 00:06:30.360 be learning kind of a thing, which is why the 114 00:06:30.399 --> 00:06:32.680 second edition added the word yet to it, you don't 115 00:06:32.680 --> 00:06:35.519 know JS yet, because I wanted to make it even 116 00:06:35.600 --> 00:06:38.639 more clear that the point of this was actually to 117 00:06:38.759 --> 00:06:41.680 kind of be hopeful and to spur people to learn 118 00:06:41.720 --> 00:06:42.959 the language more deeply. 119 00:06:43.360 --> 00:06:46.639 Yeah. I I totally understood it when it came out 120 00:06:46.680 --> 00:06:49.600 because that that I think they just transitioned that to 121 00:06:49.639 --> 00:06:51.839 a mobile slash TV game where you could scan a 122 00:06:51.920 --> 00:06:55.079 QR code or something. So I totally understood it. But 123 00:06:55.120 --> 00:06:59.000 I could also see as the you know, Twitter sphere 124 00:06:59.040 --> 00:07:03.519 has boomed, a lot of the idioms, the English idioms 125 00:07:03.519 --> 00:07:06.040 have gone awry, you know that things have opened up 126 00:07:06.040 --> 00:07:09.319 a lot more so I okay, all right, Yeah. 127 00:07:09.319 --> 00:07:13.199 And then it was a response to again two thousand 128 00:07:13.199 --> 00:07:16.160 and eight and two thousand and nine, this Cambrian explosion 129 00:07:16.160 --> 00:07:19.839 of JavaScript around libraries. Not a lot of people wanted 130 00:07:19.839 --> 00:07:23.319 to learn JavaScript the language. Everybody wanted somebody's library to 131 00:07:23.360 --> 00:07:26.399 do it for them. It sounds a lot like today, actually, 132 00:07:26.920 --> 00:07:29.759 But what we had at the time was the JavaScript 133 00:07:29.800 --> 00:07:34.439 the Good Parts book, and that book essentially said, hey, 134 00:07:34.560 --> 00:07:38.120 I Doug Crockford have surveyed the whole JavaScript language and 135 00:07:38.199 --> 00:07:40.439 I've figured out that most of it sucks, but here's 136 00:07:40.480 --> 00:07:43.600 this tiny little subset that's really good, and you should 137 00:07:43.680 --> 00:07:47.120 learn that. And I really wrote my book series and 138 00:07:47.160 --> 00:07:49.839 then the subsequent courses and everything else I've done since 139 00:07:50.439 --> 00:07:56.199 as a response to that book set to say I 140 00:07:56.240 --> 00:07:59.519 don't think you should learn only a small subset that 141 00:07:59.600 --> 00:08:03.639 one I opinionatedly, you know, put a linter for I 142 00:08:03.680 --> 00:08:06.040 think you should learn all of the parts of javas. 143 00:08:06.199 --> 00:08:09.199 That's it's really unfortunate that you're so wrong there, But 144 00:08:09.439 --> 00:08:10.839 I guess we all have our opinions. 145 00:08:13.240 --> 00:08:15.600 Say, man, I've been I've been wronged a lot longer 146 00:08:15.639 --> 00:08:17.439 than you were in the industry. I've been around a 147 00:08:17.480 --> 00:08:19.519 long time, so I'm all right with that. 148 00:08:20.639 --> 00:08:25.399 Yeah, uh okay. So one of the things that we 149 00:08:25.519 --> 00:08:29.279 have you on for today was I saw some tweet 150 00:08:29.360 --> 00:08:32.039 that caught my eye about some local first stuff and 151 00:08:32.080 --> 00:08:36.879 then later some pass key stuff, and so let's just 152 00:08:37.720 --> 00:08:42.159 transition over into talking about that and what like what. 153 00:08:42.639 --> 00:08:44.960 And it seems it seems really timely. I think when 154 00:08:44.960 --> 00:08:46.759 I first saw the tweet, between the time I saw 155 00:08:46.759 --> 00:08:49.000 the tweet and we got you scheduled, like it was, 156 00:08:49.080 --> 00:08:52.240 it was something that was you know, in the nicheness 157 00:08:52.399 --> 00:08:55.519 of its hype cycle, and now with all these with 158 00:08:56.000 --> 00:08:58.879 DHH making a stir, I think that some of this 159 00:08:59.080 --> 00:09:03.279 is actually maybe Local first itself is not on the 160 00:09:03.399 --> 00:09:05.720 rise yet, but I think that it's going to lead 161 00:09:05.759 --> 00:09:08.279 to being on the rises. People are talking about performance 162 00:09:08.320 --> 00:09:13.600 and five dollars a month BPSS and whatnot, So yeah, 163 00:09:13.759 --> 00:09:14.080 it is. 164 00:09:14.240 --> 00:09:19.399 Yeah, what I I can kind of set the scene 165 00:09:19.480 --> 00:09:24.679 for everyone around local first. A small little consulting company 166 00:09:24.759 --> 00:09:27.039 named Ink and Switch back in I think either twenty 167 00:09:27.080 --> 00:09:29.799 eighteen or twenty nineteen, they coined the term local first 168 00:09:30.279 --> 00:09:32.480 and they put out this little manifest. Though it's easy 169 00:09:32.480 --> 00:09:36.200 to google for the seven principles of local first development, 170 00:09:36.559 --> 00:09:38.080 I'm not going to go through all of those. You 171 00:09:38.120 --> 00:09:41.039 can read them yourself if you're interested, but I will 172 00:09:41.080 --> 00:09:44.360 kind of summarize the one big point of local first, 173 00:09:44.799 --> 00:09:46.840 and we'll try to distinguish that because there's a lot 174 00:09:46.840 --> 00:09:48.799 of other things that people think it is or isn't. 175 00:09:49.360 --> 00:09:53.039 But the main point of local first was to kind 176 00:09:53.080 --> 00:09:57.519 of tackle head on this very clear trend that has 177 00:09:57.639 --> 00:10:00.480 moved nearly the entire web and in fact most of 178 00:10:00.519 --> 00:10:07.080 software around it, towards a cloud centric model. And the 179 00:10:07.720 --> 00:10:10.200 tackling trying to go out this head first is to 180 00:10:10.240 --> 00:10:13.960 say that one of the big problems with a cloud 181 00:10:14.039 --> 00:10:19.600 centric model for architecture is that you make that cloud required, 182 00:10:19.879 --> 00:10:24.360 and the cloud in this very big amorphos sense, is 183 00:10:24.399 --> 00:10:29.759 not nearly as ubiquitously guaranteed for every user as we 184 00:10:29.840 --> 00:10:33.039 might like to believe. There are a variety of reasons 185 00:10:33.120 --> 00:10:37.279 why my version of an app that's on my device 186 00:10:37.519 --> 00:10:39.440 and the thing that it needs to talk to up 187 00:10:39.440 --> 00:10:42.240 in the cloud might not be able to talk. One, 188 00:10:42.440 --> 00:10:47.840 I might have spotty or no internet. Two, there could 189 00:10:47.879 --> 00:10:50.879 be some sort of large Internet wide or you know, 190 00:10:51.000 --> 00:10:56.360 service wide outage in a cloud. Routers, dns. We see 191 00:10:56.360 --> 00:11:00.720 those things. Yeah, we see these things happen, and I 192 00:11:00.720 --> 00:11:06.480 think I personally resonate with There's actually probably almost half 193 00:11:06.559 --> 00:11:08.960 of the Internet's users, at least a third to a 194 00:11:09.039 --> 00:11:11.960 half of the Internet's users, live in parts of the 195 00:11:11.960 --> 00:11:16.399 world where both power and internet are not guaranteed unlimited assets. 196 00:11:16.879 --> 00:11:20.799 These are resources that are quite constrained, they're metered, they 197 00:11:20.840 --> 00:11:26.559 cost a lot, and they basically can't afford in one 198 00:11:26.600 --> 00:11:30.799 way or another to be constantly cloud connected and constantly 199 00:11:30.840 --> 00:11:33.600 sending all of the data back and forth. So what 200 00:11:33.720 --> 00:11:36.639 Local First did was it came along and said, the 201 00:11:37.279 --> 00:11:40.759 way to start tackling this one one peg of this 202 00:11:41.080 --> 00:11:45.879 is to put data. The source of authority for data 203 00:11:46.240 --> 00:11:50.320 should be on a user's device. And by data, we 204 00:11:50.320 --> 00:11:53.279 were specifically talking about the data that is relevant to 205 00:11:53.679 --> 00:11:57.080 or matters to that user. We're not saying that, you know, 206 00:11:57.200 --> 00:12:00.639 all trillion gigabytes of Amazon's database needs to be on 207 00:12:00.679 --> 00:12:04.559 everybody's phone, but the parts of that that they need 208 00:12:05.000 --> 00:12:07.679 should be on their device. And most importantly, I would 209 00:12:07.679 --> 00:12:10.480 extend that to say, the stuff that I create, or 210 00:12:10.519 --> 00:12:13.320 the stuff that is created about me, that's the stuff 211 00:12:13.320 --> 00:12:16.000 that's relevant to me, and that stuff, the source of 212 00:12:16.039 --> 00:12:19.039 authority for that data should be on the user's device. 213 00:12:19.440 --> 00:12:25.120 That does not foreclose having cloud servers and having synchronization 214 00:12:25.240 --> 00:12:28.240 and all of that, but it shifts the whole mindset 215 00:12:28.360 --> 00:12:31.639 to we start with the user's device and we build up, 216 00:12:31.679 --> 00:12:34.960 we progressively enhance from there, rather than starting with the 217 00:12:35.000 --> 00:12:37.840 assumption that everything is cloud based and if you don't 218 00:12:37.879 --> 00:12:40.600 have connection to the cloud, you're dead in the water. 219 00:12:41.399 --> 00:12:44.240 Yeah. I'll give you a little more different example than that. 220 00:12:44.559 --> 00:12:48.200 I did some work for a form Erner platform called 221 00:12:48.200 --> 00:12:49.960 form I own number of years ago, and I've had 222 00:12:49.960 --> 00:12:52.440 the founder on here a couple of times, and one 223 00:12:52.440 --> 00:12:55.519 of the use cases he gives for local first isn't 224 00:12:55.519 --> 00:13:01.519 necessarily you know, speed or bandwidth available ability, and their 225 00:13:01.559 --> 00:13:04.879 platform had ability built in where you could do everything 226 00:13:04.919 --> 00:13:07.320 locally on your device and then when you connect to 227 00:13:07.360 --> 00:13:10.000 a server and sync up. And the example that Travis 228 00:13:10.000 --> 00:13:14.600 gave was a scuba diving company who would be out, 229 00:13:14.759 --> 00:13:16.679 you know, they'd be out on a boat out in 230 00:13:16.720 --> 00:13:18.879 the water obviously where you scuba dive, unless you're in 231 00:13:18.919 --> 00:13:21.759 a pool, and you know, you want to be able 232 00:13:21.759 --> 00:13:24.480 to collect all your customers information and so on and 233 00:13:25.200 --> 00:13:26.720 get it in there, and then when you get back 234 00:13:26.720 --> 00:13:30.480 to shore or back within Wi Fi reach or sell 235 00:13:30.519 --> 00:13:33.200 reach or whatever your technology is, then you can sync 236 00:13:33.279 --> 00:13:37.919 up with your server and get everything simpty sync up 237 00:13:37.919 --> 00:13:42.440 that way. So just another scenario where local firsts would 238 00:13:42.440 --> 00:13:43.440 definitely come into play. 239 00:13:44.120 --> 00:13:49.519 Yeah, definitely, the the realities of the world being experienced, 240 00:13:49.519 --> 00:13:53.360 the computing world being experienced in way more places than 241 00:13:53.399 --> 00:13:56.600 in a fixed office space with a fat Internet pipe 242 00:13:56.639 --> 00:14:00.000 that you're connected to the world is increasingly more mobile. 243 00:14:00.080 --> 00:14:04.080 That's not a you know, unusual thing to assert, but 244 00:14:04.120 --> 00:14:09.000 it's increasingly more mobile and increasingly less online. Actually, there's 245 00:14:09.120 --> 00:14:11.799 way more of the world that's happening in that spotty 246 00:14:11.840 --> 00:14:15.720 part of the Internet. And it's been said before that 247 00:14:16.320 --> 00:14:21.039 spotty or intermittent Internet is actually a much more challenging problem, 248 00:14:21.240 --> 00:14:24.559 both for developers and users than no Internet at all. 249 00:14:25.919 --> 00:14:31.120 And so I think we definitely we need to embrace 250 00:14:31.240 --> 00:14:35.159 the idea that for the Web to truly reach all 251 00:14:35.440 --> 00:14:39.559 eight billion people in the world, we have to think 252 00:14:39.600 --> 00:14:42.960 about the residency of data being much closer to them. 253 00:14:43.320 --> 00:14:45.879 We did have, you know, a brief few years where 254 00:14:45.919 --> 00:14:48.759 we said, well, if we just put more servers in 255 00:14:48.840 --> 00:14:52.240 more places, and if we hang giant balloons up in 256 00:14:52.279 --> 00:14:55.200 the air, and if we have satellite internet like, we'll 257 00:14:55.279 --> 00:14:57.919 just we'll blanket the world with Internet and that'll be 258 00:14:57.919 --> 00:15:02.559 the fix. That's the you know, techno billionaire's perspective on things. 259 00:15:02.600 --> 00:15:05.240 But I think builders of the web need to embrace 260 00:15:05.919 --> 00:15:09.120 this local first principle of making the server, making the 261 00:15:09.159 --> 00:15:13.720 cloud optional as opposed to required. And it does bring 262 00:15:13.799 --> 00:15:16.399 in a whole It solves a bunch of things, but 263 00:15:16.440 --> 00:15:18.399 it brings in a different set of problems, and you 264 00:15:18.480 --> 00:15:24.240 mentioned those, the synchronization questions and the whole concept of 265 00:15:24.399 --> 00:15:28.879 synchronization data structures like CRDT. You know that that's now 266 00:15:28.919 --> 00:15:31.559 a big thing of discussion where that used to just 267 00:15:31.559 --> 00:15:34.759 be a niche academic topic, but we have got dozens 268 00:15:34.759 --> 00:15:38.799 of companies that are trying to build commercial solutions around 269 00:15:40.080 --> 00:15:44.919 sophisticated synchronization mechanisms. When you have data on a device 270 00:15:44.960 --> 00:15:48.519 that needs to synchronize with other devices and with cloud servers. 271 00:15:49.639 --> 00:15:54.519 So how much does that does the local first approach? 272 00:15:55.279 --> 00:15:58.080 I guess it really doesn't. Maybe it does. Exascer debate 273 00:15:58.080 --> 00:16:01.440 a little bit. Is the performance issue, So you know, 274 00:16:01.519 --> 00:16:06.679 obviously the issue with JavaScript versus a server side language 275 00:16:06.679 --> 00:16:08.759 is that since it's running the browser, that code has 276 00:16:08.799 --> 00:16:10.840 to be all downloaded to your browser. And so there's 277 00:16:11.480 --> 00:16:15.840 the ongoing issues that developers face with trying to make 278 00:16:15.960 --> 00:16:20.159 their code, whether it's using a framework or not, as 279 00:16:20.440 --> 00:16:23.559 minimal as possible. So that for your third world countries, 280 00:16:23.600 --> 00:16:27.000 for your places where there's a poor connection, maybe only 281 00:16:27.000 --> 00:16:29.679 three G instead of five G, et cetera, you've got 282 00:16:29.720 --> 00:16:30.559 less to download. 283 00:16:30.639 --> 00:16:31.519 So now. 284 00:16:32.879 --> 00:16:37.240 You're adding a bunch more data to what you're downloading 285 00:16:37.240 --> 00:16:41.519 because you're stashing it locally. So that's going to make 286 00:16:41.720 --> 00:16:45.240 I guess that would make your on device performance when 287 00:16:45.279 --> 00:16:47.519 it's actually using the code faster because you're not having 288 00:16:47.559 --> 00:16:51.200 to make your API calls to your server. But at 289 00:16:51.240 --> 00:16:52.879 the same time then you've got to sync all that up. 290 00:16:52.919 --> 00:16:55.919 So it seems, as I ramble on here, I guess 291 00:16:55.919 --> 00:16:58.200 you could say it's sort of minimizing that and making 292 00:16:58.240 --> 00:16:59.879 it less of an issue because you don't have all 293 00:16:59.919 --> 00:17:02.600 the data flowing back and forth as much as you 294 00:17:02.679 --> 00:17:05.599 do with JavaScript. Or is that a join issue? 295 00:17:06.079 --> 00:17:10.640 Generally speaking, I think a local first app reduces the 296 00:17:10.720 --> 00:17:14.279 amount of data in totality that needs to go back 297 00:17:14.279 --> 00:17:17.519 and forth across the wire, but it may very well 298 00:17:17.599 --> 00:17:22.880 in fact frontload more of that data transfer, especially if 299 00:17:22.920 --> 00:17:26.519 you're synchronizing an existing user history onto a new device. 300 00:17:26.960 --> 00:17:29.680 There definitely might be more download, not only download of 301 00:17:29.720 --> 00:17:33.000 the application itself. Because that's another thing, like if I 302 00:17:33.039 --> 00:17:36.200 have the app, I really should have a continuing to 303 00:17:36.319 --> 00:17:39.759 work app even if I have no internet, right That's 304 00:17:39.920 --> 00:17:43.119 that's the offline first part of this, which is only 305 00:17:43.160 --> 00:17:45.400 part of the umbrella. But I should have an app 306 00:17:45.400 --> 00:17:48.680 that continues to function even if the internet connection to 307 00:17:48.720 --> 00:17:51.880 the web server is down or you know, non existent 308 00:17:51.880 --> 00:17:53.720 because they went out of business. You know, I should 309 00:17:53.720 --> 00:17:56.440 be able to keep using that. So there very well 310 00:17:56.519 --> 00:18:01.960 might be a trade off here where the initial experience 311 00:18:02.640 --> 00:18:05.799 is a little bit more like an app install experience 312 00:18:05.920 --> 00:18:09.519 that is not instant on. And I personally think that 313 00:18:09.559 --> 00:18:11.920 would be better for the web to go back to 314 00:18:13.039 --> 00:18:17.920 not trying to fake the instant on experience and instead 315 00:18:18.000 --> 00:18:22.839 embrace the idea that I'm not websites, but if I'm 316 00:18:22.880 --> 00:18:26.000 choosing to install an app, it really should be a 317 00:18:26.039 --> 00:18:29.559 thing that I'm willing to wait three, five, ten, twenty 318 00:18:29.559 --> 00:18:32.359 seconds whatever it takes to get the whole app and 319 00:18:32.400 --> 00:18:36.359 whatever data I need synchronized onto my device. You know, 320 00:18:37.359 --> 00:18:39.759 you could take a page out of Google's book, Google 321 00:18:39.839 --> 00:18:43.759 Crumb's book and put little you know, dinosaur jumping games 322 00:18:43.799 --> 00:18:45.480 in there while you're waiting. I mean, we can go 323 00:18:45.559 --> 00:18:49.519 back to the days where we had you know, better 324 00:18:49.759 --> 00:18:53.359 that better experiences than just those dumb spinners that can 325 00:18:53.440 --> 00:18:56.599 engage people and let them do things. But another point 326 00:18:56.640 --> 00:18:59.640 to this is that a local first experience should work 327 00:18:59.680 --> 00:19:01.240 even if if you don't have even if you don't 328 00:19:01.319 --> 00:19:05.839 yet have your data. So honestly, maybe having an instant 329 00:19:05.839 --> 00:19:08.839 on experience as soon as you get the code, you 330 00:19:08.880 --> 00:19:11.319 should be able to start creating data, even if all 331 00:19:11.400 --> 00:19:13.240 of the data that it's going to merge with has 332 00:19:13.240 --> 00:19:15.640 not yet downloaded. So I think there's a lot of 333 00:19:15.640 --> 00:19:18.880 complexity in terms of those trade offs, but it is 334 00:19:18.920 --> 00:19:24.200 being intentional about saying that users should be able once 335 00:19:24.240 --> 00:19:26.160 they have a piece of data and they have an 336 00:19:26.160 --> 00:19:28.640 app to work on that data, they should be able 337 00:19:28.640 --> 00:19:33.000 to continue to do what that code and data enabled 338 00:19:33.480 --> 00:19:37.400 no matter what from here on forward. My best use 339 00:19:37.440 --> 00:19:41.359 case to describe this, it's just one personally, but when 340 00:19:41.359 --> 00:19:45.319 we think about bank account apps, generally people think about 341 00:19:45.400 --> 00:19:48.000 bank accounts. Is the only use case is I want 342 00:19:48.000 --> 00:19:52.680 to know right now, instantaneously what is my current available 343 00:19:52.720 --> 00:19:56.599 balance in my bank account. But there's a tremendous amount 344 00:19:56.640 --> 00:19:58.880 of information in my bank account that has nothing to 345 00:19:58.920 --> 00:20:01.400 do with what the latest thing that I bought at 346 00:20:01.440 --> 00:20:06.240 the grocery stores. And that data is on my device. 347 00:20:06.359 --> 00:20:08.240 I can see it, I can interact with it, I 348 00:20:08.240 --> 00:20:11.759 can search it. Except when my internet goes away, Now 349 00:20:11.920 --> 00:20:14.400 all of that's completely gone. I can't go back and 350 00:20:14.440 --> 00:20:16.880 look at what I bought at the grocery store last week. 351 00:20:17.200 --> 00:20:20.000 Because they make the assumption when they build the banking 352 00:20:20.039 --> 00:20:22.279 app that the only way that I want to use 353 00:20:22.319 --> 00:20:25.160 this app is to see current incident. If they can't 354 00:20:25.200 --> 00:20:28.519 give me that, they don't give me anything, well, that's bonkers. 355 00:20:28.559 --> 00:20:32.000 I think that's my data, very clearly my data, and 356 00:20:32.039 --> 00:20:34.720 I have an app that's able to render and work 357 00:20:34.759 --> 00:20:37.799 with that data. So a local first app would say 358 00:20:38.240 --> 00:20:40.559 you can continue to look at all of your previous 359 00:20:40.599 --> 00:20:44.440 bank account transactions and read them and search them and 360 00:20:44.559 --> 00:20:47.039 categorize them and do whatever you want even if you 361 00:20:47.039 --> 00:20:49.519 don't have an Internet connection to look at your live 362 00:20:49.599 --> 00:20:53.039 account balance. That's I think what we're missing is that 363 00:20:53.039 --> 00:20:56.480 we just assume that live everything is the only use 364 00:20:56.519 --> 00:20:59.119 case that matters, when actually there's a ton of use 365 00:20:59.119 --> 00:21:02.400 cases that don't require that live connection. 366 00:21:02.599 --> 00:21:04.160 All right, So I'm going to push back on this, 367 00:21:05.240 --> 00:21:10.599 right and I actually like morally, morally I agree with you, 368 00:21:11.400 --> 00:21:14.319 but practically we have to look at what, you know, 369 00:21:14.359 --> 00:21:20.880 what the reality of the situation is. So most most 370 00:21:20.920 --> 00:21:24.839 web businesses are not profitable businesses. They are growth businesses. 371 00:21:24.880 --> 00:21:27.759 The way that people make money is that for the 372 00:21:27.759 --> 00:21:30.880 first ten years or so, they just hand off the 373 00:21:30.880 --> 00:21:33.599 business from one investor to another as they go through 374 00:21:34.160 --> 00:21:37.480 seed round this A B C, D E, F G 375 00:21:37.680 --> 00:21:40.000 H I J K lemono, you know, and then and 376 00:21:40.039 --> 00:21:45.000 then after thirteen billion dollars, maybe maybe they become profitable, 377 00:21:45.000 --> 00:21:50.880 but most likely they just they just flyn So why why, 378 00:21:51.119 --> 00:21:55.119 like what what's why would anybody care about, you know, 379 00:21:55.160 --> 00:21:57.319 the people in these spotty internet areas because you know, 380 00:21:57.400 --> 00:21:59.319 they have no money to pay for the product. So 381 00:21:59.400 --> 00:22:03.599 in terms of growth users, like, yeah, I guess you could. 382 00:22:03.640 --> 00:22:05.640 You could make an argument for say, yeah, there's a 383 00:22:05.680 --> 00:22:07.599 lot of people out there with spotty internet. You could 384 00:22:07.680 --> 00:22:10.839 get them onboarded as users if you're the only one 385 00:22:11.039 --> 00:22:13.599 that's actually trying to onboard these users, But then you 386 00:22:13.640 --> 00:22:16.240 can never count them in a metric as like potential customers. 387 00:22:17.079 --> 00:22:20.119 So yeah, I totally disagree with that. I think that's 388 00:22:20.160 --> 00:22:24.119 a complete false dichotomy that people with spotty internet have 389 00:22:24.200 --> 00:22:28.119 no money. There's lots of lots of use cases that 390 00:22:28.160 --> 00:22:31.559 we can imagine you were referring. You know, we've talked 391 00:22:31.720 --> 00:22:34.880 a little while ago about the diving company that's out 392 00:22:35.240 --> 00:22:37.880 that's that's a high end hobby that people are spending 393 00:22:37.880 --> 00:22:39.759 a whole lot of money on and they just happen 394 00:22:39.839 --> 00:22:41.519 to be in an area where they don't have Internet 395 00:22:41.599 --> 00:22:45.240 at that moment where they're collecting and experiencing the data. 396 00:22:45.640 --> 00:22:50.079 There's use cases around uh, construction and survey companies that 397 00:22:50.119 --> 00:22:52.000 are out in the field and they're nowhere near where 398 00:22:52.039 --> 00:22:55.720 Internet is. They're collecting tons of really useful and very 399 00:22:55.759 --> 00:22:58.799 expensive data that they need to sell to other people 400 00:22:58.880 --> 00:23:01.559 or synchronize with their company. But you know, we don't 401 00:23:01.599 --> 00:23:05.119 even have to get into the big companies. There are tons, 402 00:23:06.000 --> 00:23:09.279 literally millions and millions of people in the world, tens 403 00:23:09.319 --> 00:23:11.400 of millions of people of the world who are a 404 00:23:11.480 --> 00:23:15.319 one man, one woman business, a one person business, uh. 405 00:23:15.440 --> 00:23:19.200 The fish farmer in somewhere rural. They may be collecting 406 00:23:19.759 --> 00:23:22.319 hundreds of thousands of dollars worth of product that they're 407 00:23:22.319 --> 00:23:25.200 going to take to market. They are very much somebody 408 00:23:25.200 --> 00:23:27.799 that you can monetize and treat as a customer. But 409 00:23:27.880 --> 00:23:30.079 when they're out there collecting all of those fish and 410 00:23:30.119 --> 00:23:32.519 they're not yet at the market with it, they're not 411 00:23:32.640 --> 00:23:36.519 somebody who has Internet, but they still absolutely have tons 412 00:23:36.559 --> 00:23:39.680 of potential and should be treated as a valuable customer. 413 00:23:39.839 --> 00:23:41.960 And that's not to even get into the larger moral 414 00:23:42.039 --> 00:23:45.359 question of we ought to treat everybody's access to the 415 00:23:45.400 --> 00:23:49.680 Internet as an important human right I believe, as opposed 416 00:23:49.720 --> 00:23:52.240 to only a right that comes if you're willing to 417 00:23:52.240 --> 00:23:52.720 pay for it. 418 00:23:53.160 --> 00:23:59.519 But I don't know that I think about a yeah, sorry, 419 00:24:00.039 --> 00:24:03.440 it's all right, go ahead. I was just saying, I 420 00:24:04.440 --> 00:24:08.400 disagree that it's a human right. It's something that's very modern. 421 00:24:08.440 --> 00:24:11.559 It's something that's only existed for literally decades out of 422 00:24:11.920 --> 00:24:13.920 thousands of years of human history. So to call it 423 00:24:13.960 --> 00:24:17.759 a human right is on a like that's that's a 424 00:24:17.759 --> 00:24:21.559 bridge too far from me. But I agree, like I 425 00:24:21.599 --> 00:24:24.119 would love a world that is like what you're saying. 426 00:24:24.240 --> 00:24:27.279 I get frustrated all the time. I mean, living here 427 00:24:27.279 --> 00:24:31.119 in Utah, things have gotten a lot better in the 428 00:24:31.160 --> 00:24:33.240 past ten years. But it used to be sometimes when 429 00:24:33.240 --> 00:24:35.799 I was going between cities because there's these little cities 430 00:24:35.880 --> 00:24:42.319 like Mapleton or Pleasant Grove is kind of booming, but 431 00:24:42.359 --> 00:24:44.400 they were really small, you know, and so I'd be 432 00:24:44.480 --> 00:24:49.680 going going between cities and not having phone, like really 433 00:24:49.680 --> 00:24:52.960 good phone reception back when I was in college. Now 434 00:24:53.160 --> 00:24:56.119 now it's you know, because of all the tech booms 435 00:24:56.160 --> 00:24:58.079 that have happened, like all the past years, are being 436 00:24:58.079 --> 00:25:00.160 brought up and turned into business parks. A lot them 437 00:25:00.200 --> 00:25:05.279 are just sitting there empty, but they're there nonetheless, and 438 00:25:05.279 --> 00:25:07.839 and yeah, so it's it's a it's a bit better. 439 00:25:07.880 --> 00:25:08.640 So I like that. 440 00:25:08.640 --> 00:25:13.240 Idea, but I just I think it's a hard sell 441 00:25:13.960 --> 00:25:17.680 to talk with someone and say, hey, if you're if 442 00:25:17.720 --> 00:25:20.839 you're actually a legitimate startup trying to be profitable, how 443 00:25:20.839 --> 00:25:22.519 are you going to spend all this extra time to 444 00:25:22.559 --> 00:25:25.880 do something that's not an industry standard. There is no 445 00:25:26.039 --> 00:25:28.440 playbook for it, which I guess maybe that's part of 446 00:25:28.440 --> 00:25:34.200 what you're trying to fix. And and these are one 447 00:25:34.240 --> 00:25:38.079 off experiences from you know, the one percent of your customers. 448 00:25:38.079 --> 00:25:41.400 And let's say that we agree these are actually going 449 00:25:41.440 --> 00:25:44.480 to be customers, not users. But you know they're the 450 00:25:44.480 --> 00:25:46.960 one percenters, or it's the one time they're out there, 451 00:25:47.440 --> 00:25:49.400 you know they don't have another option anywhere. They're really 452 00:25:49.400 --> 00:25:52.279 going to be that upset that, Okay, while they're skydiving, 453 00:25:52.319 --> 00:25:53.920 they can't use your app. I mean, maybe it's not 454 00:25:54.000 --> 00:25:55.759 safe to use the Apple skydiving. 455 00:25:56.599 --> 00:25:58.799 There's another angle that I think we should point out, 456 00:25:58.839 --> 00:26:06.920 which is there's play of justification to attract businesses to 457 00:26:07.160 --> 00:26:10.480 create apps in this way that really has nothing to 458 00:26:10.519 --> 00:26:13.319 do with whether they ever charge their user anything, right, 459 00:26:13.680 --> 00:26:15.519 there's tons of apps out there that never charge a 460 00:26:15.599 --> 00:26:17.799 penny to any of their customers. They're just selling their data. 461 00:26:17.839 --> 00:26:21.480 They're selling them advertising or whatever. And there's plenty of 462 00:26:21.480 --> 00:26:25.480 reasons why those companies can benefit from local first apps. 463 00:26:25.559 --> 00:26:29.640 One of the biggest reasons is that if you long 464 00:26:29.759 --> 00:26:33.880 term reduce the amount of churn of data going back 465 00:26:33.920 --> 00:26:37.880 and forth across the wire. In fact, potentially you might 466 00:26:37.960 --> 00:26:42.240 even completely eliminate the need for these big centralized stores 467 00:26:42.359 --> 00:26:45.599 of your data. You drastically reduce the footprint that you 468 00:26:45.680 --> 00:26:48.960 need in the cloud, perhaps even to zero, but certainly 469 00:26:49.000 --> 00:26:52.319 significantly less. Are there things that you'll still always do 470 00:26:52.400 --> 00:26:55.839 in the cloud. Yeah, you'll host giant video files and 471 00:26:55.920 --> 00:27:00.279 other CDN things. You'll do really complex compute out in 472 00:27:00.319 --> 00:27:03.480 the cloud with AI training. But there's a ton of 473 00:27:03.519 --> 00:27:06.759 the generalized CRUD stuff that we do out in the 474 00:27:06.759 --> 00:27:09.519 cloud right now because it seems easiest to do it there, 475 00:27:09.880 --> 00:27:12.480 and we pay tons of money to those cloud providers 476 00:27:12.480 --> 00:27:15.039 to do that. There's a lot of that that can 477 00:27:15.079 --> 00:27:18.960 actually be shifted to the user's devices. We see potential 478 00:27:19.000 --> 00:27:23.839 growth in peer to peer device communications through various different protocols, 479 00:27:23.880 --> 00:27:29.440 both web and native that can reduce the stress and 480 00:27:29.640 --> 00:27:32.240 the footprint that you need in the cloud. And like 481 00:27:32.279 --> 00:27:35.720 we were mentioning in the in the pre show, people 482 00:27:35.759 --> 00:27:39.000 like DHH you know, and the thirty seven signals folks, 483 00:27:39.039 --> 00:27:41.279 and the things that they're doing, they're not they're not 484 00:27:41.640 --> 00:27:43.920 bastions of those, you know, they're not leaders in the 485 00:27:43.920 --> 00:27:48.119 local first community per se. But what they are saying is, hey, 486 00:27:48.720 --> 00:27:51.359 is the cloud really required? Or can the cloud actually 487 00:27:51.359 --> 00:27:54.000 be optional? Are there other architectures there where we can 488 00:27:54.359 --> 00:27:57.319 move back down to You have an app, you own 489 00:27:57.359 --> 00:27:59.880 the app, you host the app, and you host your data. 490 00:28:00.119 --> 00:28:02.519 And I think that's going to lead to companies starting 491 00:28:02.559 --> 00:28:04.720 to ask those questions, Wait a minute, do I really 492 00:28:04.759 --> 00:28:07.839 need to pay hundreds or thousands or tens of thousands 493 00:28:07.920 --> 00:28:10.599 of dollars to a cloud provider when I could offload 494 00:28:11.160 --> 00:28:13.799 a lot, if not all, at least a lot of 495 00:28:13.839 --> 00:28:16.839 what I was doing and reduce the cost. I think 496 00:28:16.839 --> 00:28:20.799 there's a huge business benefit to embracing local first. And 497 00:28:20.839 --> 00:28:24.880 just like with any other movement, you said, true, it's early, 498 00:28:25.119 --> 00:28:28.039 it's nascent, there's not a lot of standard, but that 499 00:28:28.160 --> 00:28:32.200 offers huge upside potential for the companies that decide to 500 00:28:32.240 --> 00:28:34.799 be early movers in that space, and it's always been 501 00:28:34.839 --> 00:28:37.799 the case that early movers have had huge upside potential. Yes, 502 00:28:38.079 --> 00:28:40.480 huge risk, but huge upside potential. It comes with the. 503 00:28:41.519 --> 00:28:47.079 Okay, So one thing that I think is pretty well established, 504 00:28:47.279 --> 00:28:49.240 and I would love to be corrected on this, but 505 00:28:49.279 --> 00:28:52.000 I think it's pretty well established that state management is 506 00:28:52.160 --> 00:28:54.799 more difficult on the front end than it is on 507 00:28:54.839 --> 00:28:56.839 the back end. Like there's just that it's a higher 508 00:28:56.920 --> 00:29:00.759 level of abstraction. There's more thing that you're not in 509 00:29:00.799 --> 00:29:03.240 control of that can go wrong. State management on the 510 00:29:03.279 --> 00:29:07.200 front end is a nightmare. And React came in and promised, like, 511 00:29:07.480 --> 00:29:09.680 you don't have to worry about state management anymore because 512 00:29:09.680 --> 00:29:11.359 we're just gonna re render the whole page. And we've 513 00:29:11.359 --> 00:29:13.920 seen how that's gone. You know, it's not been like 514 00:29:14.000 --> 00:29:17.799 this shining star of Oh, state Management's not a problem anymore. 515 00:29:17.920 --> 00:29:20.599 It's been another game of hot potato where well, actually 516 00:29:20.640 --> 00:29:22.440 we do need state management, but it's going to live 517 00:29:22.440 --> 00:29:25.279 in this this component now, Actually it's gonna live in 518 00:29:25.279 --> 00:29:27.359 this library. Actually we're gonna put it back on the server. 519 00:29:27.480 --> 00:29:29.519 Actually we're gonna stream it down to the client. And 520 00:29:30.039 --> 00:29:33.039 you know, it seems like every six months to year 521 00:29:33.079 --> 00:29:36.160 and a half sixty eighteen months, React completely gets like 522 00:29:36.240 --> 00:29:39.680 a whole fundamental redesign, and then instead of calling it 523 00:29:39.680 --> 00:29:42.480 some other framework, they just call it React seventeen or 524 00:29:42.519 --> 00:29:45.440 eighteen years ye, right, which is just like one of 525 00:29:45.440 --> 00:29:47.559 the most that's like the best brand thing that has 526 00:29:47.599 --> 00:29:50.319 ever happened in the universe in terms of front end frameworks. 527 00:29:50.480 --> 00:29:54.640 Release a completely different framework that shares almost none of 528 00:29:54.640 --> 00:29:57.640 the principles of the previous one other than the syntax, 529 00:29:58.119 --> 00:29:59.240 and call it the same thing. 530 00:30:00.279 --> 00:30:06.799 But with that said, it's working companies that are behind React. 531 00:30:08.160 --> 00:30:12.720 How are people supposed to They can't even figure out 532 00:30:12.720 --> 00:30:14.920 what they're doing right now, right like, they can't even 533 00:30:14.960 --> 00:30:17.400 figure out the state management problems that they have right now? 534 00:30:18.039 --> 00:30:20.240 How are they going to handle all the additional state 535 00:30:20.319 --> 00:30:24.119 management problems of local first? And maybe there's a snuck 536 00:30:24.160 --> 00:30:27.599 premise there that needs to be disbanded. But well, yeah, 537 00:30:27.640 --> 00:30:30.160 so here's what I would say. First of all, a 538 00:30:30.240 --> 00:30:33.400 tremendous amount, not all, but a tremendous amount of the 539 00:30:33.559 --> 00:30:38.640 current complexity in modern front ends is directly related to 540 00:30:38.759 --> 00:30:45.359 the choice that we made to centralize architecture on a 541 00:30:45.640 --> 00:30:50.519 cloud first model and then also try to tell everybody, 542 00:30:50.839 --> 00:30:52.920 even though all of that data and all of that 543 00:30:53.000 --> 00:30:55.799 code lives not on your device but out in the 544 00:30:56.279 --> 00:30:58.799 you know, in the ether somewhere, we're going to make 545 00:30:58.839 --> 00:31:01.720 it look as if it's as close to instant on 546 00:31:02.079 --> 00:31:06.279 as possible. Those two things have conspired together to create 547 00:31:06.920 --> 00:31:10.920 an entire, multi billion dollar industry of web performance optimization 548 00:31:11.519 --> 00:31:16.039 and literally dozens and dozens of these complexities that you're 549 00:31:16.079 --> 00:31:20.359 talking about, most recently the shift back to server side 550 00:31:20.400 --> 00:31:24.519 components and server side blah blah blah whatever. Most of 551 00:31:24.519 --> 00:31:31.039 that I think is chosen complexity, not necessary complexity, but 552 00:31:31.119 --> 00:31:33.839 it's been a choice that we've been continuing down that route. 553 00:31:34.240 --> 00:31:37.799 And Local First says, actually much of that, not all 554 00:31:37.839 --> 00:31:41.079 of it, but much of that is not actually necessary. 555 00:31:41.559 --> 00:31:44.920 If the code is resident on somebody's device, If we 556 00:31:45.000 --> 00:31:48.519 build an experience where it's very durable and very stable 557 00:31:48.960 --> 00:31:52.480 instead of it's constantly changing every five minutes on every page, 558 00:31:52.519 --> 00:31:56.279 load a durable and stable experience, and we put the 559 00:31:56.359 --> 00:31:59.519 data where somebody needs it to reduce the amount of 560 00:31:59.680 --> 00:32:04.079 the need of all of that back and forth. What 561 00:32:04.079 --> 00:32:06.240 what you're basically doing is you're saying all of the 562 00:32:06.279 --> 00:32:11.000 complexity that we have around eventual consistency, which is I 563 00:32:11.039 --> 00:32:14.880 think one of the worst terms we ever invented as 564 00:32:14.920 --> 00:32:20.920 technologists because there's absolutely no consistency anywhere. It's a total farce. 565 00:32:21.359 --> 00:32:23.119 It's a never consistency model. 566 00:32:23.200 --> 00:32:25.480 If you think about what is the source of authority 567 00:32:25.480 --> 00:32:29.920 for Amazon's e commerce database, there are literally hundreds of 568 00:32:29.960 --> 00:32:33.640 thousands of sources of authority for Amazon's database. There is 569 00:32:33.680 --> 00:32:36.720 no one snapshot that says this is the true source 570 00:32:36.759 --> 00:32:40.319 of truth for what's going on with Amazon as a business. 571 00:32:40.599 --> 00:32:44.720 So what we're saying is they're already have the built 572 00:32:44.759 --> 00:32:51.160 in complexity of managing effectively with crdts, very bespoke internal 573 00:32:51.240 --> 00:32:54.200 to their business logic and their cloud back ends. They're 574 00:32:54.240 --> 00:32:57.680 already having to deal with massive amounts of complexity of 575 00:32:57.720 --> 00:33:00.240 all of that state management. And I think I think 576 00:33:01.279 --> 00:33:04.599 that's the hidden complexity that you weren't talking about. We 577 00:33:04.680 --> 00:33:07.559 have all this front end complexity, but the balance of 578 00:33:07.599 --> 00:33:11.000 that is all of that hidden complexity in our back ends, 579 00:33:11.279 --> 00:33:14.599 and we have tons of giant frameworks and messaging systems 580 00:33:14.599 --> 00:33:16.839 and all that that try to manage all that stuff 581 00:33:16.839 --> 00:33:20.759 of database architecture complexity with replication and all of that, 582 00:33:21.079 --> 00:33:24.799 and basically local firstus saying we could eliminate most of 583 00:33:24.839 --> 00:33:28.200 that if we stopped trying to pretend that the only 584 00:33:28.240 --> 00:33:31.079 way for this experience to happen is to require a 585 00:33:31.160 --> 00:33:34.000 round trip. We can have round trips when we need them, 586 00:33:34.400 --> 00:33:36.640 but we don't have to require that to gate the 587 00:33:36.759 --> 00:33:40.200 user's experience. We can install an experience for them. We 588 00:33:40.279 --> 00:33:43.519 can put data there that they need most frequently, and 589 00:33:43.559 --> 00:33:46.000 we can put the logic there that makes that data 590 00:33:46.119 --> 00:33:49.799 do what that user expects and stores whatever they've changed, 591 00:33:50.160 --> 00:33:53.319 and then in the background synchronizes that to wherever it needs, 592 00:33:53.359 --> 00:33:56.400 whether that's peer to peer to another device, or whether 593 00:33:56.440 --> 00:34:00.240 it's through a traditional sending some synchronized data back up 594 00:34:00.279 --> 00:34:02.319 to a cloud server, which is what many of them 595 00:34:02.319 --> 00:34:05.519 are doing. But we're just simply saying that user does 596 00:34:05.559 --> 00:34:09.519 not have any anywhere near that amount of complexity. So 597 00:34:09.599 --> 00:34:14.199 this is a very different way of building applications. Does 598 00:34:14.239 --> 00:34:17.199 it have its own complexity, of course it does. Nobody's 599 00:34:17.199 --> 00:34:19.679 saying this is the silver bullet and it's just two 600 00:34:19.760 --> 00:34:22.320 lines of code and it's all done. But I actually 601 00:34:22.400 --> 00:34:26.199 think if we were if we went forward five years 602 00:34:26.199 --> 00:34:28.960 and then we're to take a really good local first 603 00:34:29.000 --> 00:34:31.400 app and there are several out there, linear and some 604 00:34:31.480 --> 00:34:33.239 of those others. If we were to take their code 605 00:34:33.280 --> 00:34:36.960 bases and compare them to the equivalent cloud centric code bases, 606 00:34:37.079 --> 00:34:41.519 I really do, genuinely believe that the overall complexity, the 607 00:34:41.559 --> 00:34:45.320 overall number of moving parts goes down when you embrace 608 00:34:45.400 --> 00:34:46.159 these principles. 609 00:34:46.519 --> 00:34:52.119 Okay, I I would love to agree with you. I'd 610 00:34:52.199 --> 00:34:55.760 need to see how, because again I'm just hung up 611 00:34:55.760 --> 00:35:02.440 on Fundamentally, caching on the front end is front end 612 00:35:02.440 --> 00:35:04.679 people are asked to do too much. They're expected to 613 00:35:04.679 --> 00:35:11.000 do CSS, which is essentially a design mindset, or they're 614 00:35:11.039 --> 00:35:14.320 copying design. They're either creating or copying design in CSS. 615 00:35:15.280 --> 00:35:18.679 They're expected to understand the DOM which is very engineer 616 00:35:18.760 --> 00:35:24.280 oriented data internals to event loops in a browser and 617 00:35:24.599 --> 00:35:29.519 rendering processes. And they're expected to also be a programmer 618 00:35:29.599 --> 00:35:36.039 in JavaScript, where they need to have developed the acumen 619 00:35:36.159 --> 00:35:42.880 for writing programs. And these three things are literally they're 620 00:35:42.920 --> 00:35:45.880 all opposed to each other. CSS has nothing to do 621 00:35:45.920 --> 00:35:50.519 with programming being Honing your skills at CSS means that 622 00:35:50.559 --> 00:35:52.760 you have to give up honing your skills somewhere else, 623 00:35:52.840 --> 00:35:57.199 like in programming JavaScript. Honing your skills and your understanding 624 00:35:57.199 --> 00:36:04.159 of browser mechanics and eventful paints and uh, the dom 625 00:36:04.239 --> 00:36:08.320 APIs you know all that C plus plus context switching. 626 00:36:08.800 --> 00:36:12.199 You know that that's that's systems level programming and and 627 00:36:12.199 --> 00:36:16.920 and that's very different from application level programming. And so, 628 00:36:17.599 --> 00:36:20.320 you know, like front end developers are just being asked 629 00:36:20.360 --> 00:36:22.239 to do too much, and I think that's why they're failing. 630 00:36:23.360 --> 00:36:27.320 And asking them to then also be good at data 631 00:36:27.360 --> 00:36:32.920 transformations and etl. I just I think it's too much 632 00:36:33.000 --> 00:36:35.719 because they're already burdened. Either we need to split up 633 00:36:35.760 --> 00:36:38.599 and say you're a front end programmer and you're a 634 00:36:38.599 --> 00:36:41.079 front end designer, or your front end programmer and you're 635 00:36:41.119 --> 00:36:47.599 a front end uh layout manager or you know whatever, 636 00:36:48.159 --> 00:36:51.039 so that they can actually focus and become good at 637 00:36:51.079 --> 00:36:55.000 those areas of skill and really be excellent, or or 638 00:36:55.039 --> 00:36:57.400 we have to somehow provide something to reduce the complexity, 639 00:36:57.400 --> 00:36:59.000 which again I think is the allure of React, because 640 00:36:59.039 --> 00:37:00.760 it's kind of saying, Okay, we're going to take care 641 00:37:00.760 --> 00:37:02.360 of the CSS, and we're going to take care of 642 00:37:02.400 --> 00:37:05.280 the the the DOM life cycle, and we're going to 643 00:37:05.320 --> 00:37:08.360 take care of obscuring away that you know, the JavaScript 644 00:37:08.400 --> 00:37:12.039 for this this new the the r S R R 645 00:37:12.119 --> 00:37:16.320 S X now what jas X language, you know, So 646 00:37:17.400 --> 00:37:20.920 there's it just seems like there's a lot there, and 647 00:37:21.000 --> 00:37:25.639 I'm very I want it to happen. I'm just very skeptical. 648 00:37:27.239 --> 00:37:29.800 Show me the path. How do we how do we 649 00:37:29.880 --> 00:37:33.119 add more data manipulation on someone's plate and make their 650 00:37:33.119 --> 00:37:33.719 life simpler. 651 00:37:34.320 --> 00:37:37.320 So what I think is really going to happen is 652 00:37:39.119 --> 00:37:42.599 the providers that are currently in this the local first space, 653 00:37:42.639 --> 00:37:47.000 that are trying to push for uh these synchronization engines 654 00:37:47.039 --> 00:37:52.719 and these these rather sophisticated uh CRDT mechanisms for you know, 655 00:37:52.760 --> 00:37:56.360 there's there's actually a lot more to It's not simply 656 00:37:56.719 --> 00:37:58.599 you know, last change winds. There's a whole lot of 657 00:37:58.599 --> 00:38:02.880 complexity about merging change, the live changing system across device 658 00:38:02.880 --> 00:38:04.719 and all of that, and there's a lot of different 659 00:38:04.719 --> 00:38:06.800 trade offs that are being made. And so the people 660 00:38:06.800 --> 00:38:10.000 that are designing those engines are starting, at least from 661 00:38:10.039 --> 00:38:12.360 what I can see, I'm talking about things like replicash 662 00:38:12.440 --> 00:38:14.360 and a few others that are out there. So there's 663 00:38:14.400 --> 00:38:16.400 some things that you can google. There's a number of 664 00:38:16.679 --> 00:38:20.119 solutions out there in the local first space and what 665 00:38:20.320 --> 00:38:23.000 they what many of them that I've talked to or 666 00:38:23.079 --> 00:38:28.000 heard from are saying is we do actually have quite 667 00:38:28.039 --> 00:38:34.760 a bit of industry experience around building the back end 668 00:38:35.480 --> 00:38:39.280 logic that knows how to talk to rms that are 669 00:38:39.320 --> 00:38:43.360 backed by relational databases. So if we can build the 670 00:38:43.440 --> 00:38:50.119 replication logic and the the merging logic into those types 671 00:38:50.159 --> 00:38:53.159 of abstractions, we don't have to get people to learn 672 00:38:53.199 --> 00:38:57.000 an entirely new way of programming that type of what 673 00:38:57.039 --> 00:38:59.480 we would call back end logic. And I'm actually I'm 674 00:38:59.559 --> 00:39:02.519 using the air quotes around back end because I'm going 675 00:39:02.559 --> 00:39:05.159 to self service myself here for a minute and call 676 00:39:05.239 --> 00:39:07.920 back to a term that I invented back in two 677 00:39:07.920 --> 00:39:11.280 thousand and nine and twenty ten called middle end. What 678 00:39:11.400 --> 00:39:13.559 sits between the front end and the back end is 679 00:39:13.599 --> 00:39:16.400 the middle end. The way I originally conceived of the 680 00:39:16.400 --> 00:39:19.119 middle end was it was all the plumbing in the 681 00:39:19.159 --> 00:39:22.400 bottom ten percent of your front end application and all 682 00:39:22.440 --> 00:39:24.519 of the plumbing that was in the top ten percent 683 00:39:24.599 --> 00:39:27.760 on your server. And what makes those two things work 684 00:39:27.800 --> 00:39:30.920 together and talk together, whether that be templating or casing, 685 00:39:31.079 --> 00:39:35.039 or headers or session management or any of the data formatting, validation, 686 00:39:35.159 --> 00:39:36.840 all that stuff. That's what I call the middle end. 687 00:39:37.079 --> 00:39:39.000 But what I think is going to happen with local 688 00:39:39.039 --> 00:39:42.239 first is that there will in fact be a specialty. 689 00:39:43.000 --> 00:39:44.760 Whether we call it middle end and I get any 690 00:39:44.800 --> 00:39:46.880 credit for it remains to be seen, but I think 691 00:39:46.880 --> 00:39:49.559 there will be a specialty for the back of the 692 00:39:49.599 --> 00:39:53.159 front developer or the middle end developer who builds a 693 00:39:53.239 --> 00:39:57.719 significant portion of the back end of that application. They 694 00:39:57.760 --> 00:39:59.800 move it out of what they would traditionally host in 695 00:39:59.840 --> 00:40:01.679 a cloud server and they put it into the app, 696 00:40:02.039 --> 00:40:05.360 and they build it around these abstractions like being able 697 00:40:05.400 --> 00:40:09.679 to make relational database queries in an app. And even 698 00:40:09.719 --> 00:40:11.920 if that, you know, like you have a SEQL light 699 00:40:12.000 --> 00:40:14.599 in the in the client, because we can now do that, 700 00:40:14.639 --> 00:40:16.840 we can with the advent of WLASM, we can do 701 00:40:16.880 --> 00:40:18.480 all kinds of things, so we can literally have a 702 00:40:18.480 --> 00:40:21.199 seql light client in the app. And that's what a 703 00:40:21.199 --> 00:40:23.360 lot of these companies are doing is basically saying, let's 704 00:40:23.440 --> 00:40:26.760 layer an o RM on top of an actual database 705 00:40:27.039 --> 00:40:29.400 so that I'm writing data into a sequel light on 706 00:40:29.480 --> 00:40:34.239 the device, and I'm also replicating those those right changes 707 00:40:34.239 --> 00:40:37.599 in the data off to a relational, you know, database 708 00:40:37.639 --> 00:40:39.159 that may or may not be seqal light up in 709 00:40:39.199 --> 00:40:43.400 a cloud server, but they're using that ORM layer to 710 00:40:43.639 --> 00:40:46.880 do this. I think a lot of that complexity that 711 00:40:46.920 --> 00:40:50.400 you're worried about will be built around that. That's my prediction, 712 00:40:50.880 --> 00:40:52.880 and I think that there will be people who will 713 00:40:52.920 --> 00:40:55.519 really like that because they feel really comfortable in that, 714 00:40:55.599 --> 00:40:57.599 and now they'll be able to move a lot of 715 00:40:57.599 --> 00:41:00.760 those same skills into the back of the front or 716 00:41:00.760 --> 00:41:03.960 the middle end development in local first. I think there 717 00:41:04.000 --> 00:41:06.079 will be some people who will hate that and say 718 00:41:06.360 --> 00:41:09.480 SQL sucks and relational databases suck and we shouldn't use that. 719 00:41:09.719 --> 00:41:12.239 But that's why we're going to have lots of different options, right, 720 00:41:12.559 --> 00:41:14.760 So you may have a you know, a group of 721 00:41:15.599 --> 00:41:19.119 providers that choose to build that around relational databases, and 722 00:41:19.199 --> 00:41:21.000 others that are going to make something that's going to 723 00:41:21.079 --> 00:41:23.480 look a little bit more like graph ql, a little 724 00:41:23.480 --> 00:41:26.360 bit more free form. I think we'll see that and 725 00:41:26.719 --> 00:41:28.960 a half dozen others that I haven't conceived of yet. 726 00:41:29.360 --> 00:41:33.400 But I don't think you will ask app developers to 727 00:41:33.559 --> 00:41:38.519 start becoming experts on the deep academic theory around CRDT. 728 00:41:38.760 --> 00:41:41.159 I think that's what these providers are going to solve. 729 00:41:41.400 --> 00:41:44.159 They're getting close to solving, and they're working on hard 730 00:41:44.239 --> 00:41:44.920 trying to solve. 731 00:41:45.639 --> 00:41:48.320 So you touched on one issue there, and that's the 732 00:41:48.400 --> 00:41:51.159 term of the local data storage. You know, I think 733 00:41:51.199 --> 00:41:54.280 the default at least one I always here thrown around 734 00:41:54.320 --> 00:41:57.239 versus SQL light or rescue light, you know, because this 735 00:41:58.599 --> 00:42:01.400 tool that has been around forever very very easy to 736 00:42:01.480 --> 00:42:04.679 use to embed within an application and store local data. 737 00:42:05.159 --> 00:42:10.760 So my question is do you see tooling around other 738 00:42:10.880 --> 00:42:14.599 kinds of databases that can be used locally. So one 739 00:42:14.639 --> 00:42:16.559 that comes to mind is for a document database such 740 00:42:16.599 --> 00:42:18.719 as Mango dB. If somebody were to use that on 741 00:42:18.760 --> 00:42:20.440 the back end, I could see how that could be 742 00:42:21.320 --> 00:42:24.719 very difficult to convert between a sequl light structure on 743 00:42:24.760 --> 00:42:27.119 the local and then a Mango database on the back end. 744 00:42:29.679 --> 00:42:31.840 You know, I could probably wouldn't recommend that. 745 00:42:32.079 --> 00:42:34.199 I would not recommend it either considering how I work 746 00:42:34.199 --> 00:42:36.400 with the Mango every day. That would be hellish. 747 00:42:36.760 --> 00:42:41.440 So I'd say the things that I see right now 748 00:42:41.440 --> 00:42:44.440 in the client space are sequel Light and post Grace. 749 00:42:45.119 --> 00:42:48.039 There's a post Grace Light client that's been compiled a 750 00:42:48.079 --> 00:42:52.159 wows them. You can use the Postgrace SQL flavor if 751 00:42:52.199 --> 00:42:55.320 you like, or the seql Light seql flavor if you like, 752 00:42:55.639 --> 00:43:00.320 but those are the two major players for highly structured data. 753 00:43:01.000 --> 00:43:04.599 I would argue that if you need unstructured, non relational 754 00:43:04.679 --> 00:43:07.639 data storage, we already have that in the form of 755 00:43:08.199 --> 00:43:11.559 index dB and json objects and things like that. We 756 00:43:11.559 --> 00:43:15.920 don't need a Mango dbo RM on top of Jason 757 00:43:16.039 --> 00:43:18.800 objects if that, if you don't need the relational so 758 00:43:18.880 --> 00:43:22.159 I think the reason why we get big powerful engines 759 00:43:22.199 --> 00:43:25.519 like a sequel Light or post Grace Light being compiled 760 00:43:25.559 --> 00:43:28.199 to the browser is for all that relational stuff that's 761 00:43:28.280 --> 00:43:31.000 pretty hard for people to go and invent themselves. But 762 00:43:31.159 --> 00:43:34.960 if you're really talking about uh kind of document level 763 00:43:35.000 --> 00:43:39.320 storage stuff, there's already actually a pretty good and solid 764 00:43:39.360 --> 00:43:42.440 way of storing data. We have not only the index dB, 765 00:43:42.519 --> 00:43:44.519 but a lot of people don't realize we actually have 766 00:43:44.679 --> 00:43:48.760 fully cross browser the Origin Private File System, where you 767 00:43:48.800 --> 00:43:52.800 can create files and store arbitrary data and both. In truth, 768 00:43:53.559 --> 00:43:56.800 it is absolutely true. I've written a library around it, 769 00:43:56.840 --> 00:44:01.840 so it's absolutely true. I'm act check this, Okay, please 770 00:44:01.920 --> 00:44:05.000 do if you If you get both index dB and 771 00:44:05.159 --> 00:44:11.400 OPFs the Origin Private Final System, both of those have 772 00:44:11.840 --> 00:44:15.639 essentially up to about two thirds of the device's disc 773 00:44:15.760 --> 00:44:18.400 space that the browser makes available to them. So in 774 00:44:18.440 --> 00:44:20.320 the old days when we had like local storage and 775 00:44:20.360 --> 00:44:22.679 it was limited to five megabytes, and nobody could even 776 00:44:22.960 --> 00:44:25.719 imagine doing anything like, you know, like a real apps 777 00:44:25.800 --> 00:44:28.559 back end on those things. Now that we have index 778 00:44:28.639 --> 00:44:31.840 dB and OPFs, and both of them have very solid 779 00:44:33.239 --> 00:44:37.079 access to disk space, and I just we're going to 780 00:44:37.159 --> 00:44:41.039 see a big explosion of people building real data storage 781 00:44:41.079 --> 00:44:43.800 in the client as opposed to kind of stuffing some 782 00:44:43.840 --> 00:44:45.800 stuff in local storage the way it used to be. 783 00:44:46.119 --> 00:44:48.159 And I think a lot of people are not didn't 784 00:44:48.199 --> 00:44:53.840 realize that that happened. But OPFs is absolutely already happened. 785 00:44:54.280 --> 00:44:57.079 There's there are complexities around it, but you can work 786 00:44:57.079 --> 00:44:59.960 around those with libraries, which again that's that's what I've worked. 787 00:45:00.519 --> 00:45:02.880 So let's touch on index dB real quick, just by 788 00:45:02.880 --> 00:45:05.760 way of explanation, since I always like to or don't 789 00:45:05.800 --> 00:45:08.760 like to assume that everybody knows when we're talking about 790 00:45:08.800 --> 00:45:13.000 a tool. So you know, just looking at the u 791 00:45:13.239 --> 00:45:16.679 NDM page on index it sounds like it is now 792 00:45:16.880 --> 00:45:19.599 is the actual storage the files is that in the 793 00:45:19.679 --> 00:45:23.400 browser or just stashed locally on your OS somewhere on 794 00:45:23.440 --> 00:45:23.960 your device. 795 00:45:25.159 --> 00:45:29.079 So index dB, again fully cross browser has been around 796 00:45:29.079 --> 00:45:32.400 for you know, almost ten or fifteen years now, so 797 00:45:32.440 --> 00:45:38.280 it's it's definitely a reliable system. It's not new like OPFs, 798 00:45:38.320 --> 00:45:40.559 it's been around for a long long time. So index 799 00:45:40.639 --> 00:45:45.559 dB is kind of like back in the day, we 800 00:45:45.599 --> 00:45:48.280 had both index dB and we had web sql. They 801 00:45:48.280 --> 00:45:52.159 were both trying to vie for the structured data storage 802 00:45:52.199 --> 00:45:55.599 in the client model. Index dB has a whole bunch 803 00:45:55.639 --> 00:45:57.960 of complexity around it, and web sql was like this 804 00:45:58.079 --> 00:46:01.719 higher level, you know, SQL light type of interface, and 805 00:46:01.760 --> 00:46:03.400 a lot of people said, I don't I don't really 806 00:46:03.480 --> 00:46:05.800 like the indexdb. So there was this favoring of web 807 00:46:05.840 --> 00:46:08.639 sql in the early days, but there were some browsers 808 00:46:08.639 --> 00:46:11.199 that basically said, we're absolutely not going to ever do 809 00:46:11.239 --> 00:46:14.679 a web sql like Firefox, We're not doing web sql, 810 00:46:14.719 --> 00:46:17.320 We're only doing index dB. And so whether it was 811 00:46:17.360 --> 00:46:19.559 the better of the two options is kind of irrelevant 812 00:46:19.559 --> 00:46:23.119 because Browser's just sort of decided for us that the 813 00:46:23.199 --> 00:46:25.920 thing that we got was index dB, and everybody then 814 00:46:26.039 --> 00:46:29.360 agreed and just did it. Now. Indexdb again pretty low 815 00:46:29.440 --> 00:46:33.159 level API, a lot of complexity around, you know, transactions 816 00:46:33.159 --> 00:46:35.679 and other things like that. I don't even use index 817 00:46:35.800 --> 00:46:39.719 dB in that sense. There's a library called index dB keyval, 818 00:46:40.199 --> 00:46:45.039 IDB DASH keyval that creates a literal key value storage 819 00:46:45.039 --> 00:46:49.320 abstraction on top of Indexdbuh. It's got millions of downloads, 820 00:46:49.320 --> 00:46:52.400 it's it's hugely popular. Earlier, I've never dealt with indexdb 821 00:46:52.599 --> 00:46:54.960 other than to use that library, so I look at 822 00:46:55.000 --> 00:46:58.039 indexdb as a really powerful key value store. 823 00:46:58.880 --> 00:47:03.360 Do you know how it compares to local Forage. 824 00:47:03.559 --> 00:47:07.480 I do know some of the history behind local Forage, 825 00:47:07.480 --> 00:47:09.280 but the most important thing to point out about Local 826 00:47:09.320 --> 00:47:11.519 Forage is that, as far as I'm aware, it's no 827 00:47:11.599 --> 00:47:15.480 longer maintained, IDB q val is actually actively maintained. It's 828 00:47:15.559 --> 00:47:19.239 Jake Archibald that built that library. It's an actively maintained 829 00:47:19.280 --> 00:47:22.400 library and still gets a lot of usage. Friend, local 830 00:47:22.440 --> 00:47:25.679 Forage hasn't hasn't been maintained for quite a while, I think. 831 00:47:25.559 --> 00:47:29.159 So, Okay, yeah, I've noticed that there's some Yeah, there's 832 00:47:29.199 --> 00:47:31.920 some issues there. Okay, I'll have to to try this 833 00:47:31.960 --> 00:47:32.519 out next time. 834 00:47:34.960 --> 00:47:38.000 So in any case, that that that explains what index 835 00:47:38.079 --> 00:47:40.679 dB is been around a long time, stabilized, and there 836 00:47:40.719 --> 00:47:44.760 are a variety of libraries Local Forage, IDB, KVAL and 837 00:47:44.840 --> 00:47:48.159 others that make working with index dB not as painful 838 00:47:48.199 --> 00:47:52.039 as its native API is. A lot of people use 839 00:47:52.079 --> 00:47:54.559 index DV for that, and I would I would make 840 00:47:54.599 --> 00:47:57.559 the case that index dB should be the default client 841 00:47:57.639 --> 00:48:01.480 data storage over local storage, not only because it has 842 00:48:01.960 --> 00:48:06.880 larger disk space access, but also because nxdb can actually 843 00:48:06.920 --> 00:48:10.639 be accessed from workers and done asynchronously, where local storage 844 00:48:10.679 --> 00:48:13.960 and session storage cannot be accessed from worker thronts, So 845 00:48:14.000 --> 00:48:16.480 that makes it a more flexible data storage. 846 00:48:16.719 --> 00:48:21.760 Now with OPFs, the og I got to fact check you. Okay, 847 00:48:21.880 --> 00:48:25.199 I do not see baseline support for OPFs. Okay. 848 00:48:25.840 --> 00:48:29.679 So there's a lot of complexity around OPFs. There's a 849 00:48:29.840 --> 00:48:36.880 narrow layer that we're drawing here. OPFs has a variety 850 00:48:36.880 --> 00:48:39.760 of ways that people can envision using it. I'm going 851 00:48:39.800 --> 00:48:42.280 to talk about it in ways where you want to 852 00:48:42.360 --> 00:48:46.920 access existing files on the user's system, like something off 853 00:48:46.920 --> 00:48:51.000 of their desktop. There's that usage of OPFs, and that 854 00:48:51.079 --> 00:48:53.800 does not have baseline support. It might not ever because 855 00:48:53.840 --> 00:48:57.280 there's still a lot of security considerations around it. But 856 00:48:57.360 --> 00:49:01.880 there's the Virtual Private file System of OPFs, which is 857 00:49:02.039 --> 00:49:04.719 a reserved area of disk space that you can read 858 00:49:04.760 --> 00:49:09.079 and write files into and its origin locked. That actually 859 00:49:09.400 --> 00:49:14.400 got much more widespread consensus among the browser vendors, but 860 00:49:14.519 --> 00:49:18.199 there was performance concerns around it. So people wanted an 861 00:49:18.239 --> 00:49:25.639 OPFs interface where they could do easy kind of synchronous 862 00:49:25.679 --> 00:49:29.960 reads and writes from it, and there were performance concerns 863 00:49:29.960 --> 00:49:32.199 about you can't do synchronous reads and writes on the 864 00:49:32.239 --> 00:49:35.280 main thread because that could block things and whatever, and 865 00:49:35.320 --> 00:49:37.480 so what we got was this bifurcation where there was 866 00:49:37.519 --> 00:49:40.960 an asynchronous API that you could use from the main thread, 867 00:49:41.280 --> 00:49:45.079 and that one also has not yet achieved this sort 868 00:49:45.119 --> 00:49:49.920 of baseline parody because notably Safari does not support that 869 00:49:50.079 --> 00:49:55.119 main thread asynchronous API. However, all of the browsers did 870 00:49:55.159 --> 00:50:00.559 implement the synchronous read and write from workers, willing to 871 00:50:00.599 --> 00:50:05.599 take on the complexity of burying your storage logic inside 872 00:50:05.760 --> 00:50:10.480 of a worker. You actually can do OPFs with synchronous 873 00:50:10.480 --> 00:50:13.119 reads and rites across all the major browsers. I would 874 00:50:13.199 --> 00:50:16.000 argue that is actually baseline in that subset. 875 00:50:16.760 --> 00:50:19.079 That's well, I mean, we can see if it's baseline, 876 00:50:19.079 --> 00:50:22.519 because it'll have the sticker baseline on it on MDN 877 00:50:22.599 --> 00:50:25.320 and the other sites that that catalog these. 878 00:50:26.000 --> 00:50:29.400 I'm just saying that it's there's the nuance and complexity 879 00:50:29.440 --> 00:50:31.239 may or may not be captured there in the way 880 00:50:31.239 --> 00:50:34.119 that they're messaging this, which is whether or not you're 881 00:50:34.199 --> 00:50:37.400 using the asynchronous API or whether you're relying upon the 882 00:50:37.440 --> 00:50:41.199 synchronous API and doing it in a worker. This narrow 883 00:50:41.519 --> 00:50:44.840 do it with synchronous APIs in a worker is actually 884 00:50:44.880 --> 00:50:47.480 something I've tested. It. It works on all these mobile 885 00:50:47.519 --> 00:50:50.920 devices and desktop browsers, so that. 886 00:50:50.840 --> 00:50:54.119 I think super interesting. Will you drop we? Okay? 887 00:50:54.679 --> 00:50:55.039 Agreed? 888 00:50:55.159 --> 00:50:58.880 Agreed, because the baseline is pretty broad. Baseline typically applies 889 00:50:58.920 --> 00:51:02.679 to the entire specification, except in the case of past key, 890 00:51:02.679 --> 00:51:06.480 where it only applies to one item in half of 891 00:51:06.519 --> 00:51:11.840 the options. You and I have both had fun with 892 00:51:11.920 --> 00:51:12.239 that one. 893 00:51:12.320 --> 00:51:12.880 Yes we have. 894 00:51:13.119 --> 00:51:18.000 Yeah, yeah, so yeah, drop a link to some resource 895 00:51:18.039 --> 00:51:20.960 for that, please, because just so, what I'll do is 896 00:51:21.000 --> 00:51:22.239 like comments. 897 00:51:21.960 --> 00:51:23.760 What I'm going to do is actually drop a link. 898 00:51:23.960 --> 00:51:25.480 I've referred to this a couple of times, but I'm 899 00:51:25.480 --> 00:51:28.360 going to drop a link to a library that I 900 00:51:28.480 --> 00:51:32.480 recently wrote, which tries to abstract client side storage. Gives 901 00:51:32.519 --> 00:51:36.480 you a key value abstraction across all five of the 902 00:51:36.559 --> 00:51:40.800 major client storage mechanisms. There's cookies, which people don't often 903 00:51:40.840 --> 00:51:43.360 think of as client storage, but you can actually read 904 00:51:43.400 --> 00:51:47.320 and write keyvaals and cookies. There's local storage and session storage. 905 00:51:47.360 --> 00:51:51.440 There's index dB, and there's OPFs, and that library supports 906 00:51:51.480 --> 00:51:55.159 both the OPFs in the main thread, but then you know, 907 00:51:55.199 --> 00:51:58.480 it doesn't support all browsers, or there's also the worker 908 00:51:58.599 --> 00:52:01.719 version of that which does work in more browsers. You 909 00:52:01.760 --> 00:52:03.760 just have to be willing to do the you know, 910 00:52:03.880 --> 00:52:06.719 some of the reasons why people don't like worker based 911 00:52:07.000 --> 00:52:12.519 logic is because it can it can make more complex 912 00:52:12.639 --> 00:52:16.079 your security headers, like your CSP policy on a site 913 00:52:16.159 --> 00:52:17.199 or things like that. You have to be a little 914 00:52:17.239 --> 00:52:19.800 more careful. But if you're willing to go down that route, 915 00:52:19.920 --> 00:52:23.000 you can use OPFs in all of the major the 916 00:52:23.000 --> 00:52:26.360 stable versions of all the major browsers and devices today. 917 00:52:26.840 --> 00:52:30.000 And so I'll drop a link to the storage library 918 00:52:30.000 --> 00:52:31.840 that I wrote that tries to just give you a 919 00:52:31.960 --> 00:52:36.320 very easy, consistent key value abstraction across all of those. 920 00:52:37.239 --> 00:52:39.440 So my understanding is the way that that works in 921 00:52:39.519 --> 00:52:43.400 practice is that you create a main thread API that 922 00:52:43.679 --> 00:52:49.480 resembles closely the worker thread API. It transforms data into 923 00:52:49.599 --> 00:52:54.000 a buffer and then sends it as a shared buffer 924 00:52:54.039 --> 00:52:57.719 object across the worker thread, and then the worker thread 925 00:52:57.800 --> 00:53:01.360 sends it back as a shared buffer object, and then 926 00:53:01.360 --> 00:53:05.320 it gets re encoded. That is that the basic cycle 927 00:53:05.440 --> 00:53:09.840 of that. So sharing data between workers is actually a 928 00:53:09.840 --> 00:53:14.199 bit of a complex thing, and it's unfortunate that it 929 00:53:14.360 --> 00:53:18.199 is so complex. But sharing data between workers can either 930 00:53:18.320 --> 00:53:22.920 be serializing to a string and sending that string of 931 00:53:23.000 --> 00:53:28.960 data across the inner process channel, or this newer standard 932 00:53:29.119 --> 00:53:36.159 of these transferable objects transferable objects. It's a more complex 933 00:53:36.239 --> 00:53:39.639 programming paradigm, but it is effectively that you use stuff 934 00:53:39.719 --> 00:53:42.920 some data in a type deray, and then you tell 935 00:53:42.960 --> 00:53:47.199 the browser I'm relinquishing control of this type deray to 936 00:53:47.480 --> 00:53:50.079 a thread and I can no longer read from it 937 00:53:50.159 --> 00:53:52.960 while that thread has control of the type deray, and 938 00:53:53.000 --> 00:53:57.760 then the thread now instantly has access with zero copy 939 00:53:58.119 --> 00:54:01.280 to that same shared memory, can read from that type 940 00:54:01.320 --> 00:54:04.360 deray the literal binary data from it, can read the 941 00:54:04.360 --> 00:54:06.800 bits from that, do whatever it wants right back to it, 942 00:54:07.000 --> 00:54:09.480 and then relinquish control back to the main thread. That's 943 00:54:09.480 --> 00:54:14.679 what transferable like, being able to transfer things. Most people 944 00:54:14.960 --> 00:54:17.960 don't go that route unless they have massive amounts of 945 00:54:18.079 --> 00:54:19.760 data that they're trying to send, and by massive I 946 00:54:19.800 --> 00:54:22.840 mean like one hundred megabytes for more. Most people, Yeah, 947 00:54:22.840 --> 00:54:25.280 I think when they're sending data back and forth are 948 00:54:25.519 --> 00:54:28.679 just serializing to Jason and sending it across. 949 00:54:29.559 --> 00:54:33.679 I think that PAPA parse was maybe the first widely known, 950 00:54:33.800 --> 00:54:39.039 popular library that took advantage of these tricks because it 951 00:54:39.400 --> 00:54:42.639 supposed to be able to handle you know, gigabyte CSV files. 952 00:54:43.039 --> 00:54:44.480 Mm hm, I don't know. 953 00:54:44.559 --> 00:54:46.400 Do you know of anything else that's in that vein 954 00:54:46.440 --> 00:54:50.119 because that that's my experience with worker threads is pretty 955 00:54:50.199 --> 00:54:53.840 much PAPA parse and a couple of failed experiments. 956 00:54:54.840 --> 00:54:57.719 I don't know Papa parts. I haven't used that one. 957 00:54:58.199 --> 00:55:01.559 I don't think I've ever used any worker libraries. I've 958 00:55:01.559 --> 00:55:05.079 always just used the you know, the direct work or 959 00:55:05.119 --> 00:55:07.760 interface that we get in the browser. So I don't 960 00:55:07.760 --> 00:55:11.440 have any specific recommendations to make around there. But like 961 00:55:11.559 --> 00:55:14.800 this this library that I'm you know, posting this this 962 00:55:15.199 --> 00:55:17.800 link to, you could look at that code. It's only 963 00:55:17.840 --> 00:55:19.719 like a couple dozen lines of code. You could look 964 00:55:19.760 --> 00:55:22.119 at the code of how I'm managing those workers, and 965 00:55:22.159 --> 00:55:25.360 you could very easily write an adaptation of that that 966 00:55:25.480 --> 00:55:29.159 instead of sending the data across in Jason did so 967 00:55:29.320 --> 00:55:32.559 with a more sophisticated, you know, transferable or you know, 968 00:55:32.639 --> 00:55:35.360 bury it in a binary array and a typed array 969 00:55:35.400 --> 00:55:37.519 and do a transferred object kind of thing. You could 970 00:55:37.519 --> 00:55:39.320 do that. It wouldn't be that hard, all. 971 00:55:39.239 --> 00:55:42.280 Right, Cool, So I forget the track that we were on. 972 00:55:42.400 --> 00:55:44.800 I actually, since I forgot anyway, I actually want to 973 00:55:44.840 --> 00:55:47.599 go back a little bit. And we've we've thrown around 974 00:55:47.599 --> 00:55:50.400 some terms that it seems like recently, I'm I'm. What 975 00:55:50.480 --> 00:55:52.360 I'm picking up is that people are using these terms 976 00:55:52.360 --> 00:55:57.880 in different ways, and so that's like huge step back. 977 00:55:59.039 --> 00:56:03.639 Let's define cloud, because cloud meant I have a VPS 978 00:56:03.800 --> 00:56:09.000 on Lenode. That's what cloud meant. What does cloud mean now? 979 00:56:11.280 --> 00:56:15.840 I mean cloud basically means now that you're using a 980 00:56:16.000 --> 00:56:23.280 managed hosting solution with built in scaleability. So you're using 981 00:56:23.280 --> 00:56:26.920 something like AWS or Google Cloud Platform or maybe Azure 982 00:56:27.000 --> 00:56:30.280 for Microsoft, using one of those big cloud providers, and 983 00:56:30.320 --> 00:56:33.440 you're basically allowing those managed services to do all of 984 00:56:33.480 --> 00:56:36.239 the provisioning, the spinning up and down of your servers. 985 00:56:36.920 --> 00:56:39.960 You're not really doing a lot of that manually, although 986 00:56:39.960 --> 00:56:43.599 you could, you know, you know, AWS as a dashboard, 987 00:56:43.599 --> 00:56:46.000 you could go in and take down a server or 988 00:56:46.039 --> 00:56:47.320 put up a new one if you want it. But 989 00:56:47.360 --> 00:56:51.079 you're basically creating these these policies so that it's managing 990 00:56:51.239 --> 00:56:54.079 your your scale and your growth for you. I don't 991 00:56:54.559 --> 00:56:58.480 have any more understanding of cloud than what I just 992 00:56:58.519 --> 00:57:00.719 said that is the sum total knowledge, because I never 993 00:57:01.039 --> 00:57:03.679 got into that space. There's probably listeners here who would 994 00:57:04.079 --> 00:57:07.119 have a very different and much more detailed view of 995 00:57:07.159 --> 00:57:09.679 the cloud. But what I understand the cloud because I 996 00:57:09.719 --> 00:57:12.199 have a VM online line ode right, and I don't 997 00:57:12.199 --> 00:57:15.599 call that the cloud. I'm paying for a virtual machine, 998 00:57:15.639 --> 00:57:18.000 but I do all of my own management, and there's 999 00:57:18.000 --> 00:57:20.519 no built in scalability where I get a new VM 1000 00:57:20.719 --> 00:57:23.760 just because I get you know, slash dot it or 1001 00:57:23.840 --> 00:57:25.960 at the homepage of Reddit or something. I have to 1002 00:57:26.000 --> 00:57:28.000 manage all of that stuff. So I don't call that 1003 00:57:28.119 --> 00:57:30.480 the cloud because they're not really doing anything for me. 1004 00:57:30.519 --> 00:57:33.920 I'm just renting a bit of memory and CPU cycles 1005 00:57:33.960 --> 00:57:34.320 from them. 1006 00:57:34.960 --> 00:57:38.880 So low cloud VPS, middle cloud auto scaling. But then 1007 00:57:38.880 --> 00:57:42.480 there's high cloud, which is serveralus functions. 1008 00:57:43.039 --> 00:57:48.559 Sure, yeah, cloud Flare with you know, with their durable objects, 1009 00:57:48.719 --> 00:57:52.519 and we've got you know, functions as the fast functions 1010 00:57:52.519 --> 00:57:55.639 as the service and AWS Lambda and all of that stuff. 1011 00:57:55.679 --> 00:57:57.920 That would be Yeah, I think that's fair to call 1012 00:57:57.960 --> 00:58:00.239 that a higher abstraction of cloud. 1013 00:58:00.920 --> 00:58:05.000 Because right now on Twitter, right now, it seems like 1014 00:58:05.159 --> 00:58:08.840 whenever people are saying cloud in references, particularly to all 1015 00:58:08.840 --> 00:58:14.159 this DHA stuff, they actually specifically mean functions. They don't 1016 00:58:14.159 --> 00:58:17.760 mean the auto scaling, they don't mean like they are 1017 00:58:17.920 --> 00:58:22.800 strictly it seems like they are strictly talking about just functions. 1018 00:58:22.840 --> 00:58:24.719 And that was confusing to me because, like I said, 1019 00:58:24.760 --> 00:58:27.840 I while I've heard the term cloud, it's gone from 1020 00:58:27.920 --> 00:58:33.239 meaning I don't host the server in the closet at 1021 00:58:33.239 --> 00:58:39.280 the office, I co locate it, or I use just 1022 00:58:39.360 --> 00:58:44.519 a portion vert via VM, to now it means like 1023 00:58:45.159 --> 00:58:48.000 it basically, it seems like it means anything that marketers 1024 00:58:48.000 --> 00:58:49.760 wanted to mean at the moment. 1025 00:58:50.199 --> 00:58:54.760 And public I think it's important at each other. I 1026 00:58:54.800 --> 00:58:58.599 think it's important to note there. I think there's a 1027 00:58:58.880 --> 00:59:06.480 very important distinction between a VM that I am responsible 1028 00:59:06.639 --> 00:59:10.000 with the root login to manage and turn take down 1029 00:59:10.119 --> 00:59:13.159 and to reboot and upgrade and all of that stuff, 1030 00:59:13.519 --> 00:59:17.079 versus a fully managed service where I don't even know 1031 00:59:17.320 --> 00:59:20.320 what my VM is. I've just given you like Docker images, 1032 00:59:20.320 --> 00:59:22.880 and I've said, please just go spin up whatever servers 1033 00:59:22.880 --> 00:59:25.440 I need out of that stuff. Those are very different 1034 00:59:25.559 --> 00:59:28.880 system that men thought processes, and they take very different 1035 00:59:28.880 --> 00:59:31.880 skill sets. So I think there's a distinction there to 1036 00:59:31.920 --> 00:59:33.719 be made, and I would call the ladder of those 1037 00:59:33.800 --> 00:59:37.039 cloud versus you use the term co locate. I mean 1038 00:59:37.039 --> 00:59:40.320 I was doing that back in ninety seven in college. 1039 00:59:40.360 --> 00:59:44.280 I was running a server in my apartment in college, 1040 00:59:44.559 --> 00:59:46.519 and then I remember the day that I was like, yeah, 1041 00:59:46.559 --> 00:59:49.519 I can't do this anymore, and I went and bought 1042 00:59:49.519 --> 00:59:53.039 a one U server and stuck my hardware in a 1043 00:59:53.159 --> 00:59:55.960 data center somewhere that certainly was not the cloud, because 1044 00:59:55.960 --> 00:59:59.719 I was still completely responsible for that server. They just 1045 00:59:59.760 --> 01:00:03.039 gave me a power plug and an Ethernet plug, all right. 1046 01:00:03.480 --> 01:00:09.400 So, uh then onto onto the next thing, well, the 1047 01:00:09.599 --> 01:00:12.679 kind of two things maybe. So I want to know 1048 01:00:12.760 --> 01:00:16.519 where I want to know what is the alternative because 1049 01:00:16.559 --> 01:00:18.679 we talked about, okay, people are going to have this 1050 01:00:18.800 --> 01:00:25.920 data locally, and uh, I agree, there's some efficiencies there. 1051 01:00:25.960 --> 01:00:30.039 There's also some inefficiencies, especially on Android devices due to 1052 01:00:30.079 --> 01:00:34.760 the single core uh speed and and Jason parsing from 1053 01:00:35.079 --> 01:00:38.480 local storage or index dB actually becomes significant a lot 1054 01:00:38.559 --> 01:00:41.079 quicker than most people would think. 1055 01:00:41.639 --> 01:00:41.760 Uh. 1056 01:00:42.079 --> 01:00:46.039 But like there's there's a potential, there's certainly bandwidth savings. 1057 01:00:46.159 --> 01:00:50.800 There's definitely potential performance savings, although a lot of the 1058 01:00:50.800 --> 01:00:54.039 critics of that have you know, I believe that a 1059 01:00:54.039 --> 01:00:57.039 lot of their points are valid. But like you were saying, 1060 01:00:57.039 --> 01:00:59.079 it's like, what layer are you viewing at this? If 1061 01:00:59.119 --> 01:01:01.559 it's if it's time to first contentful paint, but the 1062 01:01:01.559 --> 01:01:03.880 person still can't click a button, well, then you're just 1063 01:01:04.000 --> 01:01:06.639 lying to the user. You didn't actually do anything better. 1064 01:01:08.079 --> 01:01:13.159 And then, so what is the alternative to the cloud 1065 01:01:13.199 --> 01:01:14.760 in terms of how the data is going to work? 1066 01:01:14.800 --> 01:01:19.000 It doesn't seem like web RTC is really there yet, 1067 01:01:19.960 --> 01:01:22.119 But what's the alternative? And then what are the places? 1068 01:01:22.119 --> 01:01:25.320 How do we distinguish between the places where local first 1069 01:01:25.400 --> 01:01:28.360 makes sense and local first doesn't make sense because it 1070 01:01:28.360 --> 01:01:32.519 sounds like to me, Amazon or Walmart search would never 1071 01:01:32.599 --> 01:01:37.960 make sense. Bank access and email access seems like that 1072 01:01:38.039 --> 01:01:41.920 would always make sense, and Twitter would be somewhere in between. 1073 01:01:42.079 --> 01:01:44.480 So you give me your take, and that you know, 1074 01:01:45.000 --> 01:01:46.840 given that context, these are. 1075 01:01:46.760 --> 01:01:52.000 Fair questions, and I'll I'll acknowledge that lots of different 1076 01:01:52.039 --> 01:01:55.159 perspectives are going to exist on this, So I'm only 1077 01:01:55.280 --> 01:01:59.280 giving my one little slice of perspective. But I actually 1078 01:01:59.320 --> 01:02:04.960 do think that probably the lion's share of applications should 1079 01:02:05.039 --> 01:02:08.000 move local first. And I personally feel that way because 1080 01:02:08.400 --> 01:02:10.880 not only do we have the description, you know, the 1081 01:02:10.920 --> 01:02:14.039 discussion that we had earlier about the business model and 1082 01:02:14.039 --> 01:02:16.800 whether users can monetize and whether there's like a business 1083 01:02:17.000 --> 01:02:20.719 justification for local first. That's part of the equation. That's 1084 01:02:20.719 --> 01:02:23.079 not what brought me to local first. What brought me 1085 01:02:23.159 --> 01:02:26.480 to local first was actually a personal convection around the 1086 01:02:26.480 --> 01:02:31.920 importance of the autonomy of users owning their own identity, 1087 01:02:32.400 --> 01:02:35.360 taking that with them wherever they go, and owning their data. 1088 01:02:35.800 --> 01:02:38.280 I make the assertion in a couple of different meetups 1089 01:02:38.280 --> 01:02:43.360 and conference talks recently that data that you don't physically 1090 01:02:43.400 --> 01:02:46.039 control is data that you don't own. In other words, 1091 01:02:46.280 --> 01:02:48.880 custody of data is the whole game. If I have 1092 01:02:49.079 --> 01:02:52.360 data that theoretically is mine, but it's actually physically in 1093 01:02:52.400 --> 01:02:55.679 the custody of a cloud server that's behind some business 1094 01:02:55.760 --> 01:02:58.360 model of a company that I don't own and control, 1095 01:02:58.760 --> 01:03:01.920 then that's no longer my day. I'm renting that data back, 1096 01:03:02.519 --> 01:03:03.960 and I believe that's the ransom. 1097 01:03:04.400 --> 01:03:06.480 That's why they give you the first ten years for free. 1098 01:03:07.000 --> 01:03:10.159 Exactly. They get you hooked, just like any good drug 1099 01:03:10.199 --> 01:03:15.840 dealer does. I genuinely believe that most of the Web 1100 01:03:15.960 --> 01:03:19.320 needs to move to a model where users have that 1101 01:03:19.400 --> 01:03:23.159 autonomy over their identity and over their data, and I 1102 01:03:23.239 --> 01:03:26.360 believe that local first is the only compelling model for 1103 01:03:26.480 --> 01:03:29.480 us moving in that direction right now. Are their challenges 1104 01:03:29.480 --> 01:03:32.639 with local first? Of course? Is it so nascent that 1105 01:03:32.880 --> 01:03:35.280 it's unlikely to win? I mean, I think we have 1106 01:03:35.360 --> 01:03:40.280 to concede that most challenges to the status quo of 1107 01:03:40.360 --> 01:03:43.599 billion dollar businesses don't win. I think we have to 1108 01:03:43.639 --> 01:03:47.960 concede that we've had a whole other sphere, which we're 1109 01:03:48.000 --> 01:03:50.199 not even talking about here. We've had this Web three 1110 01:03:50.280 --> 01:03:53.920 crypto movement that for fifteen years has been saying we're 1111 01:03:53.920 --> 01:03:57.199 the answer to that. I actually worked at a Web 1112 01:03:57.239 --> 01:03:59.280 three company for a while, and they've said we're the 1113 01:03:59.360 --> 01:04:04.519 answer to all of that centralization and give everybody their stuff. 1114 01:04:05.079 --> 01:04:09.039 I worked for a Web three company and for that 1115 01:04:09.199 --> 01:04:14.719 six months was like continually confronted by how easy it 1116 01:04:14.840 --> 01:04:19.119 was for people in that space to just grin and 1117 01:04:19.559 --> 01:04:23.800 blink away. The big gap between the way the web 1118 01:04:23.880 --> 01:04:27.679 is currently built and the way users currently experience that 1119 01:04:27.880 --> 01:04:30.920 and what Web three is. And so I left there thinking, 1120 01:04:31.639 --> 01:04:33.039 I don't know if we're ever going to get to 1121 01:04:33.079 --> 01:04:36.960 Web three, but if we're ever going to get anywhere forward, 1122 01:04:37.360 --> 01:04:39.440 we need to evolve the web. And I started calling 1123 01:04:39.519 --> 01:04:42.360 it web two point five, where the web goes to 1124 01:04:42.519 --> 01:04:46.920 more of a users own their data, users own their identity, 1125 01:04:47.960 --> 01:04:53.119 the experiences are more installed rather than accessed on every round, 1126 01:04:53.320 --> 01:04:55.280 Like you know, every time you go to a web page, 1127 01:04:55.320 --> 01:04:58.559 you're effectively reinstalling that web app. And that's bonkers because 1128 01:04:58.719 --> 01:05:01.480 we wouldn't treat native AP apps that way, where every 1129 01:05:01.519 --> 01:05:03.840 single time we opened up or clicked a button in 1130 01:05:03.880 --> 01:05:06.400 an app, we re downloaded the whole app or even 1131 01:05:06.440 --> 01:05:07.119 part of the app. 1132 01:05:07.639 --> 01:05:09.679 But this is this is the allure of React, right, 1133 01:05:09.760 --> 01:05:12.119 this is this is the same problem like the state 1134 01:05:12.159 --> 01:05:16.280 management's hard, the upgrade path is hard, Diffing the data 1135 01:05:16.400 --> 01:05:18.559 is hard. We're just going to redo the whole thing 1136 01:05:18.599 --> 01:05:20.679 from top to bottom. 1137 01:05:21.119 --> 01:05:23.280 I don't so. First of all, I don't think we're 1138 01:05:23.280 --> 01:05:27.760 redoing the whole thing, because if you build local first 1139 01:05:27.800 --> 01:05:31.239 apps with web technology, you can build. 1140 01:05:31.239 --> 01:05:35.039 What I meant re rendering, reloading. 1141 01:05:35.239 --> 01:05:40.360 But oh well, that's that's I We could do multiple 1142 01:05:40.360 --> 01:05:42.920 episodes on whether or not the virtual Dawn was a 1143 01:05:42.960 --> 01:05:45.800 good thing for for us or whether it really took us. 1144 01:05:46.119 --> 01:05:49.400 You know, I think it was very much a let's 1145 01:05:50.559 --> 01:05:53.000 climb a local Maxima hill and we got to the 1146 01:05:53.119 --> 01:05:55.280 very top of that local maximam hill and then we're like, oh, 1147 01:05:55.320 --> 01:05:57.800 this sucks. This isn't the right hill to climb. But 1148 01:05:58.000 --> 01:06:00.920 that's you know, that's my personal take on on the 1149 01:06:01.599 --> 01:06:03.760 virtual dom and dom diffing and all of you know, 1150 01:06:03.920 --> 01:06:06.280 rerender every you know, fifteen MILLI. 1151 01:06:07.519 --> 01:06:09.639 But the basic concept what I'm saying is the basic 1152 01:06:09.679 --> 01:06:13.199 concept is state is hard. Let's not do it. That 1153 01:06:13.400 --> 01:06:15.840 was the allure. State is hard, Let's not do it. 1154 01:06:15.840 --> 01:06:18.559 We're going to render the whole thing so we don't 1155 01:06:18.599 --> 01:06:20.800 have to keep track of individual state. We don't need 1156 01:06:20.800 --> 01:06:21.000 to know. 1157 01:06:21.079 --> 01:06:25.079 There's no app button, there's no app in existence that 1158 01:06:25.199 --> 01:06:28.800 is using react, that is not doing sophisticated state management 1159 01:06:28.880 --> 01:06:33.159 alongside it. So I know, I know that doesn't exist. 1160 01:06:33.280 --> 01:06:40.000 We's pardon your French, Sorry, No, I'm I'm there with you. 1161 01:06:40.119 --> 01:06:42.440 I'm just saying that that's the allure, and there is 1162 01:06:42.519 --> 01:06:45.079 something to that, Like I think I've taken a look 1163 01:06:45.079 --> 01:06:47.480 at swift UI and I think Android jetpack is the 1164 01:06:47.480 --> 01:06:51.039 same and swift U. I when I hear if I 1165 01:06:51.079 --> 01:06:53.599 close my eyes and I listen to the conference talk, 1166 01:06:53.719 --> 01:06:56.760 I hear react react, react, react, But when I open 1167 01:06:56.800 --> 01:07:00.400 my eyes, I see something that it's like this looks 1168 01:07:00.519 --> 01:07:06.079 like this looks like it actually solves the problem, which 1169 01:07:06.119 --> 01:07:09.440 is like really surprising because I was, like, I abhorred 1170 01:07:09.519 --> 01:07:12.039 reacts so much. But swift Ui is something that's really 1171 01:07:12.039 --> 01:07:14.599 intriguing to me. How can these two things be And 1172 01:07:14.800 --> 01:07:17.400 I don't know. There's like there's the promise, there's what's 1173 01:07:17.440 --> 01:07:19.840 on the conference side, and then there's the implementation. And 1174 01:07:19.880 --> 01:07:21.800 I think when you look at something like swift Ui, 1175 01:07:21.960 --> 01:07:23.960 it's the same promise. But I think they might have 1176 01:07:24.000 --> 01:07:26.360 the implementation right. I don't have enough experience with it 1177 01:07:26.400 --> 01:07:27.800 to say, but I think they might. 1178 01:07:28.400 --> 01:07:32.519 The thing I would point out is that the only 1179 01:07:32.719 --> 01:07:38.639 thing that's really significant in the front end development space 1180 01:07:38.800 --> 01:07:44.440 over the last couple of years that is somewhat antithetical 1181 01:07:44.679 --> 01:07:47.440 to the local first movement is the move to server 1182 01:07:47.559 --> 01:07:52.400 side rendering of components and that whole complexity, all the 1183 01:07:52.480 --> 01:07:56.320 other things that and and and, as I argued earlier, 1184 01:07:56.639 --> 01:07:59.519 they only did that because they keep trying to chase 1185 01:07:59.599 --> 01:08:08.320 this ethical zero millisecond reinstall experience that that product managers 1186 01:08:08.400 --> 01:08:11.239 and people have just sold as a reality that isn't. 1187 01:08:11.360 --> 01:08:14.320 They're trying to get closer and closer to pretending as 1188 01:08:14.360 --> 01:08:17.159 if the app can reside in both places at the 1189 01:08:17.199 --> 01:08:20.399 exact same time and there's no cost over the wire. 1190 01:08:21.600 --> 01:08:24.159 If you didn't ever start with that as your goal, 1191 01:08:24.239 --> 01:08:27.239 which I never did, then you wouldn't have ever gone 1192 01:08:27.319 --> 01:08:30.520 down the road of trying to do server side component 1193 01:08:30.600 --> 01:08:32.720 rendering and all of that stuff. That wouldn't have been 1194 01:08:32.760 --> 01:08:34.960 the way you tried to fix it, and local first 1195 01:08:35.359 --> 01:08:38.119 fixes it in different ways that I think are much 1196 01:08:38.199 --> 01:08:41.880 less complex. And so that's really the only thing that's 1197 01:08:41.960 --> 01:08:45.119 happened in the last few years of development that you 1198 01:08:45.199 --> 01:08:48.239 might have to abandon. If you really wanted to embrace 1199 01:08:48.279 --> 01:08:50.560 local first, you would have to kind of get away 1200 01:08:50.560 --> 01:08:54.159 from that server side component way of thinking that people 1201 01:08:54.239 --> 01:08:57.800 are starting to get excited about and enjoy. But all 1202 01:08:57.840 --> 01:08:59.960 of the other things that you could bring. You could 1203 01:09:00.159 --> 01:09:06.199 bring a straight up React fifteen virtual dom application straight 1204 01:09:06.239 --> 01:09:08.920 to local first. You can do what I do, which 1205 01:09:08.920 --> 01:09:10.760 I didn't even use the front end frameworks. I use 1206 01:09:10.800 --> 01:09:13.520 templating and I'm super old school, but I use mustache 1207 01:09:13.520 --> 01:09:17.760 templates and you can do that. You can use reactive 1208 01:09:17.960 --> 01:09:22.439 things like view you know, and their signals in spell. 1209 01:09:22.600 --> 01:09:25.159 You can do any of those things for local first development. 1210 01:09:25.399 --> 01:09:29.239 The only thing you can't do is offload significant amounts 1211 01:09:29.279 --> 01:09:32.119 of your front end logic to a back end, because 1212 01:09:32.119 --> 01:09:34.039 you really need to stick that back end on the 1213 01:09:34.119 --> 01:09:36.279 client to embrace what local first is about. 1214 01:09:36.720 --> 01:09:39.600 Okay, so this here, I just just bounce an idea 1215 01:09:40.760 --> 01:09:45.920 the promise, the promise of graphql but delivered as a 1216 01:09:46.000 --> 01:09:50.439 local API, because the allure of graphql was graphql is 1217 01:09:50.479 --> 01:09:53.359 going to handle the data manipulation for you. Graphql and 1218 01:09:53.439 --> 01:09:58.159 I think that the data, the ETL, the extract, transform load, 1219 01:09:58.239 --> 01:10:04.000 the sinking of day, the transforming logic. I believe that 1220 01:10:04.000 --> 01:10:07.119 that is classically a back end task. We could call 1221 01:10:07.159 --> 01:10:09.399 it the middle end. And I'm one hundred percent on 1222 01:10:09.439 --> 01:10:12.079 board with your classification of the middle end. There's like 1223 01:10:12.640 --> 01:10:16.840 the core API, the JSON where things kiss. That's the 1224 01:10:16.880 --> 01:10:20.199 middle end and that and that's where that's the problem 1225 01:10:20.199 --> 01:10:22.399 the graph Ql was kind of trying to solve. If 1226 01:10:22.439 --> 01:10:25.560 you if you move graph QL's complexity to the middle 1227 01:10:25.680 --> 01:10:28.800 end and you give people that are purely on the 1228 01:10:28.800 --> 01:10:34.039 front end the the autocomplete of graph ql with local storage. 1229 01:10:34.119 --> 01:10:35.880 I think I think maybe it wins. 1230 01:10:36.520 --> 01:10:39.600 Yeah, I'm I think you should go be a marketing 1231 01:10:39.680 --> 01:10:42.880 consultant for a number of the players in the space, 1232 01:10:42.960 --> 01:10:45.239 because that sounds very much like how they're trying to 1233 01:10:45.279 --> 01:10:51.319 sell this. They know that there's a significant pleasurable desired 1234 01:10:51.479 --> 01:10:54.760 DX around those types of models, and they're saying we 1235 01:10:54.800 --> 01:11:00.199 can repurpose those models and back them with much more 1236 01:11:00.239 --> 01:11:03.760 sophisticated things like a CRDT that's syncing out to a 1237 01:11:03.760 --> 01:11:04.840 cloud server or whatever. 1238 01:11:05.640 --> 01:11:09.199 Okay, well, yeah, give me their contact information. I'll see 1239 01:11:09.199 --> 01:11:13.600 what I can do. But yeah, I think graph kel 1240 01:11:13.720 --> 01:11:18.199 was always going to fail because it was solving the 1241 01:11:18.319 --> 01:11:20.880 problem fundamentally in the wrong way. It's saying, we're going 1242 01:11:20.960 --> 01:11:24.560 to reduce your data load by making more round trips 1243 01:11:24.560 --> 01:11:28.399 to the server all the time. If they had inverted that, 1244 01:11:28.600 --> 01:11:31.039 we're going to reduce your data load by doing large 1245 01:11:31.199 --> 01:11:35.880 batch fetches from the server and then updating ad hoc 1246 01:11:35.960 --> 01:11:39.159 when data is stale and giving you the same API 1247 01:11:39.239 --> 01:11:42.039 that graph ql gives you. That I think could have 1248 01:11:42.079 --> 01:11:44.239 been a winning strategy, and that that's really I think 1249 01:11:44.319 --> 01:11:46.439 that's compelling because I look at graph l, I look 1250 01:11:46.439 --> 01:11:48.279 at the promise of it, I look at those autocomplete 1251 01:11:48.319 --> 01:11:52.960 tools and think, man, I love it. I absolutely love it. 1252 01:11:54.079 --> 01:11:57.039 I just yeah, how do we? How do we? Maybe 1253 01:11:57.239 --> 01:12:00.800 maybe that could be the the poisoned apple or you know, 1254 01:12:01.119 --> 01:12:07.279 uh wrong term, but you know that the hook the addicts. 1255 01:12:07.439 --> 01:12:13.640 Thing, right. I think there's a tremendous amount of potential here, 1256 01:12:13.760 --> 01:12:18.479 and I just I want to re emphasize that local 1257 01:12:18.560 --> 01:12:23.399 first software development is, and especially local first web software 1258 01:12:23.439 --> 01:12:28.239 development is really just saying, let's take all the things 1259 01:12:28.279 --> 01:12:32.119 that we currently assume can only happen on a server 1260 01:12:32.920 --> 01:12:36.439 and ask how much of that could actually happen on 1261 01:12:36.479 --> 01:12:40.840 the client device. It's not saying if you like this framework, 1262 01:12:40.880 --> 01:12:42.960 you just have to give up because you've got no place. 1263 01:12:43.279 --> 01:12:49.119 In fact, it's saying the opposite. Bring whatever uh application 1264 01:12:49.279 --> 01:12:53.159 building techniques you have, but but build more of those 1265 01:12:53.199 --> 01:12:56.680 things into the client experience. The thicker client, to borrow 1266 01:12:56.720 --> 01:12:59.760 a term from the nineties, Build thicker clients that have 1267 01:12:59.880 --> 01:13:03.239 more of that stuff built in, and stop assuming that 1268 01:13:03.359 --> 01:13:05.960 the only place for data is up in a cloud server. 1269 01:13:06.159 --> 01:13:08.119 There's lots of other ways. And you asked you asked 1270 01:13:08.159 --> 01:13:11.199 earlier about like how do we you know is webs 1271 01:13:11.479 --> 01:13:14.960 is is web RTC or web sockets or whatever, like 1272 01:13:15.000 --> 01:13:17.359 how are we how are we gonna have apps? 1273 01:13:17.760 --> 01:13:17.960 Yeah? 1274 01:13:18.000 --> 01:13:20.079 How are we gonna have these client apps talking to 1275 01:13:20.119 --> 01:13:23.079 each other? So we do. We do definitely have web ertc. 1276 01:13:23.640 --> 01:13:25.319 The nice thing is that it's been around for a 1277 01:13:25.359 --> 01:13:28.039 long time. There's a lot of abstractions. The bad news 1278 01:13:28.119 --> 01:13:32.960 is that webertc never achieved its goal of zero server signaling. 1279 01:13:33.399 --> 01:13:37.600 It's zero server after the signaling, but it still requires 1280 01:13:37.680 --> 01:13:41.239 servers that can be quite expensive and quite uh single 1281 01:13:41.239 --> 01:13:44.319 point of failure for the signaling aspects because of all 1282 01:13:44.359 --> 01:13:46.680 the complexities of not traversial and stuff like that. 1283 01:13:48.399 --> 01:13:50.000 Just give it to you for free, though, I mean, 1284 01:13:50.079 --> 01:13:54.159 don't you just get to use Google's Chrome Chrome? So 1285 01:13:54.760 --> 01:13:56.920 if you're using Chrome, if it's in Chrome, if you 1286 01:13:56.960 --> 01:13:57.560 get that for free? 1287 01:13:57.640 --> 01:14:01.079 Right? Not really? So there's two without getting too much 1288 01:14:01.079 --> 01:14:03.800 into the rabbit hole, there's two standards. There's stun in turn. 1289 01:14:04.399 --> 01:14:06.920 One is used for the signaling, but one is used 1290 01:14:06.920 --> 01:14:09.560 for media. Really, which is what most people are trying 1291 01:14:09.560 --> 01:14:11.960 to do with ROBERTC is do media relay kind of 1292 01:14:11.960 --> 01:14:14.119 like the call that we're having here. They're trying to 1293 01:14:14.119 --> 01:14:17.600 do media relay, and media relay is absolutely not free 1294 01:14:17.720 --> 01:14:21.920 because it's very expensive to the provider. So the I 1295 01:14:21.960 --> 01:14:24.600 believe it's turn servers or the media relay I might 1296 01:14:24.640 --> 01:14:27.520 have that backwards. It's stun in turn. But whichever one 1297 01:14:27.560 --> 01:14:29.560 of those is the media relay servers, there are not 1298 01:14:29.680 --> 01:14:31.760 free ones. There are companies that you can pay for, 1299 01:14:32.119 --> 01:14:34.439 but it's you know, hundreds of dollars a month to 1300 01:14:34.479 --> 01:14:38.079 pay for a scaled out media relay server. Anyway, So 1301 01:14:38.199 --> 01:14:42.199 weber TC if we thought about it as one standard, 1302 01:14:42.319 --> 01:14:45.640 I think it's actually a really good API. But this 1303 01:14:46.359 --> 01:14:50.279 signaling problem is kind of the fly and the oightment 1304 01:14:50.399 --> 01:14:52.880 or the poisoned apple to borrow the term from you 1305 01:14:52.960 --> 01:14:57.640 from just a minute ago. But there are wrong There 1306 01:14:57.680 --> 01:15:04.199 are options for fixing the signaling issue. One of those 1307 01:15:04.279 --> 01:15:08.720 options is if you move from purely web into hybrid apps, 1308 01:15:08.720 --> 01:15:12.560 if you use those native wrappers with web views, things 1309 01:15:12.680 --> 01:15:17.560 like towry, things like electron, things like socket supply. These 1310 01:15:17.760 --> 01:15:20.479 these hybrid the old days it was like phone gap 1311 01:15:20.520 --> 01:15:23.039 and ionic and stuff. There's there's dozens of them, but 1312 01:15:23.079 --> 01:15:25.960 those native apps have the potential to kind of break 1313 01:15:25.960 --> 01:15:29.319 outside of the current restraints of the web and give 1314 01:15:29.399 --> 01:15:33.960 you true peer to peer communications through networking protocols. And 1315 01:15:34.000 --> 01:15:38.039 so there are multiple options there for a web app 1316 01:15:38.159 --> 01:15:41.920 to be given a slightly extra superpower, which is let 1317 01:15:41.920 --> 01:15:45.800 you communicate. There's also potentially, I really hope this happens, 1318 01:15:46.039 --> 01:15:48.680 there's a there's a working group working on a standard 1319 01:15:49.079 --> 01:15:53.800 for peer to peer local peer to peer communications which 1320 01:15:53.800 --> 01:15:56.840 would be able to tunnel between my two devices using 1321 01:15:56.880 --> 01:16:01.279 things like Bluetooth or local wife, which is a standard 1322 01:16:01.319 --> 01:16:06.720 that Android and iOS put together. So there are web 1323 01:16:06.760 --> 01:16:09.560 standards that maybe hopefully land someday that are going to 1324 01:16:09.640 --> 01:16:12.600 let us let our web apps talk directly peer to peer, 1325 01:16:12.880 --> 01:16:16.239 even without those native wrappers around them. But I do 1326 01:16:16.279 --> 01:16:20.439 think that that will for people that decide to go 1327 01:16:20.560 --> 01:16:23.359 that route. That's not local first, that's kind of beyond 1328 01:16:23.399 --> 01:16:26.800 local first. But when you go beyond local first to 1329 01:16:26.920 --> 01:16:29.680 trying to get closer to a peer to peer architecture 1330 01:16:29.720 --> 01:16:32.600 of an app, that's where you see the true benefit 1331 01:16:32.760 --> 01:16:36.720 of potentially shutting down your cloud server entirely and for 1332 01:16:36.840 --> 01:16:40.319 closing on your entire cloud bill, because most of what 1333 01:16:40.359 --> 01:16:43.359 you need to communicate with can actually tunnel over these 1334 01:16:43.439 --> 01:16:48.079 peer to peer networks, and so I think that's a 1335 01:16:48.079 --> 01:16:50.840 little bit further out from local first, but I think 1336 01:16:50.880 --> 01:16:53.039 it's a step along the way. I think local first, 1337 01:16:53.079 --> 01:16:54.439 and then that will come after that. 1338 01:16:54.800 --> 01:16:56.560 But then, how do you get people if you can't 1339 01:16:56.640 --> 01:16:59.279 ransom the data? How do you get people to pay? 1340 01:16:59.399 --> 01:17:01.199 How do you turn? How do you turn from users 1341 01:17:01.199 --> 01:17:01.760 to customers? 1342 01:17:03.039 --> 01:17:07.479 I'm used about this on my Twitter account a while back, 1343 01:17:07.520 --> 01:17:10.439 like that, are there any business models that are compelling 1344 01:17:11.079 --> 01:17:15.720 that are not based upon we hold you ransom? And 1345 01:17:15.760 --> 01:17:18.439 we brought up thirty seven signals. They are basically saying, 1346 01:17:18.720 --> 01:17:22.079 we're a successful business that is doing exactly that. You 1347 01:17:22.079 --> 01:17:25.239 pay a one time fee you license our software. It's 1348 01:17:25.319 --> 01:17:27.680 all your software, and it's all your data, and you 1349 01:17:27.720 --> 01:17:30.600 don't have to keep paying us a subscribe, a subscription 1350 01:17:30.800 --> 01:17:33.880 ransom fee. You have to be willing to think about 1351 01:17:33.880 --> 01:17:37.039 your business model potentially the way that we used to 1352 01:17:37.039 --> 01:17:41.079 think about business models, which is not how do I 1353 01:17:41.159 --> 01:17:45.199 capture as much possible value from every single user as 1354 01:17:45.640 --> 01:17:49.239 humanly you know you can imagine versus how do I 1355 01:17:49.279 --> 01:17:52.920 capture enough value that my business is viable and growing. 1356 01:17:54.000 --> 01:17:57.239 You have to somewhat restrain the greed when you design 1357 01:17:57.319 --> 01:17:58.319 business models that way. 1358 01:17:58.439 --> 01:18:03.319 I don't know that it's greed as much as it's hype. 1359 01:18:03.720 --> 01:18:06.479 And you need money. You need a lot of money, 1360 01:18:06.479 --> 01:18:10.600 you need a lot of time. So if you want 1361 01:18:10.600 --> 01:18:11.960 to get the money, you got to get the investment. 1362 01:18:12.000 --> 01:18:15.159 If you get the investment, you have to offer almost 1363 01:18:15.159 --> 01:18:17.920 everything for free because you need the drug. And if 1364 01:18:18.000 --> 01:18:21.199 you offer everything almost for free, then you'll never make 1365 01:18:21.239 --> 01:18:23.840 that money back in a one time payment because the 1366 01:18:23.880 --> 01:18:26.399 cost is too high. The investor won't get their return. 1367 01:18:26.479 --> 01:18:28.199 So you have to make it a subscription. I mean, 1368 01:18:28.359 --> 01:18:33.079 even when you look at the companies, the profitable companies Microsoft, Apple, 1369 01:18:33.079 --> 01:18:36.560 they're actually profitable and they're turning into subscription models because 1370 01:18:36.600 --> 01:18:40.560 it's the only way to grow. There's no growth opportunity left. 1371 01:18:40.560 --> 01:18:41.800 Word to capture the planet. 1372 01:18:42.239 --> 01:18:44.840 I don't agree that it's the only way to grow. 1373 01:18:45.359 --> 01:18:49.000 I agree that it is currently the most popular and 1374 01:18:49.079 --> 01:18:51.720 compelling way to grow. So how do you grow? 1375 01:18:51.800 --> 01:18:53.600 I don't captured everyone on the planet. 1376 01:18:54.239 --> 01:18:54.560 What's that? 1377 01:18:55.239 --> 01:18:57.760 How do you grow once you've captured everyone on the planet, 1378 01:18:57.760 --> 01:19:01.359 other than subdividing your services and turn them into subscriptions, 1379 01:19:01.479 --> 01:19:03.720 Because the only way you can't multiply, Like there's ten 1380 01:19:03.760 --> 01:19:06.760 billion people. You've caught all ten billion people, all ten 1381 01:19:06.800 --> 01:19:09.479 billion people have bought your product or use your service. 1382 01:19:09.560 --> 01:19:13.760 That can Facebook, Apple, whatever. How do you convert them? 1383 01:19:14.039 --> 01:19:17.119 It's either ads or it's subscriptions, because subscriptions you can 1384 01:19:17.159 --> 01:19:19.359 give them. Well, you know, we told you this was 1385 01:19:19.359 --> 01:19:21.920 the pro tier, but actually now there's the ultratier. We 1386 01:19:22.000 --> 01:19:25.119 told you was the ultratier, but four K is actually 1387 01:19:25.159 --> 01:19:26.920 moving to the Ultra plus tier. 1388 01:19:28.600 --> 01:19:31.479 Well, you know, I'm not going to answer. I'm not 1389 01:19:31.520 --> 01:19:34.600 going to give a very satisfying answer here, but it's 1390 01:19:34.680 --> 01:19:36.640 the best one I think we can fit into this 1391 01:19:36.720 --> 01:19:40.520 particular podcast episode, which is that's part of why the 1392 01:19:40.520 --> 01:19:43.000 Web three folks are saying, hey, pay attention to us, 1393 01:19:43.319 --> 01:19:46.680 because we have tried to come up with a decentralized 1394 01:19:46.920 --> 01:19:50.960 mechanism for monetization. I'm not here to shill for Web three. Yeah, 1395 01:19:51.119 --> 01:19:55.760 I know there might very well be useful ideas where 1396 01:19:55.960 --> 01:19:58.199 you know, I'm just going to give a crazy little example. 1397 01:19:58.239 --> 01:20:01.039 Let's imagine that I've built a calendar app, kind of 1398 01:20:01.079 --> 01:20:03.560 like what you know, thirty seven signals did they build 1399 01:20:03.560 --> 01:20:06.079 a calendaring app. I build a calendar app, and I 1400 01:20:06.279 --> 01:20:08.439 sell it for ten bucks and I let you run 1401 01:20:08.479 --> 01:20:10.399 all your own data. You can host it wherever you 1402 01:20:10.439 --> 01:20:12.760 want on a three dollars VM or whatever, and I 1403 01:20:12.760 --> 01:20:15.920 don't charge any subscription fee. But then let's imagine that 1404 01:20:16.000 --> 01:20:18.560 I come up with some really compelling cool thing, like 1405 01:20:18.880 --> 01:20:21.479 an AI summary of a calendar or something. I'm just 1406 01:20:21.520 --> 01:20:26.119 making something up. Well, I can deploy services out there 1407 01:20:26.159 --> 01:20:29.520 on the peer to peer web that, say, you can 1408 01:20:29.640 --> 01:20:32.920 choose on a per calendar event basis to opt into this, 1409 01:20:33.439 --> 01:20:35.840 and it's going to cost the equivalent of a dollar 1410 01:20:35.920 --> 01:20:40.319 of cryptocurrency transaction for you to have that data that 1411 01:20:40.399 --> 01:20:43.279 you send from your calendar send into this black box, 1412 01:20:43.760 --> 01:20:46.880 and then this smart contract sends you back your AI 1413 01:20:47.279 --> 01:20:50.319 summarized data or whatever. I'm just like, I'm literally making 1414 01:20:50.319 --> 01:20:52.920 something up on the fly. But I can monetize that way. 1415 01:20:53.000 --> 01:20:56.119 I could create services out there that people can choose 1416 01:20:56.159 --> 01:20:58.600 to use on an OLI cart basis. And if I 1417 01:20:58.680 --> 01:21:02.319 make those services is compelling enough and I make it 1418 01:21:02.359 --> 01:21:04.760 easy enough for people to pay for I think you 1419 01:21:04.880 --> 01:21:09.479 can grow without locking people into subscriptions. But I do 1420 01:21:09.720 --> 01:21:13.159 concede that the vast majority of the world, and basically 1421 01:21:13.199 --> 01:21:16.600 every investor in the world, is only interested right now 1422 01:21:16.640 --> 01:21:18.840 in the subscription based business models. 1423 01:21:19.439 --> 01:21:23.279 Yeah, and I just to touch on the Web three thing. 1424 01:21:23.840 --> 01:21:28.960 I think it's really unfortunate because I do see the 1425 01:21:28.960 --> 01:21:32.600 good ideas. The problem is one they called it Web 1426 01:21:32.680 --> 01:21:36.039 three as a gimmick because it's not the Web. What 1427 01:21:36.199 --> 01:21:39.720 they want is they want an alternate universe in which 1428 01:21:39.960 --> 01:21:42.239 it's kind of like rust right, like Russ. They want 1429 01:21:42.279 --> 01:21:45.640 an alternate universe in which programming is perfect without trade 1430 01:21:45.640 --> 01:21:49.399 offs other than the trade off of learning rust right, 1431 01:21:50.359 --> 01:21:53.800 but it and the Web three people they want this 1432 01:21:53.920 --> 01:21:58.560 perfect universe that literally can't exist because like first principles 1433 01:21:58.560 --> 01:22:03.479 and incompleteness theorem and but and so there. Instead of saying, Okay, 1434 01:22:03.479 --> 01:22:06.279 we're gonna we're gonna evolve the web. We're gonna take 1435 01:22:06.319 --> 01:22:08.560 what we have and we're gonna make it one step 1436 01:22:08.640 --> 01:22:12.880 towards our ideal, they're saying we're starting over from scratch, 1437 01:22:13.000 --> 01:22:15.600 but not just from scratch, like really from scratch, Like 1438 01:22:15.640 --> 01:22:18.359 we would get rid of TCP if we could, but 1439 01:22:18.520 --> 01:22:20.720 somehow we haven't figured out how to do that yet. 1440 01:22:21.800 --> 01:22:24.000 Like if the Web three people had their way, you 1441 01:22:24.039 --> 01:22:26.920 would have to buy a proprietary network card. And by 1442 01:22:27.000 --> 01:22:30.680 proprietary I mean not in accordance with any existing standard 1443 01:22:30.720 --> 01:22:34.079 and not useful to any other standard it would. 1444 01:22:34.159 --> 01:22:37.800 Can I can I briefly offer an alternate view of 1445 01:22:37.800 --> 01:22:41.479 that world, having spent a brief six months there. I'm 1446 01:22:41.600 --> 01:22:44.199 certainly not a spokesman for Web three, and I'm not 1447 01:22:44.319 --> 01:22:47.199 here to shill for some Web three coin or something, 1448 01:22:47.880 --> 01:22:53.479 but the underlying culture that I was exposed to in 1449 01:22:53.479 --> 01:22:55.239 that world when I was trying to learn it and 1450 01:22:55.319 --> 01:22:58.319 trying to figure out they hired me because they wanted 1451 01:22:58.319 --> 01:23:00.520 me to help bridge the gap from Web two to 1452 01:23:00.560 --> 01:23:02.680 Web three, and so I was trying to look at 1453 01:23:02.720 --> 01:23:06.920 it from that perspective, what's missing, what are they assuming 1454 01:23:07.039 --> 01:23:09.119 that's not true? And all of that. And one of 1455 01:23:09.119 --> 01:23:13.720 the things that I got from the culture that the 1456 01:23:13.760 --> 01:23:19.039 cyberpunk genre of writing seems to be an extremely important 1457 01:23:19.039 --> 01:23:22.119 part of the culture in Web three. And if you 1458 01:23:22.199 --> 01:23:24.600 read people like Neil Stevenson or whatever. I'm not a 1459 01:23:24.600 --> 01:23:26.560 big reader, but I did read a couple of his 1460 01:23:26.640 --> 01:23:29.720 books trying to get this mindset a little bit more 1461 01:23:29.960 --> 01:23:33.439 injected into mind. And if you read that, I think 1462 01:23:33.439 --> 01:23:37.439 they're actually saying something a bit opposite of what you're saying. 1463 01:23:37.920 --> 01:23:42.479 I think what they're saying is not we want an idealistic, 1464 01:23:42.800 --> 01:23:48.239 perfect world, but they assume that the world is inevitably 1465 01:23:48.319 --> 01:23:51.920 going to fall in on itself in its current track, 1466 01:23:52.359 --> 01:23:58.039 and the only way to avoid the certain doom. I'm 1467 01:23:58.119 --> 01:24:00.319 using really big words like I was a you know, 1468 01:24:00.359 --> 01:24:03.600 a writer. There's something there, but the only way to 1469 01:24:03.720 --> 01:24:08.399 avoid that is to jump to their view. So from 1470 01:24:08.600 --> 01:24:11.760 where from where we sit in a mostly functioning but 1471 01:24:12.159 --> 01:24:17.319 certainly not zero problem world, we look at them and say, oh, well, 1472 01:24:17.600 --> 01:24:19.680 those folks are just you know, they're pie in the 1473 01:24:19.720 --> 01:24:21.880 sky and they just they want things that are never 1474 01:24:21.920 --> 01:24:25.359 going to happen. It's completely naive and idealistic. But I 1475 01:24:25.399 --> 01:24:29.000 think their perspective is, man, you just don't even realize 1476 01:24:29.039 --> 01:24:31.840 that the track that you're on is already going to fail. 1477 01:24:31.880 --> 01:24:34.239 It's inevitable, and we're just trying to get as many 1478 01:24:34.239 --> 01:24:36.560 people to jump off that track before the train goes 1479 01:24:36.560 --> 01:24:37.239 off the rails. 1480 01:24:37.600 --> 01:24:42.800 That's that's our bridge. We need an off ramp, because 1481 01:24:42.840 --> 01:24:46.039 what they're asking is jump off the train one hundred 1482 01:24:46.079 --> 01:24:49.800 and fifty feet down into the gorge below, rather than 1483 01:24:50.319 --> 01:24:52.680 jump off to the train onto this nice little floating 1484 01:24:52.760 --> 01:24:54.199 ninja turtle blimp we have for you. 1485 01:24:54.800 --> 01:24:57.880 Right, But That's exactly why I left that space and 1486 01:24:57.920 --> 01:25:00.319 why I'm trying to build things that I I think 1487 01:25:00.359 --> 01:25:04.119 will constitute the gap, that will bridge the gap. And 1488 01:25:04.159 --> 01:25:06.800 I call it the web two point five. This idea 1489 01:25:06.880 --> 01:25:09.840 of owning your identity, this idea of promoting local first, 1490 01:25:09.840 --> 01:25:12.880 this idea of those are things that I think need 1491 01:25:12.960 --> 01:25:16.640 to happen if anybody's ever going to plausibly make that job, 1492 01:25:16.960 --> 01:25:17.920 that's my wible. 1493 01:25:19.079 --> 01:25:22.880 Okay, so I think we are we're at time for this. 1494 01:25:23.399 --> 01:25:26.239 I for those listening on, I actually want to continue 1495 01:25:26.239 --> 01:25:30.399 on with another segment, but I think so, I think 1496 01:25:30.439 --> 01:25:35.319 we need to wrap this one up can make so please. 1497 01:25:35.119 --> 01:25:39.439 Please one last plug around this space. So I have 1498 01:25:39.560 --> 01:25:42.800 been building pieces in the local first and the identity space, 1499 01:25:43.439 --> 01:25:46.239 and anybody who's followed me on social media has seen 1500 01:25:46.279 --> 01:25:51.800 me building libraries like, for example, the local vault library. 1501 01:25:52.159 --> 01:25:54.319 I'll I'll provide all of these links, but the local 1502 01:25:54.399 --> 01:25:57.319 vault library to use past keys to own your identity. 1503 01:25:57.520 --> 01:25:59.640 That's one set of effort that I'm trying to do 1504 01:25:59.760 --> 01:26:04.399 to to help create the things that other smarter people 1505 01:26:04.439 --> 01:26:07.800 will actually build real viable solutions around. I'm trying to 1506 01:26:08.800 --> 01:26:11.560 put together those local pieces. So that they can be used. 1507 01:26:12.000 --> 01:26:15.239 The other thing that I wanted to say, which is 1508 01:26:15.680 --> 01:26:20.039 related butt separate, which is a recent initiative that I 1509 01:26:20.079 --> 01:26:23.359 have around what's called what I call bring your Own JavaScript. 1510 01:26:24.359 --> 01:26:28.159 There has been a decidedly like anti framework tone to 1511 01:26:28.239 --> 01:26:30.920 our conversation, and I just want to state clearly for 1512 01:26:30.960 --> 01:26:34.800 the record, I am not anti framework. I am not 1513 01:26:35.119 --> 01:26:38.319 down with React and view sucks. The people who created 1514 01:26:38.319 --> 01:26:41.319 those things are far smarter than I am, and I 1515 01:26:41.359 --> 01:26:43.239 look up to them. I wish I was as good 1516 01:26:43.239 --> 01:26:46.439 an engineer as many of the people that design these systems, 1517 01:26:46.520 --> 01:26:49.600 and I'm glad they exist and they are solving things 1518 01:26:50.000 --> 01:26:52.880 in ways that many of our engineers in the industry 1519 01:26:53.239 --> 01:26:57.920 really appreciate their I am not the great spoke when 1520 01:26:57.960 --> 01:27:00.640 I say, I think there is a tremendous amount of 1521 01:27:00.720 --> 01:27:04.880 value there. But what we have lost is what I lament. 1522 01:27:05.119 --> 01:27:10.279 What we have lost is the appreciation of the importance 1523 01:27:10.359 --> 01:27:15.199 of understanding how the systems work under and how sometimes 1524 01:27:15.199 --> 01:27:18.359 those aren't the right answer. We've lost that appreciation, and 1525 01:27:18.399 --> 01:27:22.920 so BYOJS, bring your Own JavaScript is really designed to 1526 01:27:23.920 --> 01:27:27.560 not say down with frameworks and down with Typescript and 1527 01:27:27.560 --> 01:27:30.359 down with tools, but rather, let's carve out a separate 1528 01:27:30.399 --> 01:27:34.039 space where we can champion those who still believe that 1529 01:27:34.159 --> 01:27:39.239 those skills and techniques are important, and we can mutually 1530 01:27:39.239 --> 01:27:43.680 sit alongside the much bigger behemoth of the framework first 1531 01:27:44.279 --> 01:27:47.680 crowd the stuff. So I just wanted to plug the 1532 01:27:47.720 --> 01:27:52.279 stuff I'm trying to do around local vaults and using 1533 01:27:52.319 --> 01:27:55.720 past keys to create our identities and protect our data locally. 1534 01:27:56.000 --> 01:27:58.279 And then this Bring your Own JavaScript is trying to 1535 01:27:58.359 --> 01:28:03.720 champion JavaScript without the requirement to go very heavy on 1536 01:28:03.800 --> 01:28:07.439 framework and tooling. Those are things that I think will 1537 01:28:07.479 --> 01:28:12.520 be very important keys I hope in the local first movement. 1538 01:28:12.720 --> 01:28:15.399 But I don't own the local first movement in any way, right. 1539 01:28:15.520 --> 01:28:18.720 I'm one guy. I don't have a company in local first. 1540 01:28:18.760 --> 01:28:21.520 There are many many other people out there, so don't 1541 01:28:21.560 --> 01:28:24.439 I hope that people won't take my little slice of 1542 01:28:24.520 --> 01:28:28.760 thinking about local first as gospel. There's a tremendously big 1543 01:28:29.000 --> 01:28:33.119 community couple thousand people in the Discord community for the 1544 01:28:33.199 --> 01:28:35.359 Local First web dev which we'll have a link to. 1545 01:28:35.880 --> 01:28:39.000 I invite anybody that's curious about local first, even if 1546 01:28:39.039 --> 01:28:41.720 you totally disagree with how I've presented it, but you're 1547 01:28:41.760 --> 01:28:44.359 still curious, please come and join that community. Because there 1548 01:28:44.399 --> 01:28:46.960 is a big tent, there's a lot of room for 1549 01:28:47.039 --> 01:28:48.680 a lot of different ways of doing it. I just 1550 01:28:48.760 --> 01:28:51.640 have my own little tiny slice of how I'm trying 1551 01:28:51.640 --> 01:28:52.239 to go about it. 1552 01:28:52.880 --> 01:28:56.520 All right, Well, thank you for that, and again we're 1553 01:28:56.520 --> 01:28:59.159 gonna continue on with another segment. We're gonna wrap this 1554 01:28:59.199 --> 01:29:02.760 one up. Uh So, let's go ahead. We're going to 1555 01:29:02.800 --> 01:29:07.119 do picks. If you it sounds like you're not gonna 1556 01:29:07.119 --> 01:29:09.119 have any problem with that. I'm going to go ahead 1557 01:29:09.119 --> 01:29:12.680 and have Steve go first, because he I want to 1558 01:29:12.720 --> 01:29:16.239 be We've already not been sensitive to your time, so 1559 01:29:16.800 --> 01:29:18.520 I have go ahead and have you go first. 1560 01:29:18.560 --> 01:29:22.920 There, Steve, all right, so the uh my picks are 1561 01:29:23.000 --> 01:29:25.720 the highlight of any Javascriptaber episode, at least the ones 1562 01:29:25.760 --> 01:29:27.960 that I'm on with the dad jokes of the week. 1563 01:29:29.000 --> 01:29:32.640 So let's see this is sort of a visual one, 1564 01:29:32.640 --> 01:29:36.199 but I'll make it a little better. Fun fact, the 1565 01:29:36.279 --> 01:29:38.560 sentence are you as bored as I am? Can be 1566 01:29:38.600 --> 01:29:41.239 said backwards? Right? 1567 01:29:42.039 --> 01:29:42.199 Am? 1568 01:29:42.199 --> 01:29:44.399 I as bored as you are? Backwards? 1569 01:29:45.159 --> 01:29:45.479 Nice? 1570 01:29:47.319 --> 01:29:51.319 Second, I've been a bit bored lately myself, so I 1571 01:29:51.399 --> 01:29:54.439 decided to take up fencing. Man, are my neighbors mad 1572 01:29:54.439 --> 01:30:01.159 at me? And then Finally, this is a brother tasty question. 1573 01:30:02.199 --> 01:30:09.039 Why did the cannibal leave the restaurant? You got cold feet? 1574 01:30:09.840 --> 01:30:12.279 Oh that's so bad. That's so bad. 1575 01:30:14.279 --> 01:30:18.039 At least bring it out warmed up right right? Well, 1576 01:30:18.079 --> 01:30:18.279 you know. 1577 01:30:18.359 --> 01:30:22.840 The the similar question is is why did Jeffrey Dahmer 1578 01:30:23.000 --> 01:30:26.520 keep a blender on his porch? You'd like to greet 1579 01:30:26.560 --> 01:30:27.920 people with a warm handshake. 1580 01:30:30.319 --> 01:30:32.520 Oh that too soon? Too soon? 1581 01:30:33.039 --> 01:30:35.199 Sorry, Kyle, Kyle. 1582 01:30:36.840 --> 01:30:38.920 Oh, I feel icky inside right now. 1583 01:30:39.039 --> 01:30:41.079 Oh that's gross. Please don't do that against Steve. 1584 01:30:42.199 --> 01:30:42.840 All right, great? 1585 01:30:43.199 --> 01:30:43.319 Uh? 1586 01:30:43.720 --> 01:30:45.399 Any was there anything else on that, Steve? Are we 1587 01:30:45.399 --> 01:30:46.439 ready to move on to Kyle? 1588 01:30:46.960 --> 01:30:47.640 Ready to move on? 1589 01:30:48.399 --> 01:30:48.800 All right? Oh? 1590 01:30:48.840 --> 01:30:50.680 Wait, No, we do the We do the guest last. 1591 01:30:50.760 --> 01:30:52.399 That's how we do it. See, it's been so long. 1592 01:30:52.439 --> 01:30:56.119 I'm rusty moving from me. Yeah, I am moving on 1593 01:30:56.199 --> 01:30:59.239 from you. That is that is what I'm doing, all right. 1594 01:30:59.319 --> 01:31:04.479 So the thing that I want to pick is gonna 1595 01:31:04.520 --> 01:31:09.199 be Oh I have to oh oh, Utah JAS conference, 1596 01:31:09.319 --> 01:31:12.319 Utah JAS conference. The videos have dropped. So if you 1597 01:31:12.359 --> 01:31:15.960 want to watch the Utah JS stuff, the videos have dropped. 1598 01:31:16.319 --> 01:31:22.359 And I'm gonna Utah JS COMF twenty twenty four. I 1599 01:31:22.720 --> 01:31:27.000 thought it was a great conference because I think this 1600 01:31:27.079 --> 01:31:30.039 is the second year in a row that I'm seeing 1601 01:31:31.079 --> 01:31:33.520 the glaze coming off of people's eyes or no, that's 1602 01:31:33.520 --> 01:31:35.760 not the right expression. People are starting to. 1603 01:31:35.680 --> 01:31:36.159 See the light. 1604 01:31:36.520 --> 01:31:39.680 Like the scales, the scales, the scales are coming off 1605 01:31:39.680 --> 01:31:43.760 people's eyes and they're starting to see the light. Because 1606 01:31:43.760 --> 01:31:48.039 there were so many great talks that were hey, maybe 1607 01:31:48.399 --> 01:31:50.520 we could do this in a simpler way. One of 1608 01:31:50.560 --> 01:31:54.199 the ones that I absolutely loved was I forget his 1609 01:31:54.279 --> 01:31:59.199 first name is something delaney. I think he gave a 1610 01:31:59.239 --> 01:32:04.239 presentation on the thing that caught my eye about it 1611 01:32:04.319 --> 01:32:07.079 was server side events. And it turns out you can 1612 01:32:07.079 --> 01:32:11.279 implement server side events and literally in a tweet, actual 1613 01:32:11.319 --> 01:32:15.000 functional server side events will fit in a tweet. Well, okay, 1614 01:32:15.039 --> 01:32:17.760 I put it in an image in a tweet, but anyway, Yeah, 1615 01:32:17.840 --> 01:32:22.199 and I'll give that too. And I would look up 1616 01:32:22.239 --> 01:32:23.640 the name, but I don't want to take up too 1617 01:32:23.680 --> 01:32:26.760 much time what what the actual talk was called. But 1618 01:32:28.119 --> 01:32:32.119 let's see sc in a tweet. Where did my tweet go? Oh, 1619 01:32:32.159 --> 01:32:35.600 I don't have it, but there's that. Okay, that's not 1620 01:32:35.960 --> 01:32:40.479 that's oops that that RL went nasty but oops? Okay, anyway, 1621 01:32:41.439 --> 01:32:45.439 so yeah, those those are those are two things that 1622 01:32:45.520 --> 01:32:47.479 I'm going to pick right now, I've got I've got 1623 01:32:47.520 --> 01:32:49.680 a couple other picks. Maybe I'll pick in the next segment. 1624 01:32:49.720 --> 01:32:53.680 But that's utah JAS conference. Go take a look on YouTube. 1625 01:32:53.680 --> 01:32:55.720 I just put the link in here, but if you 1626 01:32:55.720 --> 01:33:00.079 look up utah js on on YouTube. The conference, I 1627 01:33:00.119 --> 01:33:02.239 really really thought there were some great talks. There was 1628 01:33:02.239 --> 01:33:04.920 one that was the one hundred year web app how 1629 01:33:04.960 --> 01:33:07.760 to choose technology that will survive that you know, if 1630 01:33:07.800 --> 01:33:10.520 you if you if somehow it's still hosted in one 1631 01:33:10.560 --> 01:33:12.720 hundred years, it would still work in one hundred years. 1632 01:33:13.560 --> 01:33:15.479 I thought that was talking was actually so many excellent 1633 01:33:15.560 --> 01:33:18.479 talks is here because it was it was getting away 1634 01:33:18.520 --> 01:33:20.840 from I mean, there was still some framework hype there, 1635 01:33:20.840 --> 01:33:22.880 but it was getting away from framework hype and it 1636 01:33:22.920 --> 01:33:26.960 was getting back to not necessarily back to basics, like 1637 01:33:26.960 --> 01:33:29.520 service side events wouldn't necessarily say basics. But it was 1638 01:33:29.600 --> 01:33:31.560 mind blowing to find out how simple they are in 1639 01:33:31.600 --> 01:33:35.279 comparison to web sockets, how performant they are, and see 1640 01:33:36.199 --> 01:33:38.680 that that demo that was done, and there was there 1641 01:33:38.720 --> 01:33:40.119 was three or four talks I went to where I 1642 01:33:40.119 --> 01:33:43.439 was just blown away with I learned stuff and stuff 1643 01:33:43.479 --> 01:33:45.199 that I feel is valuable that I'm going to use, 1644 01:33:46.319 --> 01:33:49.159 and I don't often feel that way about the hype stuff, 1645 01:33:49.199 --> 01:33:51.640 but I mean a lot of that's my attitude. But anyway, 1646 01:33:51.760 --> 01:33:53.960 so I got that, Kyle, what are your picks? 1647 01:33:54.880 --> 01:34:00.880 I'll just do one similar to but not the same. 1648 01:34:00.920 --> 01:34:04.399 And this is not something I created. But the last 1649 01:34:04.439 --> 01:34:07.960 couple of days a new initiative is launched called the 1650 01:34:08.039 --> 01:34:12.399 Pure Web Foundation, and you can get to it at 1651 01:34:12.439 --> 01:34:16.960 pureweb dot dev if you're interested. But the Pure Web 1652 01:34:17.000 --> 01:34:21.520 Foundation's goal is too similar to b yojs, is to 1653 01:34:21.720 --> 01:34:26.960 champion building with the web platform without frameworks and tools 1654 01:34:26.960 --> 01:34:31.399 necessarily layered on top. It's an attempt to kind of 1655 01:34:32.199 --> 01:34:35.640 maybe even rediscover the way the web was built before 1656 01:34:35.720 --> 01:34:39.119 we were taken over by those things. I'm very excited 1657 01:34:39.159 --> 01:34:41.800 about that, and I hope more people will kind of 1658 01:34:41.840 --> 01:34:44.880 give it a look and kick the tires on this. 1659 01:34:45.159 --> 01:34:47.760 They're going, we're a lot of resources that we're going 1660 01:34:47.840 --> 01:34:49.640 to try to create for it. So it's not about 1661 01:34:50.159 --> 01:34:53.159 creating code or libraries, but about creating resources that help 1662 01:34:53.319 --> 01:34:53.960 educate around that. 1663 01:34:54.119 --> 01:34:57.760 So all right, well, thanks for that, and it has 1664 01:34:57.840 --> 01:35:00.760 been a pleasure having you so so far. Thank you 1665 01:35:00.840 --> 01:35:03.399 so much for coming on and talking about this, and 1666 01:35:03.399 --> 01:35:07.079 and uh glad that we get to have some warm disagreements. 1667 01:35:08.520 --> 01:35:10.760 I think that always makes an episode a lot better. 1668 01:35:10.960 --> 01:35:13.680 And I'm glad that you were able to defend your 1669 01:35:13.720 --> 01:35:17.079 position because I'm gonna say something that I don't normally say. 1670 01:35:17.119 --> 01:35:21.079 Sometimes if people don't defend their position, I just don't 1671 01:35:21.119 --> 01:35:27.560 ask the next question. So, Okay, I don't want to 1672 01:35:27.600 --> 01:35:32.279 be abrasive, but like when people defend the position, then 1673 01:35:32.279 --> 01:35:36.279 that gives me the ability to dig deeper. Sure, so 1674 01:35:37.560 --> 01:35:38.119 thank you for that. 1675 01:35:38.720 --> 01:35:41.000 Yeah, I've enjoyed It's been a good, lively debate, so 1676 01:35:41.039 --> 01:35:42.960 thanks for having me, all right, And with. 1677 01:35:43.000 --> 01:35:46.119 That, those of you are online, stay tuned, but for 1678 01:35:46.239 --> 01:35:54.239 this being cut for podcast release. Audios, everybody,