 Okay, thanks for that lovely emcee job. Switch this on. We can hear you better now, is that working? It is wonderful, there we go. So, thanks y'all for coming out. This is quite a crowd for the second backbone conf. And it should be fun. It was a lot of fun last year. And I think someone took away the dongle. Do you still have it? Did you take it back? No. Oh, there it is. And we're off to the races. So, welcome again. And it's too bad we're doing this conference indoors because it's gorgeous, gorgeous weather in Boston yesterday and today. I've been assured that it's always like this all summer long. And it's making me miss being in the States. So I have been mostly unemployed and or gainfully unemployed, I'd like to say. And roaming around this year, so there'll be some pictures in some of the slides. So last year's backbone conference was a lot of fun. And here actually let me just tweak this for a moment. Sorry about that. My laptop was along with everything else. Most of my worldly possessions was actually ripped off in Italy about a month ago. So I'm still getting to grips with getting the setup back on this new Italian laptop, which has the keyboard that's all funny. So all the characters makes it difficult to type. Everything you get mapped mostly to American except for the little tilde that you need to get your home directory which is down by your lower pinky. So that really screws things up as does keynote configuration. But last year was sort of a really kind of, I think a feel good conference. There was a bunch of folks from a bunch of different frameworks around and a lot of great discussion happened both in the sessions and outside of the sessions on sort of techniques and tips for doing complicated applications. So I think that as a group, most of the folks here are building websites that have grown beyond what a website traditionally was and you start to do things with more and more JavaScript and you start to wrestle with some of the difficulties that can arise when trying to make something that works really well. That doesn't feel janky or flittery or cluttery for people to use it when you're trying to make a sort of responsive application. Maybe we've gotten beyond the days when we're just trying to mimic the feel of a native app anymore. It doesn't have to feel like an OSX app or an iPhone or Android app on the web, but you do want to have it have its own sort of paradigm that doesn't feel too fusty. So there's lots of good tips and tricks and techniques for trying to make that happen and sharing it I think is what this conference is about. I hope that beyond just the talks and sort of the things that we have to say from our experiences that there's a whole wealth experience, one of the strange things about seeing a little library like Backbone which is not very much coded in of itself grow up and be used in so many different use cases to see being used in web applications, sort of magazines, newspaper interactive graphics inside of games, inside of native applications on mobile tablets is that my own personal experience with the framework and what I have used it for is this tiny, tiny fraction of the realm and scope of what other people have done with it in terms of sharing models in the client and the server, integrating with native controls using it for situations like an interactive magazine where you're flipping pages and sharing a very different than what I've done. So getting folks to share their experiences and the things that they've learned I think is one of the more important things that can come out of this. So what is the problem that Backbone addresses? Why wouldn't you just use server side rendered HTML and call it a day and go from there and do everything 2005 style? So I think that where this comes from is a lot of us have experience starting with an application that is mostly sort of, you start with data that's in the HTML page and you move beyond that to sticking Jason back down into your page and then using JavaScript to look at your data and manipulate the page interactively as you sort of have the user interact with the rich controls on the page. So what I mean by that is you have all your jQuery handlers, you have this big window.data object and you kind of look into it and push and pull pieces out and update the page, update your global data object and then save that back down to the server. And if you do this for a long time to get more sophisticated, maybe you start to have a sense of different parts of your application or different views but things can quickly become sort of tangled and messy and Backbone is the whole point of it is sort of to be a minimal extraction of if I run into these problems what are the common 90% solutions that apply to all of these cases that I can pull out? So the basic one is just separating your UI from your business logic, your interface from your model and that's the fundamental thing that sort of clears up and solves a lot of the complexities with working on a big app. But all of the little sort of features and functions in Backbone are basically things that prove useful time and time again when you're running into this issue of trying to keep your application sane. So beyond just trying to address the problem there's a particular sort of type of I think maybe style that Backbone accomplishes, right? There's gonna be a million different ways to try to tackle this problem. The problem is complexity and large JavaScript applications. You can address it head on in many different ways. You can try to have a more all consuming, all encompassing framework that sort of knows everything about your data and then constrains it in a very sort of hierarchical way where you have sort of rules set up for how each little bit is supposed to behave. And there's probably a functional style you could adopt for dealing with this problem. There's probably a constraint driven style you could adopt. The Backbone style is sort of basically simple object orientation, saying we're not just gonna have, when you get back data from the server as Jason, the Jason is just data, it's not objects yet. It doesn't have any behavior associated with it. So the Backbone sort of way to do things is to take very, very simple object oriented concepts and to try to find sort of the minimal set of these data structuring concepts in terms of the UI that make it easy to work with an application. So what that means is models and collections for your data and views and URLs for your interface. And those are kinds of the primitives that you're working with. That if you have rich primitives then it'll be a little bit easier to build your application. So what we're doing is we're looking for features that sort of fit that style and that's how the framework grows and changes. And part of it is that it makes it having this nice, first of all, you know, JavaScript is kind of a nice simple object oriented language and having your application being written in a simple object oriented style where you've got these rich models that you can have methods on that do useful work for you and you can reason about it. You can say, you know, account.disable or, you know, book.chapters.first, you know or user.photos.favorite.sharewith other user, right? Having these objects that have their data with them, the user has the photos and the photos are composed of data that tells you where the file is and all this other stuff and who it's been shared with and what the data is and having that not just as a raw JSON but coupled with simple behavior that you could pass around in your application. So everywhere that the photo is being referenced in your application, everywhere, every piece of code that has to deal with the photo is able if it needs to share it with another user or is able if it needs to get the public URL for that photo, makes it much easier to work with. Then again, if you go back, if you contrast the style, right? Imagine if you had written the sharing functionality for a photo as the jQuery callback when you click the share button next to the photo, right? If that had been where the logic goes for sharing the photo, which is what you may have done in the past, say, oh, we have a share button, that's where I'm gonna flip that. Now, nowhere else in your app is able to do that. Sometimes there's crazy, you may have worked before on apps in the past where you sort of simulate clicks on things from other places to pretend like it's doing that action. You say, oh, I wrote the handler for sharing over there, I'm gonna fake a click on it and that'll do the thing I needed to do. And then of course, once your UI changes, you're kind of up shit creek at that point. So that's a little bit on the basic style of backbone. And then the other thing that's not really so much the style, but kind of like the golden mountain that everyone tries to aim for a little bit, but is not necessarily natural is this notion of statelessness. So there's a few different things that can make working on a web application difficult. One of them is code structure, right? So we all talk about spaghetti code where everything's tangled together and in such a way, especially in terms of a front end application, a client side application where you have a lot of logic and things that your code needs to know how to do and a lot of interface stuff that's just specific to how the design works and how the layout is and when you open this panel, these things need to appear. And if those get tangled together in spaghetti style, then that makes it extremely difficult to change, first of all, but more importantly, to change your interface. So usually in these web applications, your business logic is gonna live a lot longer than your interfaces. You're gonna have these core features that your apps can be able to do and you might go through a number of different designs where you might wanna be able to add new features, new interfaces, you might wanna make a mobile version of it using the same core business logic. And if they're tangled together, all of that becomes incredibly difficult and it's hard because the easy thing to do is to tangle it together. If you're not really thinking about what you're doing, then every time you have an event come in, every time the user drags to make the connection or clicks on the thing, the natural thing to do is to do the manipulation of that data right in the handler. And that ties it very concretely to what the structure of your DOM is, to what the structure of your HTML is, and then when you wanna change that, it becomes difficult. So that's one way that code can become complicated, but simple, sort of good refactoring of your code into views and models can help that. But state is another different way. You can have spaghetti code, but you can also have spaghetti state. And what I mean by that is, and it's a little bit harder to think about it, but what I mean by that is that if the state of your application is in a place where it matters what the state is and where you can go from there, and different pieces of your application depend on the state being set up in a certain way in a different place of your application for them to work, then it becomes very, very difficult to refact your application also. And what I mean by this is things where you have a value. You have the name of the person or the number of users they've shared with or the list of their associated models. And if that state, different pieces of your interface rely on that state to render and to do their thing. And if those, first of all, if that state is duplicated into more than one place and different pieces of your interface start having different ideas about what the truth of the system is, different pieces of your interface start thinking that having different copies of that state and beginning to need to coordinate to agree on what the truth is, to agree on what the number of friends is, to agree on what the name of the title is. That's one way that the state starts to get tangled together and you have to spend a lot of time and effort making sure that everything works together. The other way is that if you end up with sort of a big state machine where your application can be doing this one thing over here or doing this one thing over here and you can transition between the two, but you can't do more than one thing at the same time is another way where you have a lot of state and you have to be careful not to paint yourself into a corner where all of a sudden you're over in this mode but you need to be able to do this feature that only exists in this other mode and the two can't work together because they have different sort of requirements about their system. So the ideal, not necessarily the ideal thing but the style that the back one tries to encourage is this idea of statelessness where if instead you basically treat your state as flat saying I have all of my models, I have all of my data and the view renders sort of transparently off of that regardless of whatever the configuration of the data in the models is it doesn't matter what it is it can be in any combination there's no invalid transition that I have there the view just sort of has a single step a very flat rendering off of that. So instead of a state machine where you've got mutually exclusive states that can't both happen at the same time and that might have a few steps between them to get from one to the other instead of that you have a flat state where any combination of data can exist at the same time and your UI just reflects what the state of the data is. So it means that maybe you have things that aren't exposed like if you're in tab number two all the stuff in tab number one you can't click on it because there's no way to click on it but it's nice if it doesn't break because of that it's nice if those functions still continue to function and they don't all get broken simply because the HTML isn't there at the moment if it's basically stateless off the state of the data. So I have one little example from Documen Cloud which is we have some drop down menus that are sensitive to the state of what the documents that are being selected are. So if you've just got one document selected they have to be written in singular if you've got more than one they've got to be written in plural. If you've selected documents that you don't have permission to edit then the stuff, the editing controls and the menus have to be disabled. You know, if you've got ones that are public then you should be allowed to publish them and these kinds of things. So it matters both the number of documents you have selected and which documents you have selected and what their relationship is to you to determine what the valid state of the menu is. So you could imagine this being very difficult thing to do. You could imagine this saying like, all right, every time the selection changes which is already sort of a nice concept to have the notion of when the selection changes and not having to sort of loop through and count and see what's being selected and what's not selected. But you can imagine like having to re-initialize a jQuery context menu, plug in basically and like blow it away and then make a new one every time that this thing changes. But it's nicer and having sort of reconfigure it for the situation at hand. But it's nice if you can sort of let it be stateless and say, all right, the context menus are gonna listen for changes in the selection state and they're simply gonna re-render their menu contents as the selection changes. And then you don't have to worry about ever having an invalid option in the context menu because whatever it is, it's simply reflecting the state transparently of what's going on in the models. So that's one thing that you could do is sort of a state machine thing saying, if one document that I do not have permission to edit is selected then go to this state over here or you could have it be kind of stateless where regardless of what's selected doesn't matter, they just reflect that in their rendering. So with those as a notion, sort of the aesthetics of backbone and the statelessness idea, what I wanna talk to you about today mostly is some of my favorite backbone patterns. Things that aren't necessarily used all the time and don't need to be used all the time but might be helpful given a certain situation. So to give you an idea of what some of these are, the first one is just custom methods. Sometimes you see people treat backbone models as basically just their JSON representation basically saying, all right, this is an object that's encapsulating this bit of JSON and I can listen for events and I'm not gonna add anything else, like I'm gonna leave my models totally naked. And I think that is foolish because they're a great place to put all kinds of useful utility methods that pertain specifically to that data. So again, it's just sort of object orientation. You've got the specific data represents an entity in your system and there's gonna be lots of useful functionality that goes along with that data. And if you put that on your model, then all of a sudden, everything that has a reference to that model can do all of those features that you need for your app to work. So your app can become much more easy to tie together. You can share these things from any place where the reference exists. You can delete them or edit them or get their attributes. So you can disable the account, you can share a book with a friend, you can get the public, the large version of the public URL for a photo, for example. So atomic pieces of data with their shared behavior. And so this is where it goes, right? So whenever you see your first extension of when you're creating a new backbone model, instead of leaving that object empty, fill in all the properties with your favorite functions. So if we do the public URL, right, we're looking at the URL of the photo here and then generating the correct URL for the large one. Or if we're looking at the sharing with example, right, here we've got an object that has, it has sort of an associated sharing's collection. So if we're gonna have a book here and you wanna share the book, or a user here and you wanna share a user's book and you wanna share it with a friend, you can get the ID off of the book. You can look back to the owner to get the owner's ID off of the user and you can go to the friend and get the friend's ID and create that sort of join table and then send that to the server. So this is something that you might otherwise put not on the model. You might put it in the, again, sort of in the handler or in the controller for whatever is doing the button that does the sharing in the application. You might say, oh, backbone already provides this create function, I'll just pass in the IDs there. But it's nice if this is a thing, right? If this is a concept in your application that you might share a book with somebody else to put that in the model and to be able to access that from anywhere. So that's custom model functions, custom collection functions. Backbone already comes with a whole bunch of underscore functions on collections. You can map and filter and reduce them and do all of these kinds of count by group by sort by all these kinds of aggregate operations on them. But it's nice if you've got your own ones that you tend to do all of the time in your application to define those as methods on your collection and to have them be available to be used from everywhere. So for example, I'm a user and I've got a friend's collection on me. But, or there's another user and it's got a friend's collection. I wanna find out which friends are in common with myself. So that's just an intersection of the two friends, right? But if you define that as a nice method on your collection then it becomes very easy to do this sort of thing. Or fuzzy searching, right? So if you wanna do a simple search, that one's already got filtering for that. But if you wanna, if you have a nice little algorithm for doing a fuzzy regex sort of match on a string to look it up by name, stick that on your collection and then you can use it from everywhere. So here's the in common definition where you take the intersection of the models on this collection along with the intersection of the user that you pass in, which is another model. Their friends is a collection and you take those models and you do that together and you find out the ones that are in common. Another nice pattern beyond that is filtered collections. So frequently you start at least in backbone sort of root level collections that map to the server side notion of what the table is for the resources. So if I've got accounts on the server side, I'm gonna have an accounts collection on the client side and there's gonna be a whole bunch of different kinds of accounts in there. Maybe everything in the organization that's currently being looked at by the user, right? So you'll have admins and you'll have colleagues and you'll have guests and you'll have friends and these kinds of things. And then when you wanna iterate through them or use them, you kind of want more granularity than just the single sort of global one. So some examples of that are all the published documents, all of the articles after a certain date, all of the posts in reverse chronological order as sort of filters on the collection. So an implementation for something like that could be defining your after function, give it a date and then you just use the underscore filter function to loop through all of the posts and look up only the posts where the date is later than the date you pass in. And then this just gives you back a new array of posts that match your criteria. You can use that from anywhere and you're off to the races. And there's another way of doing it. So this is kind of different styles, right? So one way of filtering your collections is to define a bunch of useful filter functions that return an array of the values that you need and then you can just filter it whenever you need to. Another way to do it is to actually sort of an older trick but to create a new collection that listens to the original collection and tracks what happens in it. But with the difference that it filters out only the things it's interested in paying attention to before it does so. So basically we have a source collection here and we're gonna listen to all the events on it. And whenever we have an add event or a remove event we're gonna see if we care about this model. So if this post is after the date or if this user is one of my friends or if the photo is public or whatever your matching condition might be. And then we just proxy that action through. So basically whenever we hear that the source collection is added in the model we're gonna add it if it matches our condition or we're gonna remove it if it matches our condition. And now you have this other collection you can work with and pass around that tracks the source but only contains the things you care about. So that's kind of a nice one. Harmonizing with GC is a nice back to on pattern. So thinking about how to work with references in an object oriented language like JavaScript is it's sort of OOP programming 101 and thinking about how your references are structured but it's not really JavaScript programming 101. So traditionally with JavaScript in the past it's been used in context where you don't have to worry about references because you're gonna load the page for a short amount of time maybe five minutes and not do that many things in your click handlers. And then when the page gets closed all of your garbage gets closed. Everything on the page is gonna be gone and you don't have to worry about it. With an application that you want for people to be able to leave it open for weeks. You want people to be able to leave it running in their computer all the time and never have to log out of it. And let's just fill the water all over everything. The learning how to harmonize with GC is really critical. So the basic idea is of course with JavaScript and garbage collections. You're gonna have references between your objects. Everything that lives in JavaScript land. Everything that exists in the DOM. And whenever something stops being referenced by your code it will get cleaned up by the computer. And sometimes this leads sort of beginning programmers to get very paranoid about cleaning up references and to use the delete operator on every variable that they're done with. Which you don't need to do of course. All you need to do is just stop referring to it and it'll get cleaned up. And then in backbone this takes a particular sort of interest because you have these models and you have these views and you're gonna have a certain amount of references between the two. You can have of course as many as you'd like. You can put pointers everywhere, right? You can say, if you're gonna be extreme about using a lot of references you can say I'm gonna have an explicit view hierarchy, I'm gonna have my root view. My root view is gonna know about all of its children. All of them are gonna know about all their children. I can walk the entire tree of views that represent my application and have references to everything. And the same goes for the models, right? You have your root collections of models and you can walk through all of the models and all their children, all their children's collection. And you can keep track of the ways that they're linked. You can say when a view is rendering a model it's going to have a reference. You can say this.model to get back at the model and you can do the other thing as well. You can have a model say this. Let's see book.chapterviews and then have the model have references out to all of its views. So normally that's fine. You just have to pay attention when you're deleting stuff to remove the references that you no longer need or else the objects are gonna stay around. So with events this gets a little bit more interesting because an event is a reference. So when you say on change of the title, view.update, that function, that closure has a reference to the view, right? It's able to change the view and being added as the event with basically the model saying I'm gonna call this function whenever the event runs. So now the model has a reference to that view that it's gonna use every time that change happens. And if you delete the view without remembering to clean up that reference it's still gonna be there and GC is still not gonna be able to actually remove the view and you're still gonna be calling it whenever that change happens. So the way to deal with this is first of all to not use references you don't need to, right? So the easiest thing to do is to if you avoid having everything know about everything else then you have less GC problems because chunks can be collected altogether because there's simply nothing referring to it anymore. And especially pieces that don't need to know. So for example, you often have models and views that are very tightly woven. You have, they basically represent each other and they live and die at the same time. I have a page of search results. I get all of these new items in for my search results. All of their little views are coming in. And then when I click to the next page of search results that previous page is gone. All of those models are gone and their views are gone. So even though they've been tightly coupled with events and they're listening very closely it doesn't matter because nothing else is because it's not total and it's not a complete tree. All of that stuff can be garbage collected all at once and I don't have to even think about it or unbind anything myself. Actually let's go through this a little bit. So examples of this are of course when you add a new result, like I was just saying make a new result view there and then append it to the DOM or when you have an initialized function that renders it when you're changing. So these are both cases of having sort of if you have a reference back to the model. And if they get thrown away at the same time then it all just gets garbage collected at the same time. But if the life cycles are different then you have to think about a little bit more. So if the life cycles are different then you're either gonna have to clean it up yourself. And say, all right now I've gotten rid of this thing that's going way before, the other thing that's pointing to it is so I have to sever that connection so that things can be garbage collected. Or you can use a back going feature that was introduced somewhat recently called listen to which is a way of inverting that pointer. So instead of the thing where the event is being sent from having the reference to the thing that's listening it basically says the reference is gonna go the other way and the thing that's listening is gonna have the reference to the thing that is sending the event. And the reason why I might wanna do this is because of the different levels of change. So if something is sort of ephemeral it's not lasting as long as its parent is then that's the thing that you should be listening. The stuff that's in your app that lasts the longest and is around forever and emits events and that everyone cares about is the stuff that should not be pointing out to anyone else because then you have to keep on deleting those pointers all the time. It's the stuff that's ephemeral and that turns over very quickly and that gets deleted a lot that should be listening to the things that are more permanent. So if you do it that way then you can sort of automatically sever all the connections, right? With listen to when the view gets removed it can say I'm gonna delete everything because I'm being removed right now I'm gonna delete everything that I'm pointing at. And so when you have that ephemeral view that goes away at the top everything that's pointing at down below can sever it all at once and you don't have to manually worry about it too much. So that's some ways to harmonize with GC. I think I put it in that order. So if you can get away with it don't have the reference in the first place and then it's not a problem because there's nothing to keep it around. Or if you are gonna have the reference then be aware of which side of the reference is gonna last shorter or longer and have the thing that lasts a short amount of time listen to the thing that lasts a longer amount of time. Another fun pattern is lazy loading. So the problem here is that you have a large collection of data on your application. You don't wanna load it all at once necessarily. But when the app asks for an item you should either transparently return it directly to the thing that asks for it or you should go to the server, fetch it down, cache it locally and then return it. And normally this is hard in JavaScript because we're not blocking. So if I give it to you directly then there's no way to have a consistent API where I either give it to you directly or I go to the server and then you have a callback where I give it to you later on unless you use something like a promise or like a deferred. So basically this lookup method here is lazy. So if the user's collection has that user by ID it'll just call this immediately and I'll get it in, my callback will execute basically synchronously or if it has to go to the server then it's gonna come back. And so you implement this in your application by saying I'm gonna have a lookup function. I'm gonna give it an ID. I'm gonna try to get it out of local collection and if it exists then I'm going to create a new deferred to return and resolve it before I even return it and then send that back down and the function will run immediately. Otherwise I'm gonna go fetch it from the server and return that also model.fetch returns the deferred object for that fetch which will then get as soon as the server sends back the model that will be resolved. And now you have that interface where you can always just use this and you don't have to care about whether it's local or remote. So that's kind of a fun pattern to avoid the if I have it in my cache else pattern. And you can just make something like that into even into your base collection if you're doing this a lot and then use it all over the place. Another good backbone pattern is thinking about relations on the server side in your relational database or maybe your non-relational database but that still has relations of some sort in it. And the objects on the client side in the browser. One of the problems here or one of the really difficult things here is that in a server side MBC framework it's pretty easy to have the notion of your objects that you're working with your domain objects mapping one to one to your database structure because you have access to the entire database on the server. And you basically you can on the client you can't. You can't really pretend like you have access to the entire database at your fingertips because you don't. You can do particular queries for little pieces of data from the database but you can't really map it one to one onto the client all of the relations and all of their size and complexity. Or maybe you can but it's not terribly wise to sort of bring that bulk of data down to the client side. So things are very concrete on the server side but you can be a little bit more creative with your modeling on the client side. So if we have something sort of complex like a not that complex but a many to many right. So a user has many friends through friendships and you can have many users having many friends. It's not really belongs to it's many to many. On the client side there's a few different ways you can sort of model this. So one way to do it is with your sort of slightly more server style with your global friendships joint table. So friendships here is a collection and you're gonna load in basically all of the joints all of the from user and to user links that make up the friend connection here. And so if you wanna find out who are the friends of this user you're gonna say all right, what's my ID? I'm gonna filter it through all the friendships. I'm gonna look for all the friendships that are coming from me and I'm gonna get back out those joints there right. So I don't have access to the friends. I'm gonna map through them and then I'm gonna look up the two user from the friendship joint table and I'm gonna look up the actual user on the client side and then return the array of friends. So this is a way of saying starting from me as a user object give me back an array of user objects that represent my friends using this sort of server side style of having the joint table live on the client side and then looking at the joint table to do your joint. So it's one way of doing it. And as a brief coffee script aside this is just a quick nice example. I was writing this and I was like man this is really a lot of stuff. I mean it's also sort of you have to do the two loops and do the map and the filter. And it's nice that you can just do this in one little thing right. So here I'm just have basically a loop that works as a map and a filter and says for every friend in the friendships when my ID is the same as the from user so there's your filter right there look up the other user and then that whole expression is the map. So that's the one way to do it but then another way to do it is to basically instead of having this joint table what you do is you send down the list of IDs along with each user. So when you have in your JSON response you say here's the JSON response for a user it's friends field is a list of all of the IDs that it's saying friends to and then when you initialize your model you look up that array of integers and you make a new little user collection right on the model itself. So the user model has a user collection of friends and you filter through the users and sort of say all right are you in my list of IDs because that's the underscore that include is this user in the list of my friend IDs? You get back that array of users and now instead of having this function that looks at the joint table you have a pre-built collection on the model that you can refer to directly. So I'm not saying that one of these is better than the other but it's the kind of thing that's nice to think about when you're modeling when you're modeling rich sort of relationships on the server side that need to get translated the client side and what's the most convenient way for you to do this in your application is it gonna be convenient for you to have a joint table that's not too big or is it gonna be convenient for you to have collections that fit with everything that they contain at initialized time. Another good backbone pattern is dealing with timing. So one problem you might have is you wanna optimize a little piece of UI by not having it be rendered more often than it needs to be especially for statistics views or rollup views or aggregate views that are looking at a whole bunch of models and listening for changes and then doing some kind of computation across many models. So that's usually fine but then all of a sudden if you have a change that happens to a whole bunch of items this thing's gonna sort of thrash. It's gonna be rendered a lot because you have many of these specific changes and you can manually coordinate that, right? You can have some sort of a boolean flip that says, all right, are we changing? But you wait until all the changes are done and then after they're done let's finish let's do the statistics view again. But instead of manually coordinating it you can just use a little bit of you can use sort of the JavaScript event loop to your benefit here and make it and very easily optimize it. So with something with debounce which is an underscore function that it takes a function and says as long as you keep calling me I'm not gonna run until you stop calling me for a certain amount of time. So it's basically a set time out under the hood but a set time out where as long as you keep calling that function nothing it's not gonna work until you stop calling it for the specific amount of time and then it runs. And it's great for these kinds of renders these debounce renders. So I've got my stats view which is gonna get called by everything as all these things change constantly. And it's not actually gonna be rendering until I stop calling it for 25 milliseconds. So basically instantaneously but after all of those changes happen. And because backbones changes are by default not debounce because by default they happen within the current call stack you can basically put a zero there or a very small number there and have it work have it wait until right after all of those calls that have been made and then the thing renders. So this is sort of something you can sprinkle throughout your code judiciously to say this is happening too much I want it to wait until the end of the call stack before it's gonna happen again. And then in a similar vein there's this notion of threaded rendering in JavaScript which doesn't really make sense because there's no threads but we know that when JavaScript runs the UI of your application can't run in parallel. If you're doing a really expensive computation that locks your CPU in JavaScript or really expensive transformation your page is gonna freeze until you're done with that. This is not really a problem anymore very much at least unless you have like a ton of data that's making your page laggy but in the IE six, IE seven days and if you still have to worry about ever targeting Windows XP, IE eight and maybe we shouldn't say EG it's not only a problem but it has sort of that very JavaScript heavy feel where you've got this page is kind of jerky because it's doing the JavaScript slowly and it's making the UI thread block. So this often happens when you have basically maybe a particular user and so in my case I'm most familiar with this from an old startup where we had a contact application and there's a little contact list in the sidebar of the email and for most folks it was finally render all their contacts when the page loaded. The CEO of the company had like 6,000 contacts which was way more than anyone else who had been developing the app had and so when he tried to load his contacts it would block his entire email for like maybe five or 10 seconds in IE seven or in IE six. So the notion here is you can thread your renders again with basically a set timeout. So this is actually a really nice way of keeping it it's better to optimize if you can make it fast enough so you don't have to worry about this that's ideal but if it's not fast enough and your rendering is expensive then this is a way to make it feel less painful by doing it in chunks and letting the HTML redraw in between every chunk. So basically we say I'm gonna look up my models. The ones I'm gonna render are just the first 50. I'm gonna do it in chunks at 50. So this is underscore dot first gives you the first 50 things underscore dot rest 50 gives you everything else in the list that's after the 50th one. So that's items number 51 through N where N is however a longer list is. And then I'm gonna render all the ones in the first 50 and then I'm gonna defer and this is just recursive right? So on the root case I'm gonna is the items or items on the root case I'm looking up all of my models and then after that point I'm passing in the list of two defer models into that function. So it's gonna recurse down as long as it needs to rendering the first 50 off the list until the list is empty at which point it's done and then it can go on from there. And so that doesn't block your UI and that's kind of a fun pattern. Another good one is subclassing models. This is something that people don't always think to do but can be pretty handy. So if you've got a bunch of models in your application that are very disparate and that do, well they're not too disparate. They're the same kind of thing but they behave very differently. So for example you might have accounts on your system. Some of the accounts actually are real accounts and they own resources and they have edit access. So many accounts are guests and they can't do anything. In a document cloud we have this very different notion of an account that is a journalist, it's an uploader who can upload documents and you also have a reviewer and the reviewer can log into the workspace but they're an invited expert from outside who invite them with their email address and they can come in and look at a specific set of documents you've set up for them and add notes just on those documents but have otherwise no ability to do anything because they're not really a member of the system. There's someone that you're inviting in for this particular task. So those are both sort of accounts. They both have emails and they both have logins and passwords but very, very, very different functionality. Or you could imagine different media types maybe the media application photos versus videos versus sounds are all assets. They all have URLs but they have different behaviors. It's just to subclass your models further. So instead of only having your asset backbone model and then having a type field on that and then you say if type is photo do this you can actually, you can say, my account is a backbone model and my publisher is kind of an account. My reader is a kind of an account and my guest reader is a kind of a reader and just go on from there and add all the functions that don't apply to the other ones in your subclass and you can extend it down as far as you like although going too far is probably not wise either. A new one is a global events. This is not new, this is an old one sometimes called the mediator pattern. I'm not really sure why but all that it really is realizing that sometimes you have changes in state that affect your entire application. It's a change in state that's really important that you need to know about like everywhere and that might affect UI like all across your application. And so in backbone 1.0 the events, backbone events is now mixed into the backbone object so you can use that just as a convenient place to do global events handling. So what do I mean by this? You usually don't wanna use global events unless you really need them, right? So normally if an event, so people kind of overuse them with the mediator pattern and say that all of my application needs to know about everything so I'm gonna send all of my important events through this global object but the problem there is the problem like with any global, right? You can have namespace problems where the change here needs something you don't expect it to mean. You can have problems where you want not to have a certain part of the application react to it but now it's hard not to react because it's set up in this global place and you can't do it with a reference. But there are good use cases also. So for example, imagine that your application has a help mode and as soon as the user says I need help, all of your different pieces of UI sort of change to become more explanatory and have tool tips and balloons that explain what the interface is and then when the help mode goes away, you know, help on, help off, in this case. All the UI goes back to a sort of functional state. So that's something where you can say all these views are listening to say is the user asking for help and when they are I need to change the way that I render myself and that would be a place if I wanted to do it globally. Or maybe you're changing the tab maybe you have big tabs in your application and many, many pieces of the application need to know when you're switching from the files tab to the email tab. Or maybe you have an application where they can stay logged in on the webpage but they can do user switching and go into a different account and that your whole app needs to know when that happens. So you can now just do this on the backbone object if you'd like to instead of having to make your own. Another fun backbone pattern is model snapshots. So we usually think of backbone models as representing the truth of your application, right? The truth of the state of what the situation is. Basically what the data is on the server, what the entire system considers to be true but they don't have to, right? The models can also be hypotheticals that can be little parallel universes. You can say or the past, you know. You can have models that you can pass through your system and have your system react to and have your system do calculations on that represent and if the user did this, you know what would happen? Or you can have your models represent previous states of the system. So you could say, all right, what did the models look like five minutes ago or an hour ago? And I'm gonna have those models on the client side. They're not gonna exist in terms of the database on the server but I can still, you know, put my application into that state by having these models that represent different modes. So this is just an example of a simple naive undo where I'm basically tracking, I'm saying that whenever my model changes, I'm gonna push into this array of changes, what its previous state was, its previous attributes. And whenever I want to undo, all I have to do is, you know, grab, first of all, I'm gonna save what the state was that I'm undoing and then I'm gonna set on the model the last change that I pushed in and I can just undo from there. And then when I wanna redo, I'm gonna pop off of that undone stack and then redo back up to the end of my latest, my latest change. So that's one example of sort of hypothetical tracking of attributes. And you can do this with real models also. So here's another example, right? You can clone your model, you can have your model that exists for real and then you make a new draft version and then you can transform it in some way that you're not gonna save to the server but that works in a different fashion. So that can be useful for a bunch of fun stuff. Versual sub-models is, I should figure out a better word for that because that's a little bit too complex but the idea here is that sometimes you have really dense, complex data on the server side in your database and you can't really expand it into separate resources because it's necessarily very difficult and dense and you send it over the wire in a very compact format but then on the client side, you don't have to, first of all, you don't have to warehouse all of the dense data for every user in the application of the client side. You're only dealing with a small window of it. And then the other thing is that you want a richer way to interact with it. So you can transform this stuff, it's not a real table or row on the server into a real model on the client side just so that it's easier to work with. So what I mean by that is, for example, here we've got a list of entities in a dense format on the server side. So basically it's saying in this post, there is an entity at character two with a last for five character. There's an entity at character 17 with a last for six characters. 25 at last for six, 41 at last for five. Maybe this is all for like Microsoft, right? Is the entity here? And these are all of its locations, all of its occurrences within the text. I don't want to send these down as JSON because it'd be a huge amount of JSON for every entity in the document, right? I want to have this very compact, it's not really binary, but it's this very compact textual format. But then on the client side, and that's what it's in the database too, right? It's basically a blob of text in the database. On the client side, I can bust this out. I can parse it, I can parse it, I can parse it, I can split it on the comments, I can map over those strings, split them on the colons and then make a new model that knows its offset and knows its length. And now on that entity model, I can define all my features for working with entities, for saying entity.openLocation or whatever, where it zooms right to that spot in the text where the thing occurs and highlights it for you. And this is a model on the client side, there's no corresponding server side resource. It's this tiny piece of a binary field on the server, but it has a real representation as a model on the client. So that's a nice pattern. And I think the last one that I've got for you today. So what's going on with backbone roadmap-wise? We tagged a 1.0 about four months ago and we're getting pretty close to being done with a 1.1. I'd hope to have it ready for today, but it is sadly not so. So maybe by the end of the conference, we can huddle together during lunch and crank through the last few things. It's, I think we'll do a 1.1 because there's a few changes, but it's mostly little bug fixes, a couple changes to URL handling to make things slightly prettier for some folks who are mounting different backbone apps for each different user. Or also proxying through a few more underscore methods than we did before, both because there have been new methods added to underscore and also because we're gonna start to add some of the underscore methods to the model, not just to the collection. For situations where it makes sense, we have a model with a whole bunch of data and you wanna be able to do some transformations on that data and some aggregations on that data. And yeah, so hopefully that'll be done soon and that'll be a 1.1. And I should thank Brad Dunbar, Tim Greaser, Casey Foster and Phil Friot in particular for doing most of the changes that have happened since 1.0. And that's what I got for you with a few minutes for questions. I think maybe about five minutes. Thanks guys. Are you gonna do mics for the crowd or should I repeat it? Sure, mics for the crowd. Is 1.1 backwards compatible? Mostly. There's gonna be a few slight changes, which is why it's a 1.1 and not a 1.01. But they're probably not gonna be anything that you're gonna run into unless you are the person who opened the ticket that asked for the bug and fixed. Like for the thing I talked about with URLs is basically if you have, you know, you can mount a backbone app at a root URL that's considered the base. Previously it was putting a slash at the end of the route and now it will not because it's prettier if you don't. And that will affect you if you've been doing that. But unless you're the guy that opened the ticket, that probably you probably aren't. So basically anything else? Let's see, we got one back there. Question about the mediator pattern. We had internally thought about the global events as a use case for handling two views that need to talk to each other, but without doing it as a way to talk through a model, without using a model to talk through it because the data that needs to be exchanged between the two views has nothing to do with what's synchronized on the server. Curious if you could expand on your thoughts about the... Totally, so that's one really interesting use case is you have two views they're talking through this global event system because there isn't a model that corresponds. But for me, I think if you just have a reference between the views that's easier than having the views talk through this global system. So it might feel, so sometimes with events, people use them more often than they need to because it feels cleaner to have it through an event instead of having a reference to the object and calling a function on it. But in practice, it's not really any different. So an event, an event what it is, all it is is a function that's being called. It's just being called by the other guy. So instead of you calling a particular function on that other view and having a reference to it, that global object is having a reference to you and is calling the function on you instead of that other object doing it. So it's effectively the same thing. I mean, well, I don't know about effectively. It's a different style for doing what is basically the same pattern as just having the reference. So normally that's what I do. I have those two views that they have to talk, both have to talk to each other. Both have to send messages to each other. They both have references to each other and they would just be calling functions on each other as they need to. But a mediator also works, all right? So you talked about lazy loading of full models. One of the things we run into a lot is that we have kind of partial models, right? So we have kind of the small version of the model, the medium version of the full version. Have you seen any good patterns for dealing with that? I think we've done that too. I'm trying to remember exactly what the pattern was. I mean, part of it is you check for the data. You say, is the data here? And use the same kind of pattern. You have a function that uses a dot then to give you the data. And if it exists, it'll come back immediately. And if it doesn't exist, it'll go to the server and fetch it and then continue on from there. So I think the basic statement pattern applies. And probably your model just has the model and it knows what state it's in, right? And it's going to know which of the versions it's been initialized with. And then you're going to have a fetch with a parameter that lets you load whichever version you're asking for. Do you use a Boolean or like an Enum? I think you'd want to use a string or a written JavaScript, probably the same thing as an Enum, since they're immutable, just to say what the type of the representation is that's been loaded. And then the cool thing you can do is to not have to care about which one you want to load. The cool thing to do is to then ask just for the data and have the model be smart enough to say, oh, I know which representation that data is and I'm going to go get that one for you. So in your application, then you no longer have to care about which version might be loaded. All you have to do is ask for the data that you want and it'll know, be smart enough to know what to go get for you. Over there, you can just, oh, we got mics. If you've got a model that has a structure deeper than one level and you want to listen on changes to that model that is deeper than one level, Backbone doesn't really support that. So is the trick to just keep all your models at one level or else if you go about. So the easy backbone way to do it. So first of all, if you want to do it in that particular way and have nest adjacent that goes down several more levels, there are plugins that do that for you and that will send changes through for you. It gets harder to identify what the change is. If you're changing the title property of the first element in an array of the attributes, then you have to have a way of saying what it is that got changed. It becomes a little bit more difficult in that pattern. But there's plugins that can do that if you'd like. The backbone sort of way to do it is to say your server-side database is probably relational. So it is basically flat. You have these scalar values as the attributes on your object and if it's nested, that's a relation. So instead of having your array of sub-attributes, what you do is you have your model and your model has a collection of sub-models and then you have ways to listen to events on whatever piece you want. And if the data's really rich, then that's one way to go. So that's kind of what I was showing with the user has a friend's collection of other users. So that's instead of having this nested JSON, which again gets slightly more procedural, I have a change on the fifth friend in my user's arrays name field. Instead of that, I actually have a reference to the object for Emily or whoever it is in that collection and I can listen to changes on her or on that collection directly. So that's sort of the more back-point way to do it is to have models that have collections of their sub-resources inside of them. We're about out of time, so one more if there is one. Otherwise, thanks a lot folks. Enjoy the movies.