 So it's my turn to tell you about something new in JavaScript land or in the web land, actually. And I have a proposal. I had restarted, by the way. I thought so. Oh, sorry. I didn't realize that you were still just like, oh my. Just start soon. So. So. We're trying this once more. Another episode. I love the side there. Here we are again. I'm having a talk to Jake. And this time, I have to present something. Come on, be a material. This is YouTube. You know, people don't watch anything for more than five minutes, unless you're like, oh my god, this is the most amazing thing that's ever happened to JavaScript. This is going to be incredible. You know, you're going to learn so much in this episode. You're going to come away with your brain to be like three times the size it was. It's just this is going to be the best part of your day. If not, isn't it how you die? If your brain grows to three times original size, I think I think you die. I think the idea is the skull would have to also inflate. Oh. So you look like brain from Pinky and the Brain. Yes. So now we need to put a disclaimer on the show. Might make your skull grow if you watch too much of this. It's like. That's the new tagline for the show. HTTP 203 might break your skull. Great. So I found a new JavaScript thing that intrigued me, mostly in my role as the the maintainer of Comlink, where, you know, values in workers and main thread that pretend to be in both places, but they're actually not. And then, you know, you get into garbage collection issues because things that you share will never get garbage collected because, you know, they're being shared. There's being references being held. And so I have learned more about this new proposal that is now shipped to Chrome Stable, which is weak reps. And I thought, you know what? Let's make a little episode about all this weak stuff that JavaScript has anyway. Oh, so we're not just covering weak references. This is going to be the. Well, we have a short intro bit about what's been there so far and why it is the way it is because there are some weird rough edges. Well, stop teasing me and just give me the information. Let's do it, shall we? OK, so I thought we start with what actually is a weak reference because it's been thrown around a lot and just want to make sure everybody knows what we're talking about. Really, what it means is whenever you have an object and you save quote unquote, say it's an object variable, that variable is a strong reference to that object. And as long as there's any variable in your code that, you know, has this object, this object will not get garbage collected because that would be bad if the stuff you have in variables suddenly disappeared. Now, a weak reference is the kind of reference that doesn't prevent garbage collection. So if there was a way to have a variable being a weak reference to an object, if there is no references to an object or only weak references, basically no strong references, that object is free to get garbage collected at any point in time and you might see your value actually disappear. OK, so a weak reference is kind of like if your weak reference is actually pointing to the object, then that's your way of you kind of know there's probably something else that's using this right now. Maybe. You basically know that it has not been garbage collected yet. That's pretty much as much you can deduce from that. And there's already one little difference that you mentioned there because just because you give up all strong references to an object doesn't necessarily imply that it will be immediately garbage collected. So a weak reference could theoretically still give you an object even though there is no strong references to it anymore. And that's a detail that we're going to get more into a little bit later because it's an important distinction to make. It was, I heard that because I'm glad you're doing this talk because I did read the article on weak references and I came away still being quite confused. And it was some of the uncertainty that was a bit like, I don't know, this uncertainty sounds bad. So we're going to have a lot of that because basically we have had two weak data types in JavaScript for actually quite a while. And those are the weak map and the weak set. And some might be surprised that these are fairly old. They were in IE 11. So they've been around for a long time. And what these two do is basically in the weak map, the key is weak, meaning you can only get to the value when you have the key. But the key itself is not prevented from being garbage collected just by the fact that it's being used in the map. So if you use a DOM node as the key in the weak map and don't save this DOM node anywhere else, if it gets garbage collected, your key and your value can disappear from that map. And that can be incredibly helpful. I often get to see questions on Twitter, sometimes directed at me, sometimes at others, what the use cases for weak map and weak set are. And so one of the primary uses for me is that for the longest time in JavaScript, expandos, as they're called, have been fairly common. You just take an object and you throw new properties on it. Like you put just an underscore my stuff and put your stuff in there. And that's JavaScript. It works. But one of the downsides is that it's bad etiquette, basically, to transform objects that you don't own, also because that can cause the JavaScript runtime to de-optimize because you're changing the shape, as it called, of an object. And so generated binary code might not work anymore. And they would have to regenerate it. And so mutating objects you don't own is often a bad practice. And there's an ownership issue here as well, isn't there? Because now anything else that gets that profile node can see that internal data. Yeah, because it's not really private. And you can never be 100% sure that you're not creating a name clash. Maybe in this case, some library code actually does use underscore internal. Who knows? And so what you should be doing instead is you create a week map. So in this case, we're getting something from the DOM. And instead of putting something on the DOM node itself, we use the DOM node as a key in our week map and put our extra data into the value of the week map. And that means as long as the DOM node exists, the value will continue to exist. But when the DOM node gets garbage collected, so will the value. And that's really useful. And for a week set, it's basically for the use case. Whenever you find yourself doing a week map where you store true in the value, that's like my prime example, where you just want to remember, have you visited a certain object? Have you already seen it? Has it already been processed? Those kind of things, that's where a week set comes in. However, and that is something that trips some people up or raises question marks, at least, is that neither of these are iterable. You cannot iterate over the keys in the week map. You cannot iterate over the entries in a week set. Weak stuff in general was never iterable. And that kind of comes from the fact that one of the fundamental principles, I think by the W3C was, you should never expose garbage collection. And the reason for it is actually from security. Because exposing garbage collection is what I learned when I researched this, is called a covert channel. Because now two pieces of JavaScript can communicate without ever knowing really of each other's existence. You can think about it a little bit that if you bundle two libraries and you pass just an object from one library to another, now the one library might be able to track when the other library stops using that. And that could actually, if those two libraries do it in coordination, you can communicate a lot through that without ever accessing each other's data. And that's, I mean, if you think about cookies, that's how tracking happens. And I think something like this could be exploited the same way. And so they never wanted to open this can of worms, basically. However, over time, there were more and more demands and use cases for actual weak references and exposing garbage collection. And so over time, they spent a lot of design work and collaboration between the engine authors to figure out how they can make this happen without making this covert channel an actual problem. And so the weak rest proposal was born. Before we move on to that, like one of the, like this model with weak sets and weak references where you can't iterate on the keys, that in some ways, it almost makes more sense to me because like it's that idea of like, you can only open the door with a key, right? And if you lose the key, you can no longer open the door. The equivalents here with like, because we don't just have weak map and weak set, there's also map and set, which can iterate. And that seems like a kind of model where I've lost my keys. I better go and ask the door for them back, you know? Which? Fair. It would be problematic in general, wouldn't it? So. Yeah, let's not let real doors be inspired by computer science in maps that, no, I don't think that's a good idea. So yeah, so this is where we now can talk about WeGraph. This is marked as advanced because it can be fairly hard to reason about the second garbage collection is involved. It becomes undeterministic, unpredictable, but also because whenever you use it, think really, really hard. If there isn't a way you can solve the problem without it because this will be likely to introduce more bugs than it fixes because it is a fairly hand wavy spec almost. And we'll talk about that a bit more. Well, when the garbage collection happens, isn't spec at all. Isn't spec. And that's one of the underlying problems for this entire thing. In fact, someone even said to me like, well, the JavaScript engines are not required to garbage collect. Like, the spec doesn't say they must. We'll get to that because that is actually, basically we have WeGraphs now. And in the end, they do violate a principle of exposing garbage collection. They do create that covert channel, but they did spend a lot of time in the design to make sure that on the one hand, engines are still able to optimize and iterate on their internal architecture freely without being constrained by this WeGraph existing and also to limit the bandwidth of this covert channel to such an extent that the risks are extremely low to that actually being a real problem. What are these actual problems? Why is this actually such an quote unquote advanced topic? Well, the first problem is that garbage collection is non-obvious or non-deterministic. For example, if two values become unreachable at the same time, like you give up your strong references at the same time, that does not mean they will get garbage collected at the same time. Or, and that is also something that you might notice, like it might look like you made something unreachable, but it is in fact not because the way that internal data structures work or they like a native data structures to JavaScript or closures, there might still be a reference you're just not aware of. And so your reasoning might just be flawed and really hard to figure out where it is going wrong. Engines will garbage collect differently from each other. So something that might work in one browser or when something gets garbage collected in one browser, it might not in another. It actually might get garbage collected in one previous release of your browser, but not in the current one. Or it might get actually garbage in the first run, but not in the second run of the same code on the same website because there's so many factors that the engine incorporates when to run garbage collection that it is inherently unpredictable. And this is what I brought up earlier. Garbage collection and something being unreachable are inherently separate things. Something being unreachable is a requirement for getting garbage collected, but they basically can be an arbitrary and infinitely long time in between. Most browsers run their garbage collector when they feel like the browser has downtime and only when it's under memory pressure. So, you know, if you're running on a super beefy machine, garbage collection might just not happen as a trade-off for keeping the page responsive snappy and fast. And so that's just something to really keep in mind also for the rest of the discussion that when we talk about garbage collection, we mean the moment in time when a value is being deleted from memory and the memory is being freed up, not the point where it's becoming unreachable for your code. Yeah, it's an optimization pass. Like garbage collection is optimization. It was weird when I heard that, yeah, browsers aren't required to garbage collect or JavaScript engines aren't required to garbage collect because it's like, but all the code everywhere would break if they didn't garbage collect. It's like, well, yeah, but never mind. It is something they all do. It's just when they do it and how they do it is completely unspecified. Yeah, and just to give it a separate point, it GC will happen late or sometimes all that can happen. And actually there is a little detail to this that this, well, I will talk about a bit later. All right, let's look at the actual week ref API. It is a very, very tiny slim API, which is nice. So you create a value that value has to be an object because only object gets garbage collected. Things like numbers, strings, the primitives don't get garbage collected and just put it in a week ref and now you have a week ref to the value. Wait, no, wait, wait, wait, wait, I'm confused. No, no, no, no, no, no, no. Okay, strings do get garbage collected, right? If I create a 100 megabyte string and then lose my reference to it, it will be garbage collected. I think the difference is that you can recreate that exact string later. Whereas you can't, once you lose access to an object, you can't recreate that exact object again. It would be a different instance of that object. I'm not 100% sure on strings. Now you say that. I think strings are special in that they're not objects and that two strings you create separately will be considered identical. And I think strings are shared in like a string pool because of this identity, reference identity that they have. And so I think they will probably be removed from that pool, especially large strings, but I think that's not considered garbage collection. I'm not sure on this one. So we'll probably add something in the notes of this video. Pretty sure you cannot create a weak ref to a string. Yeah, it's probably similar to how it can't be the key to a weak map or a weak set because you can recreate them again. So the same goes for numbers and symbols and null and undefined, that kind of thing. So this is now a weak ref. The weak ref is a weak reference to the value that I create above. Even if we didn't put the value in its own variable, which is a strong reference, if we didn't have a single strong reference, we would be guaranteed that this value would continue to exist until the next task. So that way we can make sure it doesn't get garbage immediately, we might have a promised chain where we want to use this value in the next microtask. That much is guaranteed. And this is not only for code to work as you expect, but also one of these mitigations for the bandwidth in that the lifetime of the value is elongated so that you can't communicate it as much through garbage collection just because now it's delayed until the next task. And now we could basically call dot deref on the weak reference to see if the value is still there at some point later. And then this maybe value will be undefined if the value had been G seed at some point between these calls, or it will be the actual value if it hasn't. And if we call deref and get the value, again, that's a new point in time where we say, okay, now the value will continue to exist until the next task at the very least. Again, for this guarantee, enter limit the amount of communication that you can do. So when you've called deref, like, all right, two questions, can you call deref multiple times? Yes, as many times as you like. And then the thing you've got is now a strong reference. Dref gives you a strong reference. Yes, it gives, yeah, basically. And so I want until that variable ceases to exist, but even then the value will not be garbage-collected at the very least until the next task. This is actually one of the consistency guarantees, so you can have multiple weak refs to the same value and calling deref on all of them will always yield the same result. There's no way that one weak ref will still have it and the other one won't. Those will always be consistent. So with this, we can have weak reference and hold onto a value without preventing it from being garbage-collected. But actually, sometimes it's more helpful to have it the other way around where we get informed when something has been garbage-collected. Because this way we don't. We just have to check, I guess, every frame or something. Like, it's really hard to, you would have to do polling and that's bad. You wanna have the inversion where you get notified when something gets garbage-collected. And that's the other part, the other half of this proposal. And that is called the finalization registry. The finalization registry takes a callback that will be called whenever a value that you have registered with the registry gets garbage-collected. And you basically registered that value with a held value. And now this is something that might be confusing to some people at first because the value that you wait to, that will be called whenever it's not the value that gets passed into the callback. And that's simply because at the time the callback is called, the value has already been garbage-collected. Doing it the other way around where you pass the value in just before it gets garbage-collected. It could allow you to store a new strong reference. Then the garbage collector would have to undo its thing and it would be way more complicated. So what you do instead, you get a separate value that you can pass in and that can be something for your internal bookkeeping to know which value it originally was or maybe it's the underlying resource you want to free up, whatever. Can you pass the same object in twice? No, that's not gonna work because it has to have a strong reference then. Yeah, so the held value is called held value because it is strongly held. I mean, you could call register some value, some value but that would prevent garbage collection from ever happening on some value. So this is your optimization step. So if you've got like, if you've vented an object and you've got some sort of system where I want to keep this WebSocket open while this object is still being used, this is the pattern you would use because you get that callback and you go, oh, that object's gone now. Now I can do my related optimizations like close the WebSocket. Yeah. And it is also important to note that the callback will be called at the same time the value gets garbage collected or at some point later in time. So, and again, this is up for interpretation by the engine. It can be very, very long between the actual garbage collection and when this callback will actually be invoked. But what about the weak ref then? Is there guarantees there? Like, could there be a situation where if I deref the weak reference, it returns like undefined or whatever, but this callback fires like an hour later or something? Yes, I think that is a possibility. So I think if the callback has been called, DRF will definitely return undefined. DRF returning undefined doesn't require that this callback has been called because it isn't required to get called at all. And this is what I want to talk about, Dex, because there is no guarantee the callback will run. And that's why it's so important that this callback isn't used for critical work. This callback should be used if a value being garbage collected means you can free up even more memory internally. It is supposed to allow you to reduce memory pressure further. It is not supposed to be used to actually do business logic cleanup work because it might not ever get called. And so in that case, you might actually be more wasteful with these resources than necessary. Yeah, you couldn't build like an analytic system that tells you how many objects are around using this because it doesn't come with those guarantees. Yes, so that's one of the reasons, for example, why this has been tailored with WebAssembly in mind because WebAssembly often passes values to JavaScript that represent something is actually in WebAssembly memory. And so in that case, it makes sense because if the representation in JavaScript gets garbage collected, meaning the engine thinks it's under memory pressure, then code can run to free up even more memory in WebAssembly lands. But if that memory doesn't get freed, it doesn't inhibit the functionality of the app or waste user resources to an unnecessary extent. So yeah, as I said, there is no guarantee that this will run. And there's some two things that they point out makes things especially unlikely for them to run. One is if you close the tab or if you kill the process, there is no need for the engine or no requirement for the engine to run all the registered callbacks if you just kill the process. So it shouldn't be used to like do cleanup work when somebody leaves the page. And it's also very unlikely for these callbacks to run if the registry itself becomes unreachable by a code. So I guess if the registry gets garbage collected unreachable, there is no guarantee that these callbacks will ever be called in the future. Now that we've registered something to get cleaned up, sometimes we might discover later on, actually we don't want this callback handler to run ever and we want to unregister a certain value. For that to work, the function register takes a third parameter, which is the unregistered token. It's similar to the held value and that is symbolizes what you need to have to unregister this one value. In this case, however, unregistered token could be the same thing as some value because it is not strongly held. But sometimes it might be easier if you use a different value altogether just for bookkeeping purposes or keeping it simple or something like that. And then you can just call it unregistered with this unregistered token and that will remove your value from the registry. And now one last method on the finalization registry, which actually I found really interesting because it's the first time that I have seen a normative optional API. That means this API is in the spec, is specced out, but implementers are not required to implement it. I think the only other API on the web that has a similar fate currently are shared array buffers in that they are specced, they're agreed upon, they're merged and everything, but they're not required to be implemented to be fully spec-compliance. Is this the same reason? Is it a security timing thing? Yes, I mean, shared array, we all know that, you know, or we have probably heard of the history shared array buffer that was removed because of spec that meltdown and now it's slowly being incorporated, but they still leave it up to the engine to decide whether they wanna enable them if they don't. Basically, browse who hadn't shipped any mitigation or found a good mitigation shouldn't be considered spec-uncompliance, incompliance? Incompliant, I think it is. I don't know. Whatever it is, don't say that about the browser, that doesn't have shared array buffer because it's a very tough problem. That's basically thinking behind it. And this apparently had a long discussion behind it, which I'm not gonna try to summarize, but some browsers didn't wanna ship this, other browsers didn't wanna ship this, there were basically a big contention around should this ever be, because it's a synchronous API that runs callbacks on amount of values that might have been garbage collected. Oh, sorry, I should explain what this function does first. So the function is called clean up sum and that is basically you saying, hey, if you have a chance, call all the callbacks for the values that have been garbage collected, but you haven't called the callback on just yet. So you're kind of opting like, I would like to process these things now. I actually kind of surprised they made it optional because it would just be just a spec-unpliant to make it a know-up because you don't have to run the callbacks. You can just say like, nah, not running anything. It's just a little, it's a little poke, isn't it? It's just like, please, please, please. But there were browser vendors just agreeing on whether this is good for the main thread or not. And so in the end, they just made it normative optional to implement this. And it currently looks like that at least on the web, we will only be shipping it in workers, not on the main thread, which I thought is quite interesting. So you do have to check whether this method exists before calling it. And this is where optional chaining comes in super handy where you just select the question mark dot parentheses and then it will be called only if that function actually exists. And that's not the first thing that that's happened with in JavaScript, right? Because we've got, it's the atomic stuff, right? There's methods on the Tomics that are only in workers as well. Yeah. And so, yeah, just keep in mind, need to check before it's there. And again, this method is just a request to run these callbacks. There is no requirement from the browser to actually process, call any callbacks or process any values. And that's what I mean, like this entire API is very much trying to leave this freedom for the engine implementers to allow them to implement better garbage collection algorithms in the future, so that they're not constrained by weak graphs and finalization registry. And so it is very, it is, you need to be very careful when working with this. One thing I want to close with, that with this, you can now actually build an iterable week map. And interestingly enough, there's an entire implementation of this in the explainer that is, I have a link here, bit.ly slash iterable week map. If you want to look at that, I'm not going to go through it here because a lot of things to track to make sure that everything is garbage correctly and so on and so forth. But if you're curious, take a look, the weak graphs implementation has shipped in current stable Chrome. I have actually merged it into comlink. So if your browser supports weak graphs, I will automatically garbage collect stuff across the worker boundary now, which I think is kind of cool. So yeah, build, try it out, play around with it, but remain careful to... Do we have enough time for you to quickly describe how you used it in comlink? Comlink, what it does is you have a value in a worker and you basically create a proxy on a main thread, saying like you proxy behave like that object in the worker. And then under the hood, I use a message passing protocol to say, this person wants to access property A, send me the value of property A please. And then this round trip happens. And what I'm doing now is basically have a simple reference counting algorithm. Whenever a proxy is created, I increment that counter and previously I had an explicit release function. I still have that an explicit release function like I don't need this proxy anymore that decreases the counter. And when the counter reaches zero, that thing can get garbage collected on the worker side. That is now you basically implicitly call that function when the proxy gets garbage collected. And you can opt in of that, you can opt out of that. But this, again, like this is if there's memory pressure, it might be useful for the engine that I release unused objects in the worker side as well. And so I pretty much just use a weak graph, a finalization registry, sorry, to get a notification this proxy has been released and then I can decrease the counter on the worker side and just let go of the message channels once that counter reaches zero. It should say like, this is super advanced stuff and anyone watching this shouldn't be like, oh, my code doesn't use weak references. I should go and add them in somehow. Like, don't do that. Please don't. Yeah. Please don't. But it is just enabling these like couple of edge cases where you can make extra optimizations or like you say, you can avoid a case where you have to call an explicit destructor, like release function or something like that. Yeah. For me, obviously it is the most exciting part is the WebAssembly bit where you now get a deeper integration between the garbage collector and JavaScript and your memory in WebAssembly. So this is the first stepping stone towards getting garbage collected languages to WebAssembly without having to ship your own garbage collector code in WebAssembly. So that's, it's not the whole story, but it's the first puzzle piece. And so I'm obviously thinking ahead and quite excited about the prospect of having managed languages be smaller and I guess better in WebAssembly. Cool. Well, we'll link to the VA article and to comlink. We'll show where you're using it in comlink. Why not? Yeah, that's good. Actually, I do now understand it a lot better than I did before. I'm glad. Well done, Serma. Well done, me. It's super advanced this stuff. And like anyone watching this shouldn't, oh Christ, Jesus, what's up, out of practice. We should say though that this is super advanced stuff.