 So I'm gonna be kind of honest. It was a little mean to put me first. See, I'm from sunny San Francisco, California Which looks a little like this right now because out on the west coast It's currently six in the morning and I am not a morning person As a matter of fact all of my clocks look a little something like this I didn't even know there was a six in the morning And I'm telling you this to give you fair warning up front. I get a little Sarcastic when I'm tired And so while many of you probably think you know what I'm going to talk about today I think you might actually be a little surprised My first thought was well, this is a conference. I could introduce a new product, right? Conferences are great places to do exactly that But this isn't really that kind of conference This is the closure conge and the conge is about sort of deep technical knowledge, right? This is about us talking about the things we used to do work and that is a very serious thing And so my thought was if we're gonna be serious, let's start with little color-changing men This past weekend my girlfriend my co-founder and I Set out to save the universe if you will by building a game in a 48-hour coding competition And what we came up with was called chroma shift And it looked a little something like this Sorry, it's a little hard to see but you're this little tiny guy who changes color and when you change color You turn things in the world on and off and so it's kind of neat about this game is that it's actually a multiplayer game Where you're both racing to some goal and as you change colors you actually affect the other players world Now I mentioned this was for a coding competition and that competition is called the node knockout The rules in the no knockout are relatively simple You have 48 hours all digital assets have to be created in that 48 hours all the art If you have sound all the music all of that stuff must be created in that 48 hours Pass that you basically have free reign You can build anything you want so long as it's built on top of this new fangled JavaScript platform Everyone's talking about called node JS and So we entered this JavaScript competition But there's nothing in the rules that said you have to actually write it in JavaScript just that it needs to run in JavaScript and so we Decided to cheat a little bit and we use closure script to do all of this And you may have heard the adage before bringing a knife to a gunfight well We decided to bring something with a little bit more kick to it For those of you who don't know closure script is a version of closure that compiles down to JavaScript And so what that means is we bring the wonders of macros and persistent data structures and Sane semantics to the otherwise Scary and unpredictable place that is JavaScript And so we built a game with closure script now how many people here show of hands have actually built a game before Something more than pong because that can be done in a hundred lines There went a lot of hands just went down For those of you who haven't before I highly recommend you build a game It turns out that building games requires a very different way of thinking about software And it sort of stretches your mind a little bit on top of that It actually serves as a Fantastic way to sort of test the edges of performance of a language and a platform Right because games have to be fast and when I say fast I mean really really fast as a matter of fact all of your logic All of your physics all of your rendering has to get done in less than 16 milliseconds in order for you to maintain 60 frames per second That is not a lot of time as a matter of fact if you try to iterate over about I think a thousand to ten thousand Items in a seek you'll hit this by default So here we are we have this this closure script or we have this competition we want to build a game in closure script And so the question comes down to how do you build a game that feels closurey, right? You don't want to write something that looks just like JavaScript. You want something that feels closurey that is still blazingly fast Well It there are a few different schools of thought when it comes to game design Sort of the traditional one is that you have these really deep object hierarchies, right? Because games are traditionally built in C++ and so OOP is the is the way of the land But it turns out those get really hairy and they're they're scary things in the long run because you want to make some new sort of enemy Class and you have n different base classes for your enemy and it turns out you end up overriding everything all the time And it just ends up being a mess really really fast It's also not a very closury way to build something But there is another way of growing about building a game engine That I do think fits closure really really well and that is called a component entity system engine I think the easiest way instead of trying to give you a high-level overview of what this is It's actually the easiest way to understand is to go through each thing individually Initially enough we're going to start in the middle because it's by far the simplest Entities are just IDs Right, so everything in the game gets some ID literally a number an integer, right? Instead of having sort of these monolithic game objects that you think about like let's say you wanted to represent a player You think about all the things that go into a player Well, you would have x position y position the angle of rotation his health his walk speed and Other different attributes that you would have to represent you end up with these giant objects The notion here is that instead the only thing you pass around is this ID and what you want to do is Decompose all of that state into little tiny reusable pieces sounds very closury, right? Those little tiny reusable pieces of state are called components And what's nice about this is that the strategy here is that they can be reused and so they need to be single Purposed little tiny bits of state an example of this would be position and so here's a little code from the game Right, we want to create a component for position It's going to have an x an x coordinate a y coordinate and a is an angle of rotation Wasn't really important for our game, but useful nonetheless and So we have this little tiny bit of state representing position and we would have little tiny bits of state representing all the other Different things we will want in the game walking and jumping and all these abilities that you might have as a player By sort of decomposing this monolithic object it makes it really really easy for us to create new things So let's say for example in our game. We wanted two bad guys One that was really really fast and walked around and another one that was slow, but jumped every three seconds Well, if you were doing some crazy object oriented thing You would probably have to you know extract some base class that represents the basic methods that this guy would have And then override some of them so that he jumps But in a component entity system since components when you think about it a An entire entity is nothing more than a group of these components all you'd have to do is something like this Right, so if we wanted a fast guy, we would give him some set of components in this case He has a position and he has this walker Component that gives a speed right and 20 units is apparently really fast And then you have a jump guy who has you know similar components, but done slightly differently He has a position. He's a walker and he is a jumper and I'll jump every three seconds So all there is to creating something new right this is ability to compose these together very cleanly Well underlying this system is nothing more when you think about it is nothing more than Some basic data structure that allows you to map entity IDs To these groups of components that's all you really need to keep track of all of this stuff And that's very very easy to represent inside of closure All you need to do is have a map from entity ID to a vector or a map of these different little component maps if you will So this gives us all the data we need for our game, but we haven't actually talked about how the game does anything Right, this is just sort of what the game is To do that We need our last piece and that is the system. It is the logic Now unlike in an object oriented system where every single class would be responsible for you know Handling its tick events right because in a game loop you're constantly looping over every single thing in the game What we want here is nice little bite-sized functions that work over those components, right? Those components are kind of like tags for us They let us know what entities inside of the game need to react to different things And so I think the best way to look at a system is just be very practical and look at a real system So we need a component here and a game isn't very fun If you don't actually render something to the screen and so our component is renderable And as you can see all it does is it takes a function that you would use to render And so what our system needs to do is it needs to go and look at all of the entities that are renderable Go through each one of them Get the renderable component from it and call that function right sounds really straightforward Sounds like a simple function and it is this is what it would look like you have some renderer Which is just a regular old closure function And you you know do seek over the renderables so that you you have each any entity that's renderable As just takes an entity and turns it into the component that is represented by that type in this case renderable And you would call that function with the entity itself So there you have it. That's all it would take to make something renderable So let's say you add some new thing to the game and you want it to be Visible on screen all you'd have to do is add this component right if you add and you know 20 different things to the game and you only want half of them to be renderable You just don't give them the component. That's all there is to it. There's no overriding There's no sort of crazy class nonsense going on there and Then inside of the game or rather inside of the game loop What you end up doing is you just call this renderer function every single frame Right and this all e function is just saying give me all entities that are renderable That's all it takes to make a renderable system So that's great We now have a way of sort of organizing our thoughts in our in our code into something that feels Closury right we have this component entity system engine Hopefully it's kind of started to set in a little bit why this might be a good idea for closure I can't remember exactly who said this. I'm pretty sure it was at the last conge But this is about turning the entire game into data, right? This is dataing all the things and when you think about it That's a great place for closure to be all we have is some giant data structure that represents the entire game at runtime And then we have these nice little bite-sized functions that work over that structure Data functions. This is the bread and butter of closure, right? And what we get as a result of this kind of like I was saying is that we get composition and really really neat in interesting ways It's trivial for us to change the game even at runtime And so here's a little excerpt I guess of the code from the game itself, which is on my github if you want to go look at it From from an actual level inside of the game, right? So we had some background here It's renderable It's on the backing layer because there's this the visual layer system So you don't cover the player up when you're rendering things There's a camera which isn't something that gets rendered inside of the game But you want it to have a position right because you want it to follow the player around the the game world And then you have the player itself which again instead of some monolithic objects in and of itself is a bunch of these Components all strung together things like yes, he's renderable, but he also has he responds to keyboard input He has a color He's animated and standing right by default and so on and so forth Now I mentioned composition here. This is a multiplayer game and what's really neat about how that played out for us Is that in order to implement the other guy? All we had to do was take this little the set of things and remove some of them Right because fundamentally that other player needs to respond to the world much the same way that the The normal player does but he's not going to respond to keyboard input and he might have a couple of other things involved in there He might respond to syncing right over over the network and so Supporting multiplayer was relatively trivial in that regard So great Component entity system engines This is the way we're going to build the game in closure script or this is the way we built our game in closure script But there's another aspect to this as well and that is member it doesn't just need to be closurey It also needs to be really fast and When it comes to closure or closure script closure script in our case There are a few problems with this approach that make this kind of difficult The first is that components change a lot Every single frame you're going to be you know Changing state inside of the game right you're gonna be getting new positions You might have new velocity vectors and so on and so forth There are so many little because there are so many little components you're recreating these all the time The second thing is that you need to iterate over these entities because of the way we've sort of decoupled it Hundreds of times in a single frame right and like I said, you need to do all of this in 16 milliseconds and The sort of the problem you run into with closure script specifically is seeks can't go that fast There's just too much overhead with calling first and all the all of the functions that go involved with that You can't iterate over them that quickly the second thing is persistent collections are not necessarily too slow to write to although They are sort of on the edge here for this But more importantly, they're a GC nightmare in this case because you're creating thousands of objects every 16 milliseconds It doesn't take very long for the JavaScript garbage collector to freak out go through some GC pause and you basically ruined your game fortunately for us Being on top of closure script. This isn't that big of a deal Because we have access to all of JavaScript and JavaScript arrays and JavaScript objects are pretty darn fast They are really really fast actually more than fast enough for us to hit our 16 milliseconds, but Closure script is closure, right? It's built on top of the abstractions. We have come to know and love inside of closure And so it's not really designed to work over JavaScript arrays and objects It's if you start writing this code it ends up looking pretty nasty. It doesn't look like closure anymore But it is closure and so we have the benefit of macros They can come to our rescue here and make this code look exactly like closure even though we are working with these arrays and objects and So sort of to give you an example of this I'll show you an example a real system from a from the game itself Using this right so when you change color We need to turn all of the all of the similarly colored things on or off, right? So there's this flip active system and it takes color and and sort of whether or not it's active And then what it does is it goes through this doff's macro is for do fast, right? It's just do seek over arrays nothing fancy here at all There's a let's see macro since you're constantly pulling components out of these entities, right? I wrote this little macro that just makes that really clean for you instead of constantly writing let you know some entity as blah over and over again and Then we have Exclamation point and question mark those are just simple aliases for a set and a get a race at an array yet Since JavaScript objects are weird That's all it takes and this still looks like closure right this looks like code you would have written it looks like the example I gave before more or less So that's awesome Using JavaScript arrays using JavaScript objects with this component entity system We've got a game that is not only fast, but is built on the founding principles of data and composition That's exactly where we want to be Now the entire code base for this in that 48 hours ended up being about 2300 lines Which for closure script is a lot? But I should say that 500 easily 500 to a thousand of those lines are just the definitions of the game and or sort of the game levels themselves Right, and so when you start thinking about that and you separate out some of the like the physics stuff that you wouldn't ever rewrite You're probably talking about having written this entire multiplayer game for the node knockout and about 700 lines of code I'd call that pretty good That being said it wasn't all fun and games while we were doing it We definitely ran into some things and even though I've worked with with closure script a lot I still don't know what to do with this Right you get these crazy error messages that make literally no sense whatsoever that are almost impossible to figure out because on say because for whatever reason sometimes the closure compiler not the G closure the Google closure compiler will like Take all of your line Excuse me take all of your lines of code and put it onto one line for a while Or take like 10 lines of code and put it onto a single line And so you'll have like 20 dock calls in that single line You have no idea which one of them is not available to you at that point in time And it doesn't give you any help for trying to figure it out That being said It obviously wasn't that much of a hindrance. We were after all able to build a game in 48 hours and so That that speaks really well to not only the ability for closure scripts to be perform it But also for it to work well in sort of a pressure situation that you know, not many people have worked with before So I've been telling you about this game And many of you may be wondering well, what in the world is he doing up on stage Talking about a game and not light table well There there's you know, we built the game with light table and we learned a lot doing that We found out some of the brokennesses and some of the things we need to fix in order for this to work a little bit better But that's not really what ties this together. I have a confession to make and That is that I haven't really been doing much closure lately. I've kind of taken to another language And and actually to make to make Kevin line up proud. I'll show you a graph As you can see I basically doing almost no closure now It might come as a shock to you that I'm instead doing closure script But What's interesting is I'm doing all closure script basically and that means for light table to the latest release of light table Is entirely built with closure script the only Bits of closure that exist are in the lining and plug-in that you use to connect to projects That's it and the way we managed to do this is by using a really neat project that embeds node J s into Chromium directly and this project is called node webkit. It's really cool It's it's written by these guys out of the Intel open source center. It's really young It's still got a lot to work on and obviously we had some issues with it when we released with Linux and so on and so forth, but it's a very good way of sort of Essentially giving yourself a platform to build closure script client apps on top of And so here I am doing tons and tons of closure script very little closure But this isn't the only thing that links the game to light table itself It's not just that we built the game in light table. It's not just that it's all closure script now It turns out that this sort of component entity system thing is a pretty good idea Not just for games. This actually served as the inspiration for how all of light table is now built But light table isn't a game and so there isn't a loop right there are events It's just like you would expect any client application to be it's an invented sort of system And so while this component engine works really well for games it needs to take a slightly different form When you start working in a in a world without that loop and the way this sort of got implemented inside of light table It's fairly simple. It is a behavior object system as I'm calling it and Again, we'll just kind of go through these and get a sense for what that might mean an Object is sort of the first bit here and unlike in a game where you're going to have lots of these composable bits of state Objects inside of light table aren't really going to be very composable in the state sense, right? Not every object has position and so on and so forth. That doesn't really make sense Instead state is just a map right it's just a map with things like you can imagine The map for an editor for instance might be the path to the file it represents if it is a file Sort of what language it's it's what language mode it's in and so on and so forth now Everything inside of light table is an object Everything from the background to the it's kind of hard to see From the background to the tabs to the editors to the results windows the command bar Everything is an object. What's interesting about that? That means you can easily add and remove the entirety of light table if you wanted to fairly trivial And sort of the way this this plays itself out in code remember These are just little maps of state more or less, but there's some some special things we need to do So there's this function that you use to write them And so this is what an actual object inside of light table looks like so this object is the console That's the little thing that prints out all your results for you And it just has some metadata on top of it So this triggers thing is just saying there are going to be events that can be called on this thing In this case there aren't any but if there were you would want to document them here just so you have a good sense for yourself There's this set of behaviors and remember these are just these are just maps. These are just States and so behaviors are what are going to give it some some life. We'll talk about that in just a second And the last thing is all objects have an init function. They can choose to do nothing when they're initialized and that's fine But if they do do something whatever they return is tried to be considered Their UI right and so in this case with our console. We just returned the console UI So we have these objects these maps and these get put into a nice big data structure for us But we also need a way for these these objects to do something And that's where behaviors come in and a good way to think about behaviors as just sort of named event handlers They're kind of a way of composing reactions to things and so I think the easiest way to understand that is just to look at one and it looks pretty much like what you would expect You have some behavior and it give it some name So when you click something we're going to remove it so we call it on click remove And there's remember I said triggers are the sort of events that get raised on an object And so the trigger in this case that we're concerned with is click, right? So when we click on something or rather when the object raises click or click is raised on the object We will have the following reaction and that reaction is to call this rem exclamation point function So this is again just like that component system. This is about turning everything into data even when something happens or whether something happens as an event, right? If you think about how events would get would get built or how event systems work sort of traditionally you give something an object You say okay add this event handler to this list of this nameless list of event handlers And you're kind of lost at that point if you wanted to introspect that object and see oh What things are going to happen when I click on it? You can't really right? You could get a list that says all there are three functions that are going to get called, but that's it Whereas in this case we've dated it right we we can know exactly What is going to get called when something happens and so here's how this plays out in a real object? So this is the notifier object the little thing that shows up in the bottom right hand side of light table when there's a new Version or when you're connecting or whatever the case may be And so we have we've documented a set of triggers for it, right? So the things that might get called on this object are notifo click Notification click and notification dot time out So if you click on one we want to know about it and if it times out we want to know about it And then we have these behaviors that we're saying it has well when When we create this object go ahead and add the behavior Remove on timeout and that's going to listen for that notification dot timeout trigger right And it's going to have remove on click Now let's say for instance you didn't like this behavior whatsoever You wanted to change the way notifications worked inside of light table All it would take is Removing those behaviors. That's it. You'd remove them add new ones You don't have to add anything right if you don't like you don't like that They timeout just remove that behavior or add some new one that that gives it a totally different way of working We have composition here again. This is about being able to compose these events in sort of unique and interesting ways And it can happen at runtime, which is really really powerful and so an example of this sort of being able to compose these these These behaviors together is let's say we wanted to make every single editor inside of light table In instant evaluation environment basically you want to make every single editor and Insta rebel All it would take is adding these three behaviors to it So sonar result is the thing that does the magical figure out what the values are and put them in their place Every time it changes every time the editor changes you want to eval That's pretty straightforward, and you want to be able to toggle the live eval on and off Those three things are enough to essentially give every single editor inside of light table the ability to be an Insta rebel And so we have it's just one big data structure All of light table is in this single map that represents every single object And what we get as a result of this is we get introspection for free This is a little tool that I have built where I can click on any object inside of light table and then see everything I know about it right I can see all of the behaviors it has and in this case It's an editor and so I can see things like well. It's not it has no wrap on It's going to be destroyed when it gets closed. It's trying to track whether or not it's active It has the ability to save because it's file oriented You can eval it's going to save when it gets eval and so on and so forth If I wanted to change this, I don't even have to go to the code I could click on one of these hit an X button or you know hit some button that removes the That removes that behavior and then go look at a list of all the behaviors that I have available to me and add it There you go now. I've changed the functionality of this editor entirely And so this is the system that underlies light table It is the behavior object system and like I said it draws a lot of inspiration from that component way of building games we get runtime modifiability and Infinite customization two things that are really really hard to get right, but fortunately games have sort of solved this problem for us already And so that's how light table works Now I always like to leave a fair amount of time for questions But I have one more thing that I want to talk and since we started early. I should have quite a bit of time for questions But I want to sort of end on one more thing And that is since I'm doing a lot of closure script and I'm fairly certain that light table is probably the biggest closure script application out there I have I wanted to sort of end on my five wishes for the project itself I am I my five wishes for for closure script sort of span a bunch of different things The first one is that we need better error messages And I know why we don't have them is because this is a really really hard problem to solve given the way it works But we have to fix them if we expect more people to be able to do this I literally spend hundreds of hours doing closure script and I still get tripped up on errors, right? If that's happening to me if you're new to it, that's going to make things kind of difficult Now that being said for the most part You only run into this every once in a while, but when you do run into it It's very hard to get around and so this is something I think we really have to sort of focus on The second one is that I would really really like to see the compiler working on no JS Now I'm not talking about eval here or any of that stuff just the compiler I want to be able to take closure script code and turn it into JavaScript without ever being able to spin up the JVM and interestingly enough when I talk to people about closure script one of the biggest complaints I hear for whatever reason is That they don't want to take that Java Requirement they just won't do it right I write in JavaScript Why in the world am I spinning up the JVM to do that? It's by far the biggest criticism I hear But on top of that in terms of light table it would be amazing to be able to modify light table itself without ever spinning up the JVM Right, I would love not to have to have that dependency and that would make a big difference I don't even think this is actually that bad We'd have to come up with some interesting things to do with the closure the Google closure compiler But I think even there there's some clever things we can do The third thing is I Would really like to see the closure script analyzer being able to work over closure It may not have the same level of information that the closure analyzer has but the closure script analyzer has a far better Interface as it exists now And there's only superficial things keeping this from really happening I don't think there's a lot of work here the the main one is that The namespaces have some different things inside of them Right, so like the the closure script analyzer doesn't know about importing Java things and the closure analyzer doesn't know about requiring Macros and so there's a little bit of magic we would have to do there But this would mean that our tools could sort of rely on a single Source of analysis and do really great things over top of that and I think that would be immensely valuable The fourth one is a bit more of a community thing and this goes for both closure and closure script In just completely in general we need screencasts. We as a community for whatever reason we're starting to work on the documentation There's some great sort of efforts happening there on working on closure docs and and so on and so forth But we still don't actually ever show people things. We only ever tell them And and this is a big thing that when I introduced someone to closure for whatever reason I think this this comes from like the way rails became popular and so on and so forth people go well Where's the screencast like? Well, we don't really have very many of those. Oh, okay Well, tell me when you get screencasts and maybe I'll look at them So this is something that we as a community it doesn't matter if you're building something stupid and trivial and and just for fun like Video recording is still probably actually useful for somebody And it's not really that hard to do so I would really like to see us sort of build or rather do more screencasts And the last one falls on me a bit and that is we really need better tools for for closure scripts There are still too many things you have to know Too many things for someone who's never used closure before to get up and running with closure script, right? It's gotten tons better a line CLJS build is awesome and that has worked out really well But that works really well for those of us who already have lining installed who are already closure people And so one of the things we I really kind of want to work on with With with light table itself is that you know, we need better tools for closure script and and what those might look like So those are my five wishes You know, we need better errors to help people so they're not banging their heads against the wall the whole time Having the compiler on node is just useful to drop that JVM dependency, which is a big blocker for a lot of people Using the CLJS analyzer for closure is just goodness because we have one source of analysis and that's very valuable Doing more screencasts again. That's more of a community thing and I really really hope you guys do it Me myself included right? We need to start doing screencasts for for light table as well And the fifth one is better tools and again, that's kind of on me But there's lots of interesting sort of efforts being made in this tool space for closure You know, there's a lot of work going on on end repel Hugo's been working on like Ritz the the debugger for for closure and Emax So there's some good good things happening here. And so I since they put me first I want to end on one last thing And that is I sincerely hope you realize how magical this community really is And I'm not saying that I run I mean I mean it and genuinely mean it like the things and the people you will meet Or rather the things you will hear about and the people you will meet at this conference It's just amazing and ridiculous some of the things that are going on in this community Like we're testing the waters in so many different directions from logic programming to new tools to New databases, right? There's so much going on in this community and I genuinely believe that we are kind of in a transitional period in our industry that a lot of the things that we Decide sort of in the next couple of years are going to make a big difference for the next decade of programming And I truly believe that some of the people who are going to make that difference are in this room right now and With that I want to welcome you to the conge 2012. Thank you So it looks like we have about 10 minutes left, so I can take questions for about 10 minutes Or if there are none I will happily go sit down and go to sleep Yeah, so the question is for the video if there is a video um is With with the initial release of light table with that 0.1 release of light table We were trying out some interesting things with like this table mode that had this function very function-oriented thing And and he was asking with this new one you seem to have reverted back to more of the traditional editor style with files and so on and so forth To that I will say it's because we wanted to release something that had a bit more polish That worked in a more general case But that is not to say that we aren't bringing all of that back right we essentially Rewrote the entire thing and one of the things we really wanted to focus on was that we need to be working in light table all the time ourselves And in order to do that really early on we needed the simplest possible way to do that and that was with files right Those tabs that are in the top of the on the top of light table. Those can contain anything. They're not file oriented They're not editor oriented. They can be anything right when you think about it tabs are nothing more than a way of sort of Bite sizing a context. It's like of the ability to switch between context relatively trivially In light tables tastes those contexts right now are only a file-based editor and the Insta repel What that ultimately intends to be is things like that what we were calling codex is those Function-oriented sort of documents if you will those are all going to come back But one of the things we kind of learned watching people use Use that thing is we wouldn't we hadn't figured it out yet, right? We had something that worked, but it it only sort of worked We need sort of better navigation and better ways of finding those functions and so on and so forth And so it wasn't worth us spending all that time trying to get that into this release We thought it would be better off Let's just release the file stuff that we have and and let people use that and that's been really beneficial to a lot of people I think purely because until we really figure that out until we nail that sort of experience with the functions It's hard to use Yeah, so the question is have I thought about how we envision Extending and plugging into light table this entire object or this behavior object system is exactly that right the point is Not only I guess one of the advantages you have of something like emacs, right? Is that you can basically turn it into anything you want? And and and there are two things we set out to do with light table one connect you to your project That's something pretty much everyone here understands The other one is that we need an infinitely customizable interface that still does graphics, right? Like emacs can do text and that's wonderful and great and Vim can do text and that's wonderful and great but We need to be able to like when we ask a question about performance. Let's see a graph, right? Like we want that ability And so the this behavior object system is a way of not only Customizing the objects that are already in light table, which there will be a lot of right There's gonna be all sorts of useful Primitives if you will But on top of that you have the exact same system at your disposal that all of light table is built in And I was only half joking when I said you could remove everything inside of light table, right? One of the things I sort of realized is that I accidentally stumbled on a way of building a closure script platform Right, you now have you could take a light table build your entire application live inside of it, right? And then just ship it as Essentially a plug-in that removes all the all the light table parts and there's your application And I actually think that's a really strong and powerful thing to do based on how our development work with light table itself has been going And so from that standpoint, there's there's still a lot to figure out like how are we going to do the packaging and of extensions and all that But you know, there's a lot of good sort of precedence there for what has worked and what hasn't right? For example, text may kind of screwed up and not having a central repository for these to begin with That's something we'll not make the mistake of right But in terms of the actual mechanism itself everything that we can do you can do oh I see okay, so so he's basically saying since since we're exposing the entirety of light table to you Isn't that a problem for compatibility over time? My answer is yes, it would be right Fortunately in general though the state like when you think about state in this case There's very little of it for one right like Editors don't actually carry around that much state Aside from obviously the text and stuff inside of them, but in terms of things outside of that There's not that much there and so the probability of that changing is relatively low On top of that all the functionality all the scary things are still wrapped up in these behaviors You can just remove right so even if even if large things happen to light table itself There's a good chance that it actually won't be that impactful in general And on top of that let's say like a key changes for example inside of that map In that case you could do some Shimming if you will and create a fairly simplistic compatibility layer that wouldn't be hard That being said anything that's this open is naturally going to have issues if you rely on the level things Like there's nothing you can do about that Yeah, so so this question was with the big data structure. Do we try to keep it fully serializable? I? Have gone back and forth on that one, so I'm going to answer your last question first Do I think it's valuable that that could be serializable my answer to that would be absolutely? I think that would be valuable because then what you could essentially do is pack that up and ship it right? You can ship it to some other version of light table or some other instance of light table and tada You're in the exact same place you were before I don't know that that Dream is certainly something I want to see happen whether or not the entire data structure needs to be serializable to do that I don't think so a view of it needs to be you need to be able to recreate the things that for whatever reason can't be serialized And it turns out that those are relatively few and straightforward And they're things that you wouldn't want to serialize anyways in the light table case so far and so The ability to not only just like share it to someone else But even like to sync it across multiples like for pair programming for example It's definitely something I want to see and so our goal is to keep it as serializable as possible such that when we do that work It's not that hard to do So I talked to David Nolan A little bit about this so so his question was as what does it take to make the closure script compiler work inside of JavaScript essentially So there there are a couple of different aspects of this just Turning closure script into JavaScript is relatively straightforward The things that would need to happen there is you need a you need macro expansion Which is something that's not written in closure right now. You would need a full Line numbering pushback reader and all in that as well I think those were the main two things that needed to happen if I remember correctly someone else might know better than I do And then there's this problem with if you want to then subsequently get the output You would actually get if you were using the pile you have to run it through the Google closure compiler and that requires Java Right now. So so I said there's probably some trickery we could do there Well, you could easily set up there actually already is a service where you could just send code and get the result back Right, so you could do it that way But in your case if you're just doing something like a repel right you want to make I'm Arab be completely Yeah, just Right you can make right and I think that was actually the point of high Mara focus can probably talk more about it Right was this idea that you could just like send code to it and get results back So yeah, so I don't think there's a lot of work to do there Well, I say a lot. I don't know how much is in involved in trying to do all of that But it doesn't seem at least on the surface level to be too much work All right guys, I'm out of time I'm more than happy I'll be here the entire conference. So you're more than more than welcome to come and talk to me Thanks, everyone