 And today I'm going to talk about immutability and JavaScript. It's not about functional programming though. So I work with HelpShift in Pune. HelpShift has really embraced functional programming and the concepts of immutable data structures. Our backend is written in closure and at front end we use React and immutable data structure. You should definitely check it out. I came across this term, persistent data structures when I was working on a JavaScript application that was something like Google sites where the user would come and create a webpage using dragging and dropping a widget. So it had a Visivig editor and the requirement for us was to have an undo redo functionality. So my colleague, he knew about persistent data structures and immutable data structures and we tried to dive deeper into it. When we did that, we found out that yes, it gives you redo undo functionality, but that was just a side effect. What you actually get when you use persistent data structure is a lot of other advantages when it comes to writing applications, be it JavaScript or any language. So off late I started looking into what is functional programming, what is persistent data structure, what is immutability and stuff. And I would like to share whatever I've learned so far. So in short, these are the two main points that we'll talk about today. One is what is immutable data structure and how does it simply simplify the process of writing softwares. You'll also see how immutable data structures are implemented internally and how does it lead to performance. So I'd like to start with this code of sort, Rob Pike, who is well known for his work with UNIX and with Bell Labs. So he gave these, these five rules of programming, you know, programming in general. This is rule number five. So I'm just going to read this. So he says data dominates. If you have chosen the right data structures and organize things well, the algorithms will almost always be self evident data structures. But algorithms are central to programming. So people translate this to something like this. Write stupid code that uses smart objects, which my colleague translates it to something like this, which is, I believe correct, write simple code that uses smart data structures. So the point that I'm trying to make here is that data structure is something that is important when it comes to writing applications. And we should see if we can do better in terms of it, whatever we are doing today. So to touch the problem, why should we actually consider it and all? This is a text from immutable.js, you know, which we are going to talk about a little bit today. This is a text from the documentation. It says that, and I think we have heard about it during the talks over the last couple of days, much of what makes application development difficult is tracking mutation and maintaining state developing with immutable data encourages you to think differently about how data flows through your application. So the point here is that maintaining state of our application is something that we've been doing a lot. We spend a lot of time and effort thinking about how should we structure a database data and how should we, you know, organize? How do we react to state changes in the application? So there is another way to do things, which is this persistent data structure and immutable.js and, you know, all this concept of immutability. So we'll see how does it actually help, right? So just to, like, you know, set the context correct, this is the dictionary definition of immutable for people, you know, who are wondering what actually immutable is. So immutable simply means unable to be changed. So something that cannot be changed once you create it. So in terms of a JavaScript application, for example, you create a variable. You're not able to change it. It is there. It will just stay there in your application, wherever you try to access it from. So this is a concept and JavaScript actually already has few concepts, which are immutable in nature. String is one of them. So we'll just see, just to complete this definition, we'll just see what string, you know, how does string work in JavaScript? So let's say I create a string. I call it str and I set it a particular value in this case, one string called strings are immutable in JavaScript. And then I try to mutate it. The whole concept of immutability, the opposite of immutability is mutating, right? Something that can be changed. So let's say I try to mutate it. So I say str index of three and I try to set it to x, for example, or maybe I try to do a slice operation, you know, I apply slice function on this, pass on couple of indexes, right? And now if I log it to the console, the string that I created earlier, it's going to be the same. I believe that, you know, most of us know this, but in case you don't, you can just, you know, quickly try it out in your consoles. But the string that we created earlier, the point is that the string that we had created earlier, whatever operation you do on it, use any framework library string in JavaScript would be immutable. You won't be able to change it. So not just strings in JavaScript, all the primitives, the numbers, for example. So let's say you have a number five in your application, every time you face your program encounters that symbol five, it is going to have the same notion. It cannot be changed. So yes, this is the concept of immutability. And you know, I talked about it can be good and, you know, it can lead to good things. But how do we actually use immutable data structures in JavaScript? Because JavaScript, even though it has primitive data structures, where we have strings and numbers and Booleans, the most important or mostly used components of our application are array and objects, right? So how do we use arrays and objects in JavaScript today with your application? So you can use a couple of libraries will today just talk about immutable.js. So immutable.js is a library written by Facebook. So it tries to mirror the ES6 sets maps, you know, ordered map order sets, and it has a JavaScript first API. So it is object oriented API. So you will not feel, you know, that you know, you're using something else, a new technology or something or a new library, so you will feel at home. It has all the object oriented like APIs that you can use. The only difference here is so every time you do an operation on a collection. So immutable.js gives you a good set of collection that you can use in your application. As I said, set map ordered set order map and stuff. So if you want to, if you do a mutation operation on a set or a collection using immutable.js, it is always going to return you a new copy of it. It does not return. It does not mutate it in place. It gives you a new copy of it. So that's the difference. So let's see, let's see a couple of quick examples of how would we have an object in immutable, you know, if you use immutable.js or any immutable data structure. So I declare a variable called map one and I say immutable.map is a syntax, simple syntax and I have three keys A, B and C and I assign it, you know, the values one, two and three. Now I try to, excuse me, now I try to mutate the object that I just created. So I say map one dot set B and 50. So if you had a normal JavaScript object, we would have done something like this. We would have got the object, you know, it would have got updated. But in this case, since it is immutable, you know, that's something that cannot be changed. We still get the same A, B and C with one, two and three. So the first map that I had created, it did not get updated. What it actually does in fact is that it returns a new copy of it. You know, it creates a copy, updates that and returns that, which we are, you know, storing in map two. So if I log map two to the console, I'm going to get the updated one, you know, what we intended to. So this is what you do when you try to mutate something, when you try to, because we cannot make an application where we don't, you know, we're not allowed to change something. It is weird, right? So this is how you do it, though, similar to the list map example that we saw list is also there, also known as arrays if you want to use it. So you create a list, you try to push three to the list that I had just created one and two. So if I do a push operation on a normal JavaScript array, it generally gives you an, it updates it, right? But it is not going to happen because it's immutable. And if I log the second list, it gives you the, the updated one, right? So it's cool, you know, a new concept, but why actually it is good? Should we, why should we, you know, spend time hearing this talk and, you know, going back and trying to figure it out? Why should we do it? So why is immutable data structures good? So that's, that's the main point that I'm going to highlight now. So we touched upon the problem of mutation, maintaining state. So the biggest advantage that, you know, I can tell you is the state management is very easy when you work with immutable data structure. And what happens is that, you know, in most of the cases, we have an application, we have a state which is represented by some object nested object or something. And we react to the changes to the state, right? So what we do is we check if the state got changed and we do some operation based on it, maybe like we would re-render or we would make some database calls or whatever, some XHR. But we do something based on the state changes. So the most important thing here is to understand if the state got updated or not, right? So immutable data structures work differently when it comes to doing this. So the concept of equality comes into picture. It has a very simple concept of equality. I'll just compare it with the, you know, mutable world, what we do right now so that, you know, we get an idea. So let's say I have an application and this is the, you know, in simplest term, this is how I am representing my state, the state of the application. So I say where X and it has a key called foo and the value is bar, right? So this is my state at this moment. And somewhere in the application, I can have something like this. This is quite possible. And I update the reference that I had, the second line, where Y equals foo. Basically it's a pointer to X in the memory location. So I say Y dot foo equals bars. And now, you know, my application encounters this state tracking, you know, change tracking code and it finds that is the new state or whatever new object same as my earlier state. So what we get here will get true, right? Because the reference, reference equality always gives you true. Even though what we see here is that the state has changed, right? So my application would not react to it, would not do anything because we just did our reference equality. What happens, and the state is different, what happens in the case of immutable data structure, if you do it like this is, you would again do the same thing in place of a normal array, you know, object literal, I'm using immutable dot map and I'm setting it, I'm changing it. Now, the example that we saw earlier was that, you know, every time you try to do a set operation or a push operation on an immutable data, it creates a copy and returns you a new version of it. So why in this case would definitely be a different reference? And I would easily, you know, safely and simply can say that, you know, my state has changed and, you know, work on it, do some operation based on it. So this is the, I think this is the most important concept when it comes to understanding the state management problem and the change tracking problem that we saw that, you know, I just wanted to highlight and the state has already actually changed and sorry, and this works for nested objects. So you might say that, you know, my state does not look like an object, which is, you know, foobar, right? It's very simple, but if you use immutable data structure, it works for any level of nested object, you know, a state represented by an object, which is of any level. So it works out of the box. In case you don't know React, you would have learned it by now, you know, a lot of React stuff. So in case you don't know React, if you do not pay attention, React basically has, you know, views which gets created, you know, it's a bunch of components and I'll not go into details. But every time React, so React tries to smartly not do a lot of stuff. It does only the minimum possible, you know, requirements. So it tries to, so every time it tries to render a component or a child of it, it goes to this function and tries to, you know, run it. If this function returns true, it re-renders it simply. So the very basic or the default implementation that React has, it always returns true because it doesn't know what is going to be there. So basically it's a hook for the developer, you know, for us. And we can write logic here to tell that, you know, if you are certain that this particular change from next, from, you know, this state to next state is not going to change, you know, my component does not require an update. I would just say, you know, return false, right? So this is the to-do that you should have in the application. I've just picked it from React's documentation. So now, so we might do something like this, right? Return this props value, you know, not equals next props dot value. So basically if my state did not change, I'll return false. And if my state changed, you know, if I want my component to be updated, I'll say true, you know, go and update this component. So I'll take a very simple, you know, trivial use case. This is my current state. This is my next state foobar foobar, right? The only difference is that I have one level of nesting. So props dot value, next props dot value. And when I have this, when I run this logic that I have written, if I run this, it is going to return true, right? Why? Because they are different, different, you know, references. You can see it, right? They're different references, so it's going to return true, which is not the case, because my state has not changed. It is still the same. I don't want to update it. So if we use, you know, again, I don't want to bash mutable data structures, but if you again use the mutable data structure here, your problem would be solved. And, you know, as it works with nested objects, you are, you are very, it's very simple, right? I'll just like to talk very quickly about pure functions. I don't want to go into function programming and stuff. I also don't know much about it, but pure functions are functions that work with immutable data structures, right? So you give some input to the function. It does some operation, just that it is not allowed to update that, you know, it is immutable. So you send, give some inputs, it returns some outputs. It has no side effects. So if your function is using immutable data structure, it becomes deterministic, like it's a fancy term to say that, you know, it is always going to return you the same output, certain, if you, you know, give the same certain input. So I input X, it is going to return me Y. Whenever, whatever happens in your application, it is always going to do that. It is not going to change its behavior. So if we have functions like this in our application, it's going to be easily testable. That's the biggest advantage that I can think of. And you can write easy test cases. Persistence that I already covered a little bit. You know, it simply means that immutable data structures or libraries like immutable.js, they preserve the previous version of the data that you're working on. So you updated it, but it is still going to be preserved. So a very, you know, quickly, I'll go back to the same list example that I showed. I did a push operation on list, but it's still preserving the same original list that I had. And if I do an equality, it is going to give me false because they're different objects now. They're not the same object. So a very naive implementation of this, this looks like this. I picked it from Lee Byron. Lee Byron is the creator of immutable.js library. He works with Facebook. So this is the way naive implementation of list.push or any immutable data structure operation. So what we do is every time we want to do a push on list, what we might do is we make a copy because we cannot mutate it. We want to keep it. We want to preserve it. So we make a copy. We edit the copy because we want a new version. So that's the push operation that it would do. And then we return the copy, right? So we are maintaining the immutability of function. So it's gonna be there. And we are also changing it because we have to update it, right? So you might say that this is slow, right? Copying a lot of things. Every time you do this, every time I do a one push operation, and I don't know, I have thousands of push operations in the application, every time you do it, it's gonna, you're gonna copy and it's gonna be dead slow. You know, react once more. Sorry about that. So react does the same thing. React has this concept of virtual DOM, right? And it tries to do again the minimum amount of work. So it tries to find the difference between the next DOM and the current DOM. And it tries to reuse the stuff which you don't want to update. So basically, and recall, I mean, there's a fancy term for that. It's called structural sharing, right? Structural sharing is nothing but reusing unchanged parts. So this is the concept that react uses internally or virtual DOM, you know, the project virtual DOM uses or even immutable data structures, you know, internally they use that. I'm gonna talk a little bit deeper into it. I want to explain this concept. So I believe that everyone knows what a list is, right? So link list basically. So a link list is a group of nodes. I want to explain what the concept of structural sharing is. So let's say this is a list and one is the head node and two, three, four are the tail. And I want to update this particular list. I want to create a new value of it. So what I'll do is I'll create one more node, zero, and I'll point it to the entire link list. So I have two values now, zero, one, two, three, four, which is the new one, and one, two, three, four, correct? So if I want to do something similar, I want to have five, two, three, four, right? So now I have three values of this list that I had and I'm still sharing two, three, four nodes, right? In all the three values, all the three versions of it. So this is nothing but structural sharing. We are sharing these three nodes for, you know, these three different values of link list. I hope this is pretty clear, right? It's not very complicated. And if I want to copy, you know, if I want to update one to five, what I'll do is I'll copy zero because I'm not allowed to mutate zero, right? So I'll make a copy of zero and I'll make change one to five and I have now zero, five, two, three, four. This is how structural sharing works and there's a better data structure for that in terms of efficiency. It's called directed acyclic graph. Again, like nothing very complicated here. It's a graph. If you have seen a graph in, you know, school or college. So it's a graph and what the aim is to, you know, leverage structural sharing or demonstrate structural sharing here, how structural sharing would work in a structure like this, right? So let's say I want to mutate or, you know, update seven, right? So what I'll do is I'm not allowed to change it in place. So I'll make a copy, right? I made it X. It is still point to eight because eight has not changed. I want a new version of it. So, you know, I pointed to the previous, the parent node, six. But again, six is not allowed to be updated. So I'll make a copy of it and I'll reach till the node, till the, you know, root node. So I have a new version, you know, a brand new version that I wanted. One, two, three, four, five, six. In case of seven, I updated it to X. So one, two, three, four, five, six, X, eight. This is the new version that we just got. And these are the stuff which is, you know, two, three, four, five, all the purple ones. Yeah, all the purple ones are shared, right? So structural sharing. This is how structural sharing is being used. I still have the old version preserved. It's not lost. In case you want to lose it, if you want to, you know, you don't want the version. So you can just get rid of the reference. It'll get garbage collected, right? Now work with this. So DAG directed a cyclic graph. This structure is cool, you know? Structural sharing works with this. But we don't have DAGs in our applications, right? In our applications, we have arrays and objects, you know, as we said earlier. So this slide, I'll just quickly go. It is efficient, you know, clearly because we are not copying a lot of stuff. The space we are reusing. And because we are not copying, we are saving time as well, right? So again, the question is, we need to represent arrays and objects in terms of DAGs. That's what we want. That's what, you know, our application says. So, you know, clever people, you know, intelligent, brilliant minds, they came up with something called this, very complicated looking structure. It is not, it is called bitmap vector try. I have references. You can, you know, go through it if you want to know. But overall, it's similar to the structure that we saw earlier. The difference, it has, you know, a couple of differences. Each node that we saw earlier, you know, the green ones or the purple ones, those nodes are replaced with arrays of a fixed size, which they call a branching factor. So in this case, the branching factor is four. Each array has four items. And each array item would point to an array of the same size in the next levels, right? So for the first item is pointing to, you know, an array of four items and so on, right? I'm not representing each one because it's going to be tough. So at first level, you have four, one, four is for zero, then four is for one, four is for two, right? So each node is an array. The second property is that data lifts, you know, the data that we are representing. We are trying to represent a list here, right? So data lifts at the bottom of the tree, right here. So starting from the top. So let's say this is an array of 150 items, right? And we are representing indexes from 128 to 143. So it's like this. So there's a list representation in terms of bit mapped vector try, you know, fancy term. So just representing is not enough. We want to do get set, you know, all those operations. So how do we do a get? So let's say I want to do a get of 141 index, right? That value. So if I want to do that, what they do is we first represent this to the binary form, start. And the idea is to reach from top to bottom because the data lifts at the bottom, right? So we start from the top and we reach at the bottom following a particular path, right? So we take two bits each, sorry. So we take two bits each and we try to find which path do we take. So we start with one zero, the red one, and which is the three third item. It's nothing but, you know, two in binary. So there's a third item in the array. So which tells us that, you know, go to the third item in the second level. So we reach here, we encounter zero, zero. It tells us go to the first one. We find one, one, then we find zero, one, right? And this is how we get 141. You know, this is the path that we took. And 141, whatever value is there, we just return it, right? So if we want to do a set, like I'll just quickly wrap it. So if we want to do a set, we do the same thing. We want to leverage structural sharing. So we follow the same path, right? We make copies because we're not allowed to mutate each array. So we make copies and we update the value and we save foo to that particular index. And there's a new brand, new version of it, right? And these gray ones are the one which are shared. The green ones represent the new version and the light gray ones are the old version. So we are using structural sharing and what we did, right? We did four array hops in order to do a set. Four array hops plus four copying of arrays. And forget we just do four array hops, right? So, and it turns out that JavaScript engines are, you know, aggressively optimized for these kinds of operations, array operations, you know, bitwise operations. So it turns out to be very efficient. We'll see how, you know, in detail. So the implementation, you know, we just saw the implementation, those graphs and tries, right? The implementation is done as try, something called try. It comes from retrieve. You should look it up. But that's the structure that we just saw. So the implementation is done like this. But the interface, you know, the APIs that has been given to us using immutable.js or other libraries are list and maps. So you still can do everything what you can do using, you know, normal array. You can do a random access. You can do a push. You can, you know, iterate from first index to the last index and stuff like that. So the interface, the APIs is still list and maps. No change. Just that implementation is try, which is efficient. Let's talk about performance, right? Because performance, performance is the theme. So about performance, we saw the branching factor of four, right? Each array had four items. So that was just for to fade in the slides because it's tough to, it's easy, right? To visualize for not many complications. In actual, if the languages which actually implement immutable data structures, like immutable.js or, you know, libraries or Clojus script, for example, they use a branching factor of 32. So at each, they came to this number to buy a lot of empirical testing and, you know, it maps good with the hardware and stuff. So, so they came up with this number, 32. So at each array that you have has 32 items, right? And it points to 32 other items. Each item points to arrays of 32 items each, right? So every level you have 32, then 32 raise to power two and three, four, five. So to give you an idea of how, you know, good this branching factor is, or, you know, how crazy efficient this is. Let's assume that we have a try or whatever structure that we saw earlier. It has a level of seven, let's say, right? So it is going to represent, and as we saw data lives at the leaves, right? So the number of items at the lowest level or the leaf level is going to be 32 raise to power seven. Now this number is roughly 34 billion, you know, items. So if I have an array of 34 billion item, you know, I can represent this using a try, which has seven level. If I want to do a lookup, what will I need? I'll need, you know, at most seven hops, right? In that structure, if I want to do an update, I need at most seven hops and at most seven copying of those arrays, you know, following that path. So this thing is, if you do the same thing, you know, if in a normal 64-bit machine JavaScript engine, I took it from David Nolan, but the numbers are correct. If you do it in the, you know, 64-bit JavaScript engine, it is going to take 256 gigabytes of memory. So you can have a 10 billion item array in your machine, in your application, and you can do a lookup in seven hops, and you know, you have to copy seven times, right? It's crazy efficient and performant. So there's not just me who knows this or, you know, a few people, people took note of it and they combine the concept of virtual DOM, not just React, but you know, React uses virtual DOM. So they can combine the concept of virtual DOM and for managing state, they combine the concept of immutable data with virtual DOM, right? DOM, sorry. And there are libraries or languages, you know, we saw a good talk about Elm today, right? So Elm is one such language which does that. There are other libraries called OM. There is a library called Mori as well, you should check it out. So there are libraries and languages which sort of combine these two concepts and give us, you know, super fast ways to write applications. So just to give you an idea about Elm, Elm, this is the good old to-do application that, you know, Elm people wrote and benchmarked. I'm not going to go to her details, but still, this is the to-do application that they wrote and this is the speed in milliseconds that they compared with React, Angular, Ember, and Angular 2. So Elm is these, you know, this one, the smallest bar, smallest, smallest good in this case because speed. So this is both naive and optimized performance comparison of to-do application written using Elm and written using, you know, libraries and frameworks using mutable data. The differences between React and Elm is that Elm uses immutable data structure. React, the good thing about React in this case, I just wanted to point this out is that React does not assume what kind of data structure you have to use. So today in your React application, if you want to use mutable data structure, you're free to do that. If you want to use immutable data structure, you're free to do that. It has no opinions about data structure that you have to use. I think Angular 1.x had this. I think Angular 2 also is sort of like that. I'm not sure. But yeah. I hope that, you know, I talked sense and you guys are like excited about this thing as I am. So you want to know more about it? You can check these people out. Rich Hickey. So Rich Hickey, like almost all of his talks, whatever I've seen are like brilliant. This is one that I wanted to point out because there is some stuff that, some idea that I took from this talk. It's called value of values. You should check this. David Nolan, again, that branching factor concept that he talks about. And he has a library called, he maintains a library called Mori, which is Cluj's script immutable data in vanilla JavaScript if you want to use it. You can do that. This is the link. You can look it up, but here's a link anyway. Elm language we briefly touched upon earlier also. The complicated data section that we saw, they were, you know, inspired by this paper by Phil Bagwell called ideal hash trees. And if you are interested, you should check it out. And he's a talk by Lee Byron on the same subject on immutable.js. He's the creator of React. You should watch that as well. So quick recap, immutable data structures, let us write simple applications. It makes our lives easier as JavaScript application developers. We can use, if you want to use it today, we can use it. There are libraries out there that are easy to use, JavaScript first APIs. They use structure sharing in order to achieve persistence and efficiency. And they enable superfast performance as well. Here's a summary. Immutable data structure struct. And I can take some questions. Yeah. Yeah. Just a quick announcement before questions. The PWA birds of feather session is starting now. And the flash talks begin after question here. Which one? This rocks. Okay. Yeah. Sorry. Oh, sure. This is the recap. Immutable data structure is cool. Yeah. Okay. Is there a question? Hello. Yeah. So Redux came up with a immutable store. So it uses just object.assign. So can you repeat? So in Redux ecosystem, Yeah. The reducers use object.assign. Yeah. Which is not performing for large amounts of data. But at the same time with immutable.js, you get around 50 KB of payload in your build size. So what is the... Correct. Have you benchmarked anything like at what point immutable.js becomes a good thing to use compared to a normal object.assign implementation. Okay. So if I understand correctly, what you're saying is that why not use object.assign? Yeah. Because for small sets of data, object.assign is fine. Yeah. It's not visible, but the immutable.js 50 KB payload in the build size. It affects larger than that. Yeah. So you're correct. Object.assign does make your object immutable, right? And then I think object.observe as well, right? I think they dropped object.observe from the ES7 candidate list or something. But still, so this particular thing is more about thinking in terms of immutable data structure. So let's say you have a state, right? And you know that your state is allowed to be updated. So you'll write your application or you'll structure your application in one particular way. You know that, you know, your state is going to change and any part of the application can do that. But if you work with immutable data structure, you're going to have a different kind of architecture. So it's the differences there. I just use immutable.js in order to explain. If you want to use it today, how do you do it? But it's more about how do you actually, you know, use immutable data structure to write your application and make it simpler, right? If you know what I mean, right? Quite cool. Does it answer your question? There are benchmarks. I can give you the links, but there are benchmarks. You can just Google, there are benchmarks. I've seen benchmarks. I could not have everything here because it might get confused. So confusing. So there are benchmarks that you can look up. Hey, hey, hey, hey, so you said immutable, like it creates a new copy of object, right? Suppose some map. So suppose some object is keeping a reference of the old one and you replace the object in list, list something. Sorry, I got the first part, but not this again. Suppose some other component or something is keeping a reference of the old object. Okay. So you replace it with a new object. Now you state becomes a new object. Okay. But the reference is being pulled by some other object. So that may lead to memory leaks, correct? No, so let me give you a refresher. So when you have an object and when you update it, right? It does not update it in place. It gives you a new version of it. So let's say your program, some part of your program had the old reference and was using the old, you know, state for example. So it would do its, its, you know, execution, whatever lines of code that you had written, it would do it based on the state that it had, whatever it has in its scope. Now you changed it. So the new version would be worked upon, you know, your code will run on the new version. So you will do something based on the new version. So it's like that. So you're not losing both of them. If you want to utilize it, you can utilize the old one. If you don't want to utilize it, you can just lose the reference. Okay. Or does that answer? Okay. Okay. More questions? Do we have time? Hi. Okay. Yeah. Yeah. Can you hear me? Yeah. I can see you. So the thing is that you talked about immutability where you say that you create new objects and then after that assign. So what happens in the case where you are actually creating a UI model that maps to a particular view and then after the user keeps changing values in the view. So don't you think that the overhead that is there by creating different immutable objects actually affects or is it different to the performance? It's a good question. So are you done with the question? Yeah, I am done. So it's again about implementation and interface that I just talked about, right? So the implementation is done as tries. So let's say a library like immutable.js or a language like Clojus script or anything, they would apply mutation internally. So there's a concept called birthing that Richiki talks about an object, you know, you give birth to an object or a value when it is actually used by the outside world. So when you are actually using it or you did, you know, 10 mutations. So the libraries would apply 10 mutations internally, but what you get is a value which did not mutate, right? So the implementation is like that. It does not actually mutate every time you mutate it. The end result of a particular operation gives you a immutable data. Did you follow? So, but even though you say that internally this happens, so don't you think that looking at what they were talked about in the previous sessions, where they talked about progressive web apps for mobile devices? So considering the limit on the amount of memory available, so don't you think that it would still be an overhead if these are used in mobile devices? So when I started, you know, like you guys older than me, I started with a 256 MB RAM computer, right? I have a 16 GB computer right now. So it's not decreasing. There are devices, mobile devices, which are like smaller, but still like it's not that, you know, small memory that you have that you can't do this kind of thing. People used to do this because earlier like decades ago, we had computers or memories which are like very limited and you have to mutate in place. But it was like quite some time ago, not I think, I think 50 years ago, when we used to do, I mean, we see the pictures of, you know, punch cards and stuff, right? But not anymore. So we don't have, we can talk about it offline. Yeah, I can hear you and I can, yeah? When you try to set using this, so what you do is create a copy, all right? And you'd keep the old reference to be dumbed by the garbage collection for the browsers, right? So how does that affect the performance? Because say we were being, means it is very, performance intensive, the garbage collection turns out to be performance intensive and affects the animation frames we have been talking previously. So if you are setting so many objects at a certain rate, how does it affect? Or how do you handle the garbage collection in this? Yeah, so it's a good question again. So garbage collection is something that again, like it's about implementation and interface. We don't have to worry about garbage collection, the languages or the libraries that implement immutable data structure. They know that, you know, this is the case that is going to be there with immutable data structures. We are going to have a lot of, you know, persistent versions and they have a, you know, matching garbage collection system. That's how it works, right? Works, cool. Okay, that's all folks. Thank you. And thanks to JSFOO for, you know, putting up a great show two days, right?