 Okay, so I want to talk a little bit today about immutability interactivity and JavaScript so I've been doing JavaScript now for about eight years doing user interface work and a Lot of a lot of what I've been thinking about recently is how With you guys you often have what appears to be inherent complexity and by sort of thinking and embracing immutability I think you'll be surprised by how a lot of what appears to be inherent complexity ends up being Incidental complexity and you can eliminate it and hope I hope to demonstrate a bit of that today so I For four years. I was at the New York Times and I recently switched over to cognatect cognatex pretty cool They actually really embrace immutability and all their platforms and their products They do lots of cool stuff. You should check it out in order to talk about interactivity We sort of have to start from the beginning. This is some kids playing around on a xerox alto at xerox park I believe they're messing around with a small talk system So you can actually download a pretty good version of small talk today. It's called squeak. It's open source I highly recommend it. It's a pretty amazing Programming environment if you open up a system browser and start inspecting the internals of the system You'll find like the classes that are available and so on You'll probably encounter model view controller, right? So I don't need to explain this too much. This is a JavaScript conference NBC's are quite big in the JavaScript world But the idea the concept was first formulated by Trigva Rinskog and Adele Goldberg and others at xerox park in 1979 Very long shadow, right? The basic concepts are still prevalent today To a large degree. I think this is because at an abstract level MVC is actually a sound separation of concerns, right? You have users they want they're interested in a certain domain So you model that domain and they want to interact with that via controls or or some interesting interaction And then you have to sort of manage the domain model and whatever the users actually sees the thing I'm going to try to question today is Implementations so for a very very long time MVC's and have been traditionally done over stateful objects. So I think it's possible to Preserve all the things we like about MVC's but we can do them without stateful objects and that sound might sound kind of crazy It is kind of crazy and hopefully I can demonstrate that it's actually Practical to do this But to sort of throw a wrench in the history of UI programming we have to talk a bit about the web So this is Tim Berners-Lee built the very first Web browser using a rich MVC framework called next step which eventually became cocoa and when he designed the web browser He wasn't thinking of creating a whole new UI paradigm, right? The big idea here was just linking documents together and sharing them over a network It's a document model. It was never meant to replace the rich UI frameworks that people were building for desktops. So By a very strange trend of events Most or not most but it's certainly a large number of people interact with computers via web browsers And so what that's what that what that's meant is that as JavaScript developers? We're forced to abstract over something that was never designed to be to sort of host UI work many of the challenges many of the frameworks many of these sort of standards that are happening are all trying to monkey patch the browser to be a suitable UI programming environment So you know you do you UI programming enough and you know this pain, right? Tools like backbone tools like ember angular JQuery they're all trying to put the DOM Push it further down so that you can reason about something higher level. I still I would quit like having done it for a long time I've gotten I've gotten to the point where I feel like Doing UI programming on the web kind of feels like this analogy that Alan Kay likes to make about software He sort of alludes that a lot of software architecture looks like this like the great pyramids It's really impressive, but there's no concept here The only idea is that it's gonna take thousands of years with thousands of people and hundreds of years Right. There's not like a there's not a there's not like a real principle at play And he points out how architecture changed very radically as soon as it's sort of Chanced upon a very good central concept and he points out the arch right the arch sort of radically changed Human notions of architecture and he points out that software really needs to do this There's often when we when we design something if we can find an arch we can often You know get a lot a lot more value out of our systems. We can build simpler systems So objects did give us something great. I think NBC is really cool And again, we don't want to like eliminate the good parts of it But I feel like we're still missing something and then you could ask well if the object-oriented guys don't have the answer What about the functional programming guys? So if you follow functional programming, which is getting more and more popular these days You might have heard something called FRP. That's functional reactive programming. It came out of Haskell It's pure FRP is still very much an active area of research because people are trying to figure out how to make it efficient You might have heard of Rx Rx is really cool. It's a reactive extensions. It's a it's a Microsoft take on FRP Fundamentally though, it's a coordination language It doesn't really do much for the fact at the edge of your coordination You're gonna have to mutate the DOM or show something to the user if you are familiar with go or Closures core async you might have heard about something called CSP. I actually blog about CSP quite a bit You can also accomplish similar things to CSP via ES6 generators But again, while it does manage sync asynchronous events and it's great for streams It's still a coordination language. It doesn't really do anything about the rendering problem At which point you we might say well, maybe maybe NBC is the best thing Maybe stateful objects really capture how we Conceptualize user interfaces. Maybe there isn't a more fundamental thing and hopefully by the end of the day I can convince you that Immutable objects are pretty awesome specifically persistent data structures And if you organize your your application around persistent data structures, you get a lot of cool properties So the next few slides I'm going to show are not my own because the slides that somebody else did were perfect There's a really great Initiative in New York called hacker school. It's sort of like a writer's retreat for programmers There's a facilitator there named Zach Olin and he produced a series of slides for strange loop, which is a great conference in the States Sort of non mainstream programming languages and approaches, but he put together a great series of slides I'm just going to use them To explain how persistent data structures work. They're they're very well known To closure programmers, of course our closure script programmers Very well known to Haskell programmers in Scala, but outside that community. They're not very well known So I think it's worth taking some time to explain The idea so functional programmers what they like to do is they like to you know functions and data That's it as much as possible. So Functional programmers want immutable values. They don't want stateful objects and the whole idea of changing something It's really you you don't if I have a data structure and I change it I'm not going to destroy the old one So with if you have a stateful object, or if you have a mutable array You're destroying the previous value that it represented and that represents some new value It's possible to avoid this And that's where the word persistent comes from persistent data structures They give you the convenience of regular data structures, but they don't destroy the previous value that was represented And I can show you how they can be fast. That's what's really cool, and that's what's relatively new I would say people did not understand this until within the last decade how this could actually be done efficiently in practice so Persistent data structures might sound really advanced really scary. They're they're not I Imagine almost everybody in this room has seen a linked list If you understand linked lists, you can understand persistent data structures So here's a list with x at the head, and it has some tail Hopefully familiar to all of you if I want to a different value, right? What's really cool about a linked list? I can just cons or like Construct a new value by putting something at the head, and I can just point to the tail That means I have a value x and I have a value y and they're sharing more than 50% of memory Right. They're they're sharing their contents even though they represent two different values You could have another variable that points to the tail of x and we now have three distinct values that share memory This is structural sharing and that's the big idea behind persistent data structures So sharing structure gives you efficiency in space But it also gives you if efficiency in time because you're not losing time copying Things right what was really cool about those different values were that we had is we didn't have to copy anything So you can actually take the linked list idea and and and generalize it so Phil Bagwell who unfortunately passed away innovated a very efficient encoding Called the hash array map try it was actually a mutable collection It wasn't until Rich Hickey the inventor of closure came along saw that you could modify it just a little bit and get an Extremely fast Family of persistent data structures out of them. So he invented something called the bitmap bitmap to vector tree and The way that it works is that it it it effectively Look, it works like a JavaScript array. It's random access. You can push things at the end efficiently You can iterate it over it quickly and Basically the way that it works is it's a it's a each node is an array and it's a tree of arrays Right, it's arrays that point to arrays and that might sound a bit weird But we'll we'll dig into that and the way we do look up. It's a prefix tree So we take the index and the index itself Gives us the prefix into the tree to find the location of a particular value. So it's a bitwise tree So a persistent a persistent vector. This is what it looks like one possible implementation You can imagine a JavaScript array with that contains four elements each of those elements is actually a pointer To four more arrays Each of those point to four more arrays that have again four slots And then finally you'll hit like the last level and the last the leaf nodes, right? Contain the actual elements themselves. So what is finding something in a data structure that looks like this in tail? so Here we have the we want to find the hundred and six element, right? So that there's actually a binary right that's we can represent as that as a binary It is a bite, you know the binary version of that and what we can do is we can say we can mask off the first two bits We can mask off the first two bits and what we when we do that that gives us a number that gives us the number one So we know to look from the root at the what's what's at the first index at index one And that takes us to the next level we can mask that one and that says oh, that's The value two so we can look at the second the in the second index of the second level that brings us one level down Again, we mask off the next two bits again. That's two The last set of bits that we have gives us You know look at the second index we're done There's no more there's no more bits to mask off and we have the element 106 Right. So how many operations do we need we needed? For three four array lookups and just some bit operations. These are these these are the types of things that JavaScript engines Are very aggressive optimizations on these types of things So what does it mean to update a persistent vector if you want to update it? So all we have to do if you want to update this persistent vector is to update Only the path that changed That's all you have to do all the other arrays that weren't on that path can be shared Right. So exactly the same as the linked list Most of the most of the memories gonna get shared and as it turns out Array cloning if you do it correctly Quite a few JavaScript engines optimize that as well So the main thing we should be thinking is what about the branching factor is for the optimal one as it turns out That's not the case After a lot of empirical testing closure on the JVM pick 32 and pretty much Anybody that implements them picks a size similar to this because it maps very well to modern hardware and cache lines And so 32 gives you very good lookup performance as well as update performance. So just to show you how Crazy this branching factor is imagine a persistent vector that had seven levels Right. That's 32 to the seventh power That's 34 billion elements right That if that was if that was a that was an array on a 64 bit operating system with a 64 4-bit JavaScript VM That's 256 gigs of RAM Right. So in a persistent vector you can get to any element in seven hops and you could even represent it in memory So and updating a 10 billion item vector only requires you to change and clone seven arrays So hopefully that gets you a little bit excited about how persistent vectors work This is exactly why I decided to own like I was very familiar with persistent data structures and then react came out and I was like this is going to be a really awesome pairing Taking the persistent data structure approach and the diffing approach that react offers because what we can do now is we can represent our Application state just as an immutable value and we can apply a function and then react will calculate the virtual DOM Right react gives us another value, which is the virtual DOM representation If something in the application changes we have immutable data So we're just going to get some new value apply the function react will compute the new virtual DOM and The way that react works It basically takes the two virtual DOMs that it produced and it cap calculates a minimal change set So we don't have to touch the DOM directly react sort of remote controls the DOM so to speak What's interesting about this model is that we can flip v0 and v1. We can get the reverse change set for free Right normally you'd have to use some sort of command pattern where you have to calculate the reverse delta So we don't have to do this react will do that for us So just a real quick demo So one of the very first things that I did when I when I saw that pairing functional Persistent data structures with react. I was like oh, I wonder how hard undo would be able to implement for example to do MVC Which is a kind of reference application for JavaScript MVC's so there but they're actually about like five lines of code that are relevant here for undo and Just really quickly. I'm gonna go You know the same you know to do MVC that you've seen a million times I'm sorry. Oh, you can't see it Thanks one second there we go So I'm adding some to do all items here. I can Click this at the top. You can see how fast it's rendering. It's far faster than 60 frames a second I'm gonna like this. I can switch Which things I'm looking at I can clear the completed and then Right, so that was just five lines of code and that's we just get it for free It's just free because react does the diffing for us. So going forwards and backwards in time It's it really equivalent as far as react is concerned and the snapshots are cheap because the difference between one app state in the next is very small and the Persistent data structures give us the efficient encoding of app state So you might not be convinced because to do MVC it's like it's cool But it's kind of like a trivial application. It doesn't really map to the type of things that people actually build Fortunately, I can show something that I did not make. This is a pixel editor by this guy Jack Shadler He works at Ableton He read he saw my undo post and he was like well is is David Nolan like is he for real Can you actually build apps this way? And so he decided to do something Where he built a pixel editor it's 64 by 64 pixels. So what he's doing is he's encoding 4096 pixels into a persistent vector. So that's 4096 individual pieces of state and he was able to implement undo redo and previewing of any state So I'm going to show this Real quick. So Here it is So what's happening here is I'm actually updating and a persistent vector Okay if I go up here There were some undo states I can You should see the preview and if I'm scrolling over here, you can see that the preview updates very quickly So how much code did this take to do? That's it. This is this is all the code that it took to do undo redo and the preview again Because it's just how react works. It's just our persistent data structures work So this is this is like one of those Moments were like oh something that we thought was inherently complex was not inherently complex It's incidentally complex because you want to build such a system with stateful objects stateful objects are what make Doing things like this complicated Sorry The other cool thing is you're probably wondering how much memory this takes so I went ahead and did a test and I imagined what if I had 1,000 frames of these 64 by 64 pixels I randomly update every pixel So I use the chrome profile and I did a heap snapshot So on the left is a heap snapshot of 1,000 saved sort of frames It takes two tenths of a megabyte on the right. I've allocated 100 arrays and that's 1.7 megabytes right So the exact same thing except persistent data structures you're seeing you just save tons of memory by sharing structure in this way so The pixel case is actually the worst right you have 4096 distinct states think about the types of applications you build putting your entire model into an immutable system is Completely doable right there. There are no real problems there and it'll likely be more memory efficient than a traditional approach So you're so hopefully you're excited about this I didn't you know I I would you know I didn't talk too much about closure script because you can actually Try this stuff out with a library that I maintain called mori which exports most of the closure script standard library It also exports all the data structures so you can use them There's quite a few people I know actually who for various reasons can't use closure script And they actually use coffee script mori plus backbone and react right So it's it's definitely possible to play around with this stuff without using closure script I will say that closure script does it it is cool and it does make some of these things more idiomatic as well as Closure script is able to optimize the more of the code Mori is actually not that small a lot of people most people use it with node It's not as popular on the front end because it's quite a big payload if you don't if you're not able to apply the Optimization techniques we do in closure script So that's all I had and I think I'll take some questions now If you have an existing app built on say backbone or any other MV star framework, how would you Would you propose it just like a complete rewrite to like refactor this paradigm or is that something you could introduce gradually? That sounds like a lot of work to me I do think though that it's possible. There have been quite a few experiments for example Can I just interrupt and say can the people who do the lightning talks come to the front as well just while David's talking? It's possible to for example do a Collection right like to do a collection that exposes a backbone API, but under the hood It's immutable like that's that's that's completely doable There's like the API is completely separate from how you store that state Thanks Got some more questions One over there. Sorry yesterday Hawking gave an excellent workshop about closure script and He posed a question which I will function like an intermediary whether Closure script and in this case on as well is ready for production Would you advise against all for using it? For a go out rather demanding client People are using in production. That's all I can say. I mean is there was there something more specific you're looking for Well, it cost you ahead if it feels or not Will it I'm sorry miss when it costs at your head if you fail or not Can I blame closure script? Can you blame closure script as much as you can blame JavaScript? It's very easy though Are there any big examples of places where closure scripts has been used or I was being used They're there. I mean I actually keep a list though It's hard to keep track now and actually some people just use it and they don't tell me That's kind of the problem. There's a lot of people use it. They don't tell you what they're doing But what's what's happened is that there are a few people that are I think wrapping up products with it I think what's happened is a lot of people are definitely using react like in the closure script world people have embraced react again It's possible to use react directly and you just get all the benefits Any more questions if we are doing sort of what you are saying So we are actually using Mori and react together and so on and I had a question about the size of the Mori library You said that that's a problem. Should we try to use the Google Closure linker or is it possible with Mori or is there another solution you get the point So you can run the Google closure compiler and compile everything and you will get all the optimizations I will say I'm not a I'm not a fan of the type of code you have to write for Google closure Part of the reason we did closure script is writing that type of JavaScript is not very fun But you can do it if you want to you can definitely do it and I think Somebody's done that actually But as far as the size of the library, it's pretty big. I mean because again, we can't optimize it for JavaScript users It's like 33k gzip. So it's a bit big for clients people have people the node node users like it quite a bit The meteor devs meteor. I believe they're using it now to do their package management constraint solver And they were able to get like a 50 50 percent performance increase by using it So if you had to use this closure script like persistent collections With Libraries that take like JavaScript arrays or are you setting up the lightning to allow what I'm sorry So if you had to use it with a library JavaScript libraries that use JavaScript arrays is a is is there a way to do that? And is it fast? There's not a way to make it fast. So I experimented a bit with yes six proxies. So you can Put a proxy around it The problem is that it's too new a feature for any engine to optimize You could imagine, you know being like look we want to use these data structures But we want the same API that we always had you got to optimize this stuff So I would say the only thing people can really do there is just push browsers to optimize a proxying Any more questions for David? Awesome, okay. Thanks very much