 But yeah, so Polymer Summit happened. It was really good. I recommend everyone to watch all the videos. Let's go talks. It's even supercharged. There is a supercharged. I do say so myself. Yes. You were involved. Monica was involved. Yes. Even I was involved. You were. They let you on stage again. Yes. That was very good. I want to talk to you. I really liked that Polymer Summit was Justin's. Yes. And he was talking about lit HTML, like with the sort of. Yes, and that really spoke to me because he wrote an like he wrote basically a V-DOM alternative or a different take on V-DOM. And I've been playing around with V-DOM a lot basically because of tasklets that we talked about in the last podcast, which hopefully everybody has listened to. Do you want to do like an American TV show previously? Previously. On H2B 2.0 for you. Because of my voice. So it's just something slew. That was really good actually. So I've been looking into V-DOM and it took, I heard about V-DOM a lot and I knew basically what it did, that you had like an alternative in-memory representation of the DOM. And if you changed something, it would just create a completely new version and then find out the differences. But I never realized that is a solution to the data binding problem. If you look at Polymer, usually like annotate this attribute should always have the value of this variable that I have in my state. Right, right. And whenever it changes, there's some magic going on that realizes, oh, this has changed. I should therefore also update this attribute in the DOM. Yeah, and I worry a little bit, especially when it's two-way data binding. And you look at the implementation and I just never understood it. There's like mutation observers, but also you create magic gathers and setters so you can hook into the mutation of the variable. And if either of the sites change, you have to do all the piping. And it is not easy to implement a proper two-way binding thing. And then Vdom comes along and basically says, don't worry about the two-way binding. We're just going to like re-render the entire tree as an object and figure out what changed for you. Right. And in terms of algorithm, that is simpler. If you want to do like a really good diffing algorithm, that's not easy. But in terms of how it works, it's easier to understand. And I never realized, OK, so Vdom is a solution to the two-way data binding thing. Right, it becomes very one-way. Yeah, and then on the other hand, you would use events to bubble up changes back into your state. And that kind of makes sense. But then after I understood that, I thought about it more and more. And I was like, this is, once again, developer experience over user experience. Right. Because it is a great developer experience because that sort of way you're re-declaring the world every time, it sorts out a lot of state bugs. You put in a fairly small library. If you look at Preact, it's 3 kilobytes. That's tiny. And it does all these things, plus components and other stuff, even. But also, it completely neglects the fact that if you have a decently sized document with a couple, let's say a couple of thousand DOM nodes, there's sort of diffing going on that is completely unnecessary. Because you, as an developer, know that the big portion of your document is static and doesn't change. Right. And you pay that cost per node, not per change. Yeah. So VDOM, I guess the VDOM update or render call scales with how big your document is. Yeah, to some degree. And there's also should component update, which is you sort of get out of jail. If there's a large part of the tree that doesn't change, then you can in the React world sort of avoid redoing the work there. So we've got this virtual DOM idea that React uses, where you're paying the cost roughly per node that exists. Whereas HTML and HyperHTML, which does a very similar thing. And I've been looking at HyperHTML. I think Justin even called out HyperHTML as one of the inspirations for the HTML. Oh, cool. Oh, excellent. So they use tagged templates, JavaScript, string, literals, dot com. Is that right? With some of those words, maybe not in that order is the thing, right? I think you're right. But I think I want to also have it as a shirt. Sure. So the benefit of using, so you've got your HTML in the sort of string part of the template. Which is a very common pattern to have. If you have a custom element, you want to have your shadow root markup, for example, or just some styles or something in there as like an HTML string most of the time, which is what JSX does in one way or the other. And this one is basically, without the JSX pre-compilation bit, and instead using the HTML tagged template string literal. So one of the benefits of that is that it knows that the string parts of the template do not change. No, because what you use is the thing about tagged template string literals is that these are the things in case people don't know, the back takes, the new back takes strings in JavaScript are template string literals. And you can tag them by putting a function in before that. And that means that the JavaScript parser will bisect, dissect the string into the string bits and the bits where you do the $curly braces things to put values in there. And then you don't have to put the verse directly. We can do some processing on that first. And what Justin does is that he generates a template tag, the actual HTML template tag, and replaces your interpolation variables with a placeholder. So he basically remembers in the template tag where values can mutate. And that means whenever you change a value, he doesn't have to div the entire tree, but already knows where to jump and where to compare. And that makes a big difference. Yes, HyperHTML by Andrea J. Marchi is implemented very similar. Even if you've got that interpolation bit in the middle of a string, in the middle of a text node, I think what Andrea does is actually at compilation time inserts a comment in there that you can then go and pick out and then replace that node with whatever you actually wanted in there. I think Justin just does it with some text and goes and finds that text. I think he just creates a separate text node, but I'm not 100% there. But most of the time you just have two operations. Either you set an attribute or you replace a DOM node in the template. And that's the two operations. You can extend it. You have an extension API, a parts API, he calls it, where you can decide, actually, this is supposed to be a property or an event listener. Right, yes. But at its basic level, there's only two parts, which is attribute modification and node replacement. I played a little bit with HyperHTML. You've played with it. I think it's a very interesting pattern. I feel like it could be the next move of what is the thing on the web, where it's a very nice middle ground, because I always did the manual. I just write a custom element. I know what things I need to change and we'll just mutate the manually with query selector and just setting the things. And this is getting most of the developer experience without paying as big of a performance cost as with a pure VDOM dipping approach. Absolutely. And that is really, really nice. The Almighty Jank. The Almighty Jank. That's a good wrestler name. I like that. The Almighty Jank walks into a ring and it just freezes while the other guy just walks around. Takes a chair from the side and just goes. Hits him and he just falls over. It just doesn't. Turned into a cardboard cutout at any time.