WEBVTT 1 00:00:05.519 --> 00:00:09.400 Hey folks, welcome back to another episode of JavaScript Jabber. 2 00:00:09.560 --> 00:00:11.720 This week, I'm your host, Charles Maxwood, and we are 3 00:00:11.759 --> 00:00:15.839 talking to Delaney Gillileen. We're going to be talking about 4 00:00:15.960 --> 00:00:18.079 how everybody's doing the front end wrong and how it's 5 00:00:18.079 --> 00:00:21.160 super slow because we all do it wrong. So do 6 00:00:21.160 --> 00:00:23.920 you want to introduce yourself and we can dive in 7 00:00:24.079 --> 00:00:26.519 and talk about how we could do it better. 8 00:00:27.039 --> 00:00:27.320 Sure. 9 00:00:27.480 --> 00:00:30.079 Yeah, as you said, my name is Delaney. 10 00:00:30.199 --> 00:00:32.039 I have a kind of a weird background. 11 00:00:32.079 --> 00:00:34.479 I've done a lot of stuff in game development, military 12 00:00:34.520 --> 00:00:37.000 applications and all that, and I've always found that the 13 00:00:37.200 --> 00:00:41.359 web is an amazing sandbox for doing security and deployment 14 00:00:41.399 --> 00:00:44.359 and so it's almost its own little os and I 15 00:00:44.399 --> 00:00:46.799 love the ideas of it, and I've done some pretty 16 00:00:47.119 --> 00:00:51.000 big applications in it, but I've always had this weird ditch. 17 00:00:50.880 --> 00:00:54.560 That things are being done wrong. I really had. 18 00:00:54.399 --> 00:00:58.280 Issues with spas and how you're basically sitting down in 19 00:00:58.320 --> 00:01:01.359 all your state and Jason and recreating the world each 20 00:01:01.439 --> 00:01:04.799 time you do an update, and so I started getting 21 00:01:04.840 --> 00:01:08.359 into hypermedia and the HDMX stuff, but I ran into 22 00:01:08.359 --> 00:01:10.920 issues with that too, and long story short, I ended 23 00:01:10.959 --> 00:01:14.079 up with my own framework called data Star that is 24 00:01:14.120 --> 00:01:17.519 trying to solve all those things of being there's the 25 00:01:17.680 --> 00:01:21.280 line of like the MPa style of HTMX, and then 26 00:01:21.319 --> 00:01:23.959 there's the SPAS and I think we really are on 27 00:01:24.040 --> 00:01:26.760 a different plane. We're doing stuff that's not in between. 28 00:01:26.799 --> 00:01:29.719 We're doing both and more. So okay, I can talk 29 00:01:29.719 --> 00:01:31.359 about it. Yeah, it makes sense. 30 00:01:31.920 --> 00:01:35.000 My weapon of choice in this space is Turbo, which 31 00:01:35.079 --> 00:01:36.599 is part of hot Wire, and. 32 00:01:36.519 --> 00:01:37.319 It does a lot. 33 00:01:37.959 --> 00:01:40.920 It doesn't do exactly what HTMX does. You know, the 34 00:01:40.920 --> 00:01:43.920 same kind of idea where you're you know, you're streaming data, 35 00:01:44.239 --> 00:01:47.280 you know, back and forth and you only rerender what 36 00:01:47.319 --> 00:01:50.959 you got back and it sends back HTML instead of JSON, 37 00:01:51.159 --> 00:01:54.200 and so it doesn't have to go and figure out 38 00:01:54.280 --> 00:01:57.280 what all of your components are and then redraw it 39 00:01:57.400 --> 00:01:58.280 like React does. 40 00:01:58.799 --> 00:02:01.560 Well, if if you've Turbo, then I've already worked with 41 00:02:01.599 --> 00:02:03.959 mckel and the guys over the Turbo team to work 42 00:02:03.959 --> 00:02:06.560 on a new version of the morphs stuff. So we 43 00:02:06.640 --> 00:02:10.599 actually use uh vomit. Yeah, we have our own version 44 00:02:10.599 --> 00:02:13.080 that we started from working with Michael. In fact, he 45 00:02:13.240 --> 00:02:15.879 was on our podcast a while ago and we worked 46 00:02:15.879 --> 00:02:17.960 on that for quite a while. But we have the 47 00:02:17.960 --> 00:02:19.840 fastest morph being strategy in the world. So if you've 48 00:02:19.840 --> 00:02:22.479 already used turbo, are getting some of the benefit, You 49 00:02:22.639 --> 00:02:24.159 getting some of the benefits of the work that has 50 00:02:24.199 --> 00:02:25.479 been done in data ironically. 51 00:02:25.560 --> 00:02:26.120 Oh interesting. 52 00:02:26.280 --> 00:02:29.039 So yeah, so it sounds like there's a story here 53 00:02:29.120 --> 00:02:31.039 right where you're saying, Hey, I wanted to do a 54 00:02:31.080 --> 00:02:34.319 thing and the tools out there were not the best 55 00:02:34.319 --> 00:02:36.240 tools for it, or I thought there could be better 56 00:02:36.280 --> 00:02:37.879 tools for it. Do you do you kind of want 57 00:02:37.919 --> 00:02:40.439 to just back up and give us some conflict on 58 00:02:40.479 --> 00:02:41.599 where this all came from. 59 00:02:41.759 --> 00:02:44.000 Yeah, So I was working on a project and it 60 00:02:44.120 --> 00:02:46.840 ended up being in view and mostly three D. So 61 00:02:46.919 --> 00:02:50.039 project was basically a military thing where we sent every 62 00:02:50.120 --> 00:02:52.840 radar blip from every radar station in the continental United 63 00:02:52.879 --> 00:02:56.439 States in real time to the browser, and they wanted 64 00:02:56.439 --> 00:02:57.879 to be able to scrub back in time over and 65 00:02:57.919 --> 00:03:02.000 now like live. So you're talking about a million updates 66 00:03:02.039 --> 00:03:04.479 per secon about nine hundred thousand updates per second and 67 00:03:04.719 --> 00:03:06.879 being able to scrupt to any point in time within 68 00:03:07.360 --> 00:03:09.840 a second to any point in time. So that's a 69 00:03:09.879 --> 00:03:12.719 hard problem if you don't know, like, that's a lot 70 00:03:12.759 --> 00:03:14.360 of buffers and a lot of gl stuff. 71 00:03:14.400 --> 00:03:16.560 And so I'm mostly a web guy like my backgrounds 72 00:03:16.560 --> 00:03:16.919 in three D. 73 00:03:17.120 --> 00:03:19.800 So I was knocking that out and I was like, man, 74 00:03:19.840 --> 00:03:21.280 there's got to be a better way because I'm basically 75 00:03:21.319 --> 00:03:23.400 sending all this spas. You're sending the entire state of 76 00:03:23.400 --> 00:03:26.280 your application to the front end. All your state lives there, 77 00:03:26.319 --> 00:03:28.280 and then you're trying to keep those the state of 78 00:03:28.280 --> 00:03:30.639 the back end the front end in sync. Right on 79 00:03:30.800 --> 00:03:34.199 sort shirt, I started searching around more to do different things. 80 00:03:34.479 --> 00:03:36.960 HTMX I thought was a really interesting idea in that 81 00:03:37.039 --> 00:03:39.639 it's going back to kind of hypermedia of the two thousands. 82 00:03:40.599 --> 00:03:42.680 But one of the things I ran into is that 83 00:03:42.800 --> 00:03:45.759 A it wasn't fast enough and B it didn't include 84 00:03:45.800 --> 00:03:47.159 things like the morphing out of the box. 85 00:03:47.280 --> 00:03:48.840 So I was like, well, why isn't that included? 86 00:03:48.919 --> 00:03:49.919 And then I was like, well, I want to be 87 00:03:49.960 --> 00:03:51.599 able to pick and choose, because some of the choices 88 00:03:51.639 --> 00:03:53.439 they made I didn't think were very good. So I 89 00:03:53.479 --> 00:03:55.520 wanted to have a plugin system. They have extensions, which 90 00:03:55.520 --> 00:03:57.520 means you can add stuff on top of HTMX. Right, 91 00:03:57.639 --> 00:04:00.680 you can't replace anything in HTMX right, it's its one 92 00:04:00.680 --> 00:04:02.719 big five K file and you kind of left with it. 93 00:04:02.800 --> 00:04:04.960 So I went through and said, okay, if I was 94 00:04:04.960 --> 00:04:07.280 writing a game engine but for the web, what would 95 00:04:07.319 --> 00:04:09.560 that look like, Everything being module, everything being kind of 96 00:04:09.560 --> 00:04:12.280 an ECS style, like a different way of looking at 97 00:04:12.280 --> 00:04:15.080 it from a data oriented perspective. And so once I 98 00:04:15.080 --> 00:04:17.959 started getting into it, it long over time basically morphed 99 00:04:18.000 --> 00:04:20.639 into its own thing. But in data Star, for example, 100 00:04:20.759 --> 00:04:23.360 everything is a plug in, literally everything, And one of 101 00:04:23.360 --> 00:04:25.839 the major plugins that we have is this thing that 102 00:04:25.879 --> 00:04:29.199 does service set events. And people really have not understood 103 00:04:29.199 --> 00:04:31.439 service set events, and they think it has to be 104 00:04:31.519 --> 00:04:33.079 a stream, it has to be this extra cough thing. 105 00:04:33.439 --> 00:04:35.639 All it is is a chunked response and that's it. 106 00:04:35.680 --> 00:04:38.000 That's literally all it is. It's a data type, which 107 00:04:38.040 --> 00:04:40.279 means as soon as you can send down a response 108 00:04:40.399 --> 00:04:42.839 with it data event, you can send down signals, you 109 00:04:42.839 --> 00:04:45.439 can send down elements, you can send down different parts 110 00:04:45.439 --> 00:04:47.439 of the page, so things like HTMX. 111 00:04:47.480 --> 00:04:49.720 It's a kind of a it's not the norm to 112 00:04:49.879 --> 00:04:50.519 say I'm going to. 113 00:04:50.480 --> 00:04:51.639 Update this part of the page or this part of 114 00:04:51.639 --> 00:04:53.040 the page, or I want to pin this signal, I 115 00:04:53.079 --> 00:04:55.439 want to merge this thing like you kind of do 116 00:04:55.560 --> 00:04:58.399 a whole Just the way it works doesn't kind of 117 00:04:58.439 --> 00:05:00.680 jive with what I wanted to do. Basically just sat 118 00:05:00.720 --> 00:05:03.439 down and started writing out these pieces and lo and 119 00:05:03.519 --> 00:05:06.519 behold ended up being way smaller. So, for example, we 120 00:05:06.560 --> 00:05:09.639 include the fastest signal library in the world. It's built 121 00:05:09.680 --> 00:05:12.040 off alien signals if you're into that space at all, 122 00:05:12.079 --> 00:05:15.040 and we have the fastest moreporting library by far, and 123 00:05:15.120 --> 00:05:16.120 we're ten kilobytes. 124 00:05:16.160 --> 00:05:16.480 Wow. 125 00:05:17.240 --> 00:05:20.240 Yeah, the whole thing, And so it's a pretty crazy 126 00:05:20.279 --> 00:05:23.000 thing that we basically just if you don't rely on 127 00:05:23.079 --> 00:05:26.360 other people's lives, everything's there's no MPM, there's no vendoring. 128 00:05:26.800 --> 00:05:29.120 It's just all written for those specific needs. So every 129 00:05:29.160 --> 00:05:32.120 plugin is completely independent, and it makes it so that 130 00:05:32.160 --> 00:05:34.959 it's really fast, really small and really tight code, and 131 00:05:34.959 --> 00:05:36.839 then you don't have to think about it anymore, which 132 00:05:36.879 --> 00:05:38.560 is kind of a neat thing. And also we're the 133 00:05:38.600 --> 00:05:41.279 only one that's really relying on the specs. So there's 134 00:05:41.279 --> 00:05:43.800 a thing that's built into the to the HTML specs 135 00:05:43.839 --> 00:05:46.079 called data dash Star, which basically allows you to put 136 00:05:46.160 --> 00:05:46.879 data astributes. 137 00:05:47.199 --> 00:05:49.199 So data star is just. 138 00:05:49.279 --> 00:05:52.560 Hooking into that and reading up the key value store 139 00:05:52.560 --> 00:05:56.240 that it gives you and then implementing its own modifications 140 00:05:56.240 --> 00:05:58.800 and stuff. So basically everything is like data dash class 141 00:05:58.879 --> 00:06:01.040 data dash on, data dash load these. 142 00:06:00.959 --> 00:06:01.560 Kinds of things. 143 00:06:01.720 --> 00:06:04.279 So we're living within the spec So it's not that 144 00:06:04.319 --> 00:06:07.920 we're trying to replace it with a whole new spa 145 00:06:08.040 --> 00:06:10.319 framework or something. We're literally just using the things that 146 00:06:10.399 --> 00:06:12.360 already built into the browser, which means that we're very 147 00:06:12.360 --> 00:06:14.639 small and very fast, because the fastest thing you can 148 00:06:14.680 --> 00:06:15.560 do a jobascript is not. 149 00:06:15.560 --> 00:06:16.800 Do jobascript, I'm true. 150 00:06:17.480 --> 00:06:22.120 So I guess you know, seeing this particular use case, 151 00:06:22.160 --> 00:06:24.600 you know, or you've got millions of you know, blips 152 00:06:24.639 --> 00:06:27.560 on radars across the US, and you know kind of 153 00:06:27.600 --> 00:06:29.560 doing a lot of that real time stuff, which I 154 00:06:29.560 --> 00:06:31.480 think is a different thing. You probably handle a lot 155 00:06:31.519 --> 00:06:33.160 of that on the back end, but then making it 156 00:06:33.199 --> 00:06:34.600 all show up the way that you need it to 157 00:06:34.720 --> 00:06:37.399 on the front end is the challenge we're talking about. 158 00:06:37.639 --> 00:06:39.560 Is this something that you would recommend just for people 159 00:06:39.600 --> 00:06:41.399 who are doing that kind of a thing, or is 160 00:06:41.439 --> 00:06:44.279 this a better fit for other problems as well. 161 00:06:44.959 --> 00:06:47.199 Yeah, so I think that the way the Data Start 162 00:06:47.279 --> 00:06:50.360 builds things now is the best way to build the 163 00:06:50.399 --> 00:06:51.560 websites barn On. 164 00:06:51.639 --> 00:06:53.240 And the reason why is people. 165 00:06:53.000 --> 00:06:54.560 Say, well, yeah, I'm not building a game, I'm not 166 00:06:54.600 --> 00:06:56.839 building will time stuff. Yeah, but if it can handle that, 167 00:06:57.319 --> 00:06:59.959 then it can handle your other issues so much EASi. 168 00:07:00.279 --> 00:07:02.759 So for example, there's a one of our. 169 00:07:02.720 --> 00:07:06.000 Users made a it's really a rendering demo because it's 170 00:07:06.000 --> 00:07:08.199 the dumbest way to build this kind of thing. But 171 00:07:08.240 --> 00:07:10.639 he took the Game of Life and he made every 172 00:07:10.680 --> 00:07:14.040 cell a DIV and then colored the div with CSS, 173 00:07:14.079 --> 00:07:16.600 and then when you click on it, it updates to this, so. 174 00:07:16.600 --> 00:07:17.680 You have twenty five hundred divs. 175 00:07:17.720 --> 00:07:20.120 He's updating in it like between five and ten primes 176 00:07:20.160 --> 00:07:22.680 a second, and it's it's a shared state, so everyone 177 00:07:22.720 --> 00:07:24.279 in the world's he's the exact same version of it 178 00:07:24.360 --> 00:07:28.800 at all times, and it's rendering in like eight milliseconds, 179 00:07:28.879 --> 00:07:30.920 So if you can handle twenty five hundred dives, yeah, 180 00:07:30.959 --> 00:07:33.519 So it's it's fast enough that it's just a non 181 00:07:33.560 --> 00:07:35.399 issue for what you're doing. And the other thing that's 182 00:07:35.399 --> 00:07:37.639 interesting about this approach, which we can get into, is 183 00:07:37.639 --> 00:07:40.920 that he's not sitting down new like if you were 184 00:07:40.959 --> 00:07:42.480 doing that in a normal spot, you would be sitting 185 00:07:42.519 --> 00:07:43.800 on Jason all the time. 186 00:07:44.959 --> 00:07:48.360 He's sending down the finished HTML. 187 00:07:48.480 --> 00:07:49.959 But the thing is, like, for example, in a Game 188 00:07:50.000 --> 00:07:52.439 of Life, it's not that different from the last approach 189 00:07:52.600 --> 00:07:55.160 so he's getting between four and five to one compression 190 00:07:55.240 --> 00:07:56.920 ratios with no extra effort. 191 00:07:57.360 --> 00:07:59.199 So he ended up being on. 192 00:07:59.160 --> 00:08:01.959 The top of Hacker new Is on a five or 193 00:08:02.000 --> 00:08:04.519 ten dollars machine and it ran fine. 194 00:08:04.639 --> 00:08:06.959 Yeah, that makes sense because essentially what you're doing is 195 00:08:07.000 --> 00:08:10.120 you're saying, instead of here's the whole Game of Life 196 00:08:10.120 --> 00:08:14.680 board visible space, you can just say, hey, these handful 197 00:08:14.720 --> 00:08:18.040 of ones are the ones that got updated right, changed color. 198 00:08:18.079 --> 00:08:20.079 Well, so here's the thing that's really nice is that 199 00:08:20.079 --> 00:08:22.240 he's sitting down in that case, all twenty five hundred 200 00:08:22.240 --> 00:08:24.439 dips because it's fifty by fifty grid, he's sitting all 201 00:08:24.480 --> 00:08:27.240 of them down every single time. Oh really, because yeah, 202 00:08:27.319 --> 00:08:28.920 So the thing is you just think about it as 203 00:08:28.920 --> 00:08:32.799 this big fat morph and it is smart enough to say, hey, 204 00:08:32.879 --> 00:08:34.759 I already had a compression window that had bits and 205 00:08:34.759 --> 00:08:37.120 pieces of it, so you mentally can. 206 00:08:36.960 --> 00:08:38.120 Think of it. It does. 207 00:08:38.200 --> 00:08:40.919 Yeah, that's what the morphdomb and also the Broadley compression 208 00:08:40.919 --> 00:08:42.600 and all these things, like we've thought about this stuff 209 00:08:42.600 --> 00:08:44.679 at a deep level where we can send down things. 210 00:08:44.679 --> 00:08:46.159 So if you had a board that you know how 211 00:08:46.240 --> 00:08:47.759 in Game of Life, if it's just sitting there kind 212 00:08:47.759 --> 00:08:50.240 of switched between two states, like if it gets to 213 00:08:50.240 --> 00:08:52.679 a stable state, that change over since it's already in 214 00:08:52.679 --> 00:08:55.360 the window of the Broadley stuff is like twelve bytes 215 00:08:55.639 --> 00:08:58.559 bytes twelve bytes, so sending down twenty five hundred things 216 00:08:58.600 --> 00:09:01.399 just a twelve byte change. Depending on how much data 217 00:09:01.399 --> 00:09:04.399 that is shared in your updates, you can get these 218 00:09:04.440 --> 00:09:06.679 crazy compression rangions, like we've seen up to four thousand 219 00:09:06.679 --> 00:09:09.519 and one compression. So it's better than web sockets because 220 00:09:09.519 --> 00:09:11.440 you get all this compression stuff, you get the proper 221 00:09:11.480 --> 00:09:13.759 headers and cookies and all that stuff. It's better than 222 00:09:13.919 --> 00:09:17.120 standard crud stuff because you're halfing your polling. So instead 223 00:09:17.120 --> 00:09:19.480 of requesting something and getting back and requesting something and 224 00:09:19.480 --> 00:09:21.879 getting it back, we're having that RTT because we can 225 00:09:21.879 --> 00:09:23.799 just send down as we decide on the back end 226 00:09:23.879 --> 00:09:25.240 right when you need it, so you can send it 227 00:09:25.279 --> 00:09:27.159 every second or speed it up or slow it down, 228 00:09:27.240 --> 00:09:30.080 it does not matter. Everything else works the same. So 229 00:09:30.360 --> 00:09:32.600 it is by far the best way to build any website. 230 00:09:32.679 --> 00:09:34.679 And I will take on anyone with that challenge. 231 00:09:34.720 --> 00:09:36.679 So let me kind of back up a little bit 232 00:09:36.679 --> 00:09:38.600 because I know that a lot of people, you know, 233 00:09:38.879 --> 00:09:41.440 if they're doing front end, so and to give you 234 00:09:41.440 --> 00:09:43.600 a little bit of a context. I mean, my weapon 235 00:09:43.600 --> 00:09:46.039 of choice again, like I said, is the hot wire stack. 236 00:09:46.120 --> 00:09:49.600 So I'm usually using something like stimulus and so and it. 237 00:09:49.759 --> 00:09:52.039 You know, you're talking about the data attributes and stuff, 238 00:09:52.080 --> 00:09:55.120 and stimulus just basically gives you a convention on top 239 00:09:55.159 --> 00:09:57.879 of that to you know, to scope your changes. 240 00:09:58.480 --> 00:09:59.679 And to track your events. 241 00:10:00.519 --> 00:10:03.759 So I guess what I'm wondering here is, you know, 242 00:10:04.200 --> 00:10:06.480 you've talked about a game of life. You've talked about 243 00:10:06.759 --> 00:10:08.679 so those are both kind of visual things. I mean, 244 00:10:08.759 --> 00:10:11.399 I guess the one is kind of a poor man's 245 00:10:11.519 --> 00:10:14.120 you know, pixelated thing, and then the other one is 246 00:10:14.159 --> 00:10:18.039 like a full on what is it, you know, just 247 00:10:18.080 --> 00:10:22.960 a graphical visualization of the radar and things. 248 00:10:23.360 --> 00:10:26.440 So is there is there a data driven you know. 249 00:10:26.480 --> 00:10:30.120 You know, dashboard or user interface or admin panel or 250 00:10:30.159 --> 00:10:32.000 something like that that's been built with data Star. 251 00:10:32.639 --> 00:10:32.840 Yeah. 252 00:10:33.200 --> 00:10:35.600 The thing is I work at Sanadia on that's as 253 00:10:35.720 --> 00:10:38.600 a day job, and so I'm building literally that right 254 00:10:38.600 --> 00:10:40.600 now as a real time dashboard thing for all the 255 00:10:40.840 --> 00:10:43.600 interconnected sets of contexts on global superclusters. 256 00:10:43.639 --> 00:10:44.799 That's what I'm working on right now. 257 00:10:44.960 --> 00:10:47.200 So I can tell you by far it's the easiest 258 00:10:47.200 --> 00:10:48.440 way to do that because you can think of things 259 00:10:48.519 --> 00:10:50.399 in these large fat more basically thinking of it in 260 00:10:50.440 --> 00:10:53.159 immediate mode. If you've ever done game development, your UIs 261 00:10:53.159 --> 00:10:56.120 are generally they're so interactive that it doesn't make sense 262 00:10:56.159 --> 00:10:58.480 to hold on to state because you're basically re rendering 263 00:10:58.519 --> 00:11:00.440 the whole thing in a new state every frame anyway. 264 00:11:00.679 --> 00:11:02.919 So the immediate mode is more the sell of data start, 265 00:11:02.919 --> 00:11:04.919 and it is by far the simplest way to build 266 00:11:05.000 --> 00:11:08.000 those kinds of complicated dashboard. If you go to the 267 00:11:08.000 --> 00:11:11.720 website data star or data dashtar dot dev and go 268 00:11:11.840 --> 00:11:15.200 to for example, the DBMD like, that's not like it's 269 00:11:15.360 --> 00:11:19.159 techniquely it is interactive, but we're actually updating that dashboarding 270 00:11:19.240 --> 00:11:23.360 thing in micro seconds, not milliseconds, not seconds like you're 271 00:11:23.440 --> 00:11:26.200 used to seeing in a dashboard. We're doing it in microseconds, 272 00:11:26.320 --> 00:11:29.039 so we're able to make updates to the back end, 273 00:11:29.240 --> 00:11:31.200 make it very efficient, and actually make shared state. 274 00:11:31.399 --> 00:11:32.759 So one of the things I think is going to 275 00:11:32.799 --> 00:11:33.279 be coming in. 276 00:11:33.320 --> 00:11:35.080 Web poor point zero kind of thing is much more 277 00:11:35.120 --> 00:11:38.159 collaboration and the idea that all the state should be 278 00:11:38.240 --> 00:11:40.679 living in the right place, which is most primarily the 279 00:11:40.720 --> 00:11:43.600 back end, means that everyone can have these collaborative shared states, 280 00:11:43.759 --> 00:11:45.799 and it's actually cheaper because you're sending down just the 281 00:11:45.799 --> 00:11:46.840 parts that have changed. 282 00:11:47.840 --> 00:11:50.799 So it's way faster, right, So what does the approach 283 00:11:50.799 --> 00:11:53.039 look like then? So let's say that I'm like, all right, well, 284 00:11:53.240 --> 00:11:55.159 you know, and I use rails on the back end, 285 00:11:55.200 --> 00:11:57.399 but you know, so I'm going to use it. You know, 286 00:11:57.559 --> 00:11:59.159 I'm going to use rails on the back end, or 287 00:11:59.200 --> 00:12:01.279 maybe I'll use no or something. I don't know, but 288 00:12:01.480 --> 00:12:03.279 you know, so I set all that up. You know, 289 00:12:03.320 --> 00:12:06.519 I have ways to get data from my back end 290 00:12:06.559 --> 00:12:09.360 from my front end. So what what does the workflow 291 00:12:09.360 --> 00:12:11.440 actually look like when I'm building this out? 292 00:12:11.879 --> 00:12:13.879 Sure, so if you've already used similar or if you've 293 00:12:13.919 --> 00:12:17.120 already used the turbo stuff, basically you could start with 294 00:12:17.159 --> 00:12:20.440 a skeleton page that just says, hey, here's my like 295 00:12:20.600 --> 00:12:23.200 layout and here's IDs for things I want to hook 296 00:12:23.240 --> 00:12:25.320 into the same kind of way that the morph works, 297 00:12:25.480 --> 00:12:27.759 you do the same thing, except for now you're basically 298 00:12:28.080 --> 00:12:30.919 all you do is when you send back these we 299 00:12:30.960 --> 00:12:31.879 have a SEKS to make. 300 00:12:31.799 --> 00:12:32.960 It a little bit easier, but it's literally just a 301 00:12:33.000 --> 00:12:33.879 helper on top of SEC. 302 00:12:34.279 --> 00:12:37.120 You'd say I want to patch element and you give 303 00:12:37.159 --> 00:12:38.720 it an element with an ID. 304 00:12:39.519 --> 00:12:41.000 That's it. That's all you do. 305 00:12:41.240 --> 00:12:42.919 Everything else is handled for you. It knows where to 306 00:12:42.919 --> 00:12:44.759 grab it, what to update, how to morph. So the 307 00:12:44.799 --> 00:12:47.200 defaults are if it has an ID, I'm going to update, 308 00:12:47.200 --> 00:12:49.399 I'm gonna select on that and grab that ID, and 309 00:12:49.480 --> 00:12:50.679 I'm going to morph by default. 310 00:12:50.960 --> 00:12:52.879 So in most cases that's all you do. 311 00:12:53.080 --> 00:12:54.960 You just like send a patch that says here's the 312 00:12:55.000 --> 00:12:58.360 new stuff for that area that has an idea, and 313 00:12:58.360 --> 00:13:00.399 you're done. And the nice thing is that most of 314 00:13:00.399 --> 00:13:02.600 the state in the back end becomes really really simple 315 00:13:02.840 --> 00:13:04.440 because you're just sending down win things shame. 316 00:13:04.519 --> 00:13:05.960 So your locality of behavior. 317 00:13:06.120 --> 00:13:08.559 Instead of saying I'm trying to build up adjacent object 318 00:13:08.600 --> 00:13:11.000 and then send down, you're saying I got something from 319 00:13:11.000 --> 00:13:13.759 the database. And what I do is I literally get 320 00:13:13.759 --> 00:13:16.399 the row from the database and then I render on 321 00:13:16.440 --> 00:13:19.399 the next row. Like I render, I get the data 322 00:13:19.440 --> 00:13:21.559 and I send it to the template library and then 323 00:13:21.559 --> 00:13:22.080 I'm done. 324 00:13:22.480 --> 00:13:24.360 Like the locality behavior can be the same. 325 00:13:24.200 --> 00:13:26.279 Line, right, So you use the template library on the 326 00:13:26.279 --> 00:13:27.879 front end or do you know in the back end 327 00:13:27.919 --> 00:13:30.639 that's because the thing is up to your back and 328 00:13:30.679 --> 00:13:33.200 I tend to use GO most of the time. It's 329 00:13:33.320 --> 00:13:35.360 it has a lot better tooling the sea for you know, 330 00:13:35.759 --> 00:13:38.200 webright kind of stuff and so yeah, I just have 331 00:13:38.279 --> 00:13:40.759 Temple and I have Temple components and you render the 332 00:13:40.759 --> 00:13:41.879 stuff and you send it down. 333 00:13:42.200 --> 00:13:44.320 That's it. Like there's it's very simple. 334 00:13:44.320 --> 00:13:46.639 We have SDK's and I think twelve languages to make 335 00:13:46.679 --> 00:13:49.120 this easier so you can just get up and running quickly. 336 00:13:49.240 --> 00:13:52.679 But the nice part is like Turbo and HGMX have 337 00:13:52.879 --> 00:13:54.360 the idea of like sending stuff in the back end, 338 00:13:54.399 --> 00:13:56.080 Like I think that's a good idea of a general thing, 339 00:13:56.120 --> 00:13:58.519 but the problem is they don't have the concept of 340 00:13:58.600 --> 00:14:01.639 signals and reactivity and things on the front end. So 341 00:14:01.840 --> 00:14:04.879 data Star also includes things like data class, data style, 342 00:14:05.159 --> 00:14:08.679 data on click, all the signal libraries, data computed data, 343 00:14:08.720 --> 00:14:10.960 effect like all the things you need to build front 344 00:14:10.960 --> 00:14:12.799 and stuff it's up because there's times where there's client 345 00:14:12.879 --> 00:14:15.120 side state and there's times when there's not, and being 346 00:14:15.120 --> 00:14:17.679 able to know which it's which makes it a lot easier. 347 00:14:17.799 --> 00:14:18.639 Yeah, that makes sense. 348 00:14:19.080 --> 00:14:21.639 So to talk through some of this when you're talking 349 00:14:21.679 --> 00:14:23.519 about the front end state, right, you don't need a 350 00:14:23.559 --> 00:14:25.440 state library because you just put it all into the 351 00:14:25.519 --> 00:14:28.240 data attributes and you just updated as you go. 352 00:14:28.840 --> 00:14:33.080 Yeah, so there's one familiar to me with stimulus. Yeah. 353 00:14:33.120 --> 00:14:37.679 So there's one basically global reactive store, kind of like 354 00:14:37.799 --> 00:14:39.559 you see in redocs or any of these kinds of things, 355 00:14:39.639 --> 00:14:41.840 where you have a global store. As you make changes, 356 00:14:42.360 --> 00:14:44.840 it automatically updates and gives you signals and all this stuff. 357 00:14:44.879 --> 00:14:47.399 And then what happens is whenever you do actions inside 358 00:14:47.399 --> 00:14:49.559 you think, we have an at sign for basically actions, 359 00:14:49.759 --> 00:14:51.720 So if you do it at GET or not at post, 360 00:14:52.080 --> 00:14:55.120 it automatically compiles all the signals and sends it back up. 361 00:14:55.159 --> 00:14:57.279 There's filtered on that you can say I want to 362 00:14:57.279 --> 00:14:59.000 subset it and all that, but the point is that 363 00:14:59.039 --> 00:15:02.240 you basically you can keep things in sync by sending 364 00:15:02.320 --> 00:15:04.360 that state back up to the server. And because you 365 00:15:04.440 --> 00:15:06.559 have so much of your states on the back end, 366 00:15:06.639 --> 00:15:08.639 there's very few signals on the front end. Right There's 367 00:15:08.679 --> 00:15:10.879 things like doing two a binding two an input or 368 00:15:10.879 --> 00:15:13.480 a text area or to some kind of timer thing 369 00:15:13.639 --> 00:15:15.919 or some user local setting of a theme that you 370 00:15:15.919 --> 00:15:17.799 don't care about, Like, there's some of that stuff, but 371 00:15:17.840 --> 00:15:19.279 most of the time you send all that up to 372 00:15:19.279 --> 00:15:21.240 the server and then you know the exact state of 373 00:15:21.240 --> 00:15:22.240 what the front end is doing. 374 00:15:22.440 --> 00:15:24.559 Right, So then if I need to send a signal 375 00:15:24.600 --> 00:15:26.519 back from the back end, how do you manage that? 376 00:15:27.039 --> 00:15:30.039 So with the nice thing is that we support all 377 00:15:30.039 --> 00:15:31.240 of it again in ten kilobyte. 378 00:15:31.279 --> 00:15:32.240 So if you want. 379 00:15:32.120 --> 00:15:35.919 To do a request against an HTML page, we'll morph 380 00:15:36.000 --> 00:15:36.240 that in. 381 00:15:36.360 --> 00:15:38.639 If you do it against adjacent object, we'll morph that in. 382 00:15:38.679 --> 00:15:40.679 If you do it against a jobscript object, we'll execute 383 00:15:40.679 --> 00:15:43.720 that jobscript for you. But in your SEC you could 384 00:15:43.720 --> 00:15:45.720 be sending down, hey, I want to update this patch 385 00:15:45.759 --> 00:15:46.679 of this page, or. 386 00:15:46.639 --> 00:15:47.919 I want to update these signals. 387 00:15:48.039 --> 00:15:51.080 So you have patch signals and patch elements and then 388 00:15:51.120 --> 00:15:54.840 there's technically read signals. When this stuff comes in, that's 389 00:15:54.879 --> 00:15:57.600 the entire SDK. You just like that's it. So you 390 00:15:57.639 --> 00:16:00.600 just patch things in whether there's signals or element, and 391 00:16:00.639 --> 00:16:02.480 you update your page and that's it. 392 00:16:02.600 --> 00:16:05.120 Like it's fast because there's very little of it. If 393 00:16:05.120 --> 00:16:06.840 that makes sense, right, Yeah, that makes sense. 394 00:16:06.960 --> 00:16:08.960 On the other end though, like if something changes on 395 00:16:09.000 --> 00:16:11.039 the back end, does it just push the data through 396 00:16:11.080 --> 00:16:12.879 a web socket or how do you manage that? 397 00:16:13.279 --> 00:16:16.000 So the thing that people have this has been a 398 00:16:16.399 --> 00:16:19.559 big issue with the HTML five spect People are so 399 00:16:19.679 --> 00:16:22.120 used to seeing SEC because that's that's I kind of 400 00:16:22.120 --> 00:16:24.799 think everyone should be using SD for basically everything. And 401 00:16:24.879 --> 00:16:27.480