 Hi. I am Rebecca Murphy. I am a JavaScript developer at Boku. I never know which of these slides to put first, like that one or that one. I'm a JavaScript developer at Boku and today I want to talk about how, you know, this is a jQuery conference. We're all here because we like jQuery and because we are either using it or planning to use it in our jobs. And what I want to talk about today is how we can think about how to do our jobs and how to make, especially applications on the client side, using some patterns that kind of go beyond the traditional get some elements and do something with them approach of jQuery. So, before I get started, like I said, I'm a senior JavaScript developer at Boku. That's me. That's my Twitter. That's our website. And I'm also the author of the much outdated but still sort of useful jQuery fundamentals, jqfundamentals.com, which if you have been working on learning jQuery, you've probably passed by that once or twice. And these days I spend a lot of my time talking about and thinking about and helping clients with client side application organization. So helping them and talking about how, like I said, you can go beyond the traditional DOM-centric approaches that we've kind of learned and start to create code that is well organized, maintainable, pleasant to develop with, testable, and decouples our JavaScript from the HTML on our page. Maybe even uses JavaScript to create the HTML on the page. Maybe our HTML is not coming from our server anymore. Maybe instead we're actually creating the HTML just from the data that's coming from the server. So this is kind of what we're seeing happening with JavaScript these days is more and more of this client side, of the logic of our applications is moving to the client side. So before we talk about that, though, I want to talk about kind of where we've come from, which is this. This is how many people were writing JavaScript before jQuery came along? All right, about 30% of you maybe lived in that terrible, terrible time. And this is what we wrote then. Is it IE? Is it IE for Mac? Remember IE for Mac? That was a thing. Netscape 4, good times. So this is what JavaScript used to look like and this is what, these are the kinds of problems that as front-end developers we used to spend our time on were these agonizing browser differences. And then of course in 2006 jQuery came along and it wasn't the first library to give us some tools that kind of smoothed over those browser differences, but we can fairly, all 600 of us who have paid money to be in this room to hear about jQuery, we can pretty fairly say that jQuery won. jQuery has established itself as the go-to library for DOM manipulation, Ajax events and effects. And it lets us mostly ignore browser differences. You know, God bless them for still fixing our IE6 problems in IE7 and IE8. It lets us mostly ignore browser differences and focus on writing code that does what we need it to do. The sweet spot of jQuery, if you go to the homepage you'll see this, this little box and this is what seduces everyone because it's like, that's like English, I can write that. The sweet spot of jQuery is to get some elements and do something with them. That's kind of the story of jQuery and that's kind of the principle that you learn with jQuery and that's pretty cool because it means that you can take some markup that might look like this or just like a little search form, whatever. And you can write some JavaScript that looks like this, and this uses the new deferred functionality so that's pretty cool. So you can take that HTML and write some JavaScript that looks like this, just like 15 lines of JavaScript and from that you end up with a working application, like boom, done. It's pretty great. But the problem with that 15 line approach, and I'm not saying that 15 line approach is wrong, it's just that it is, it maybe you may discover that it is short sighted. Because when this simple app where you search for cats and it shows you some tweets about cats, turns into this app where you search for cats and you need to keep track of your recent searches and you need to show videos and images and stuff from Twitter and then maybe later there's a feature request to be able to like a result or something like that. So when that simple search app evolves into this, then it's really easy to end up with code that looks a whole lot like this. Who's seen code that looks like this? Every single one of you. Who's written code that looks like this? It's okay. I got paid money to delete that code. It was a lot of money. And it's, yeah. The end. Bye. No. So the problem with that approach is that it's very much a black box. So your view, you know, the user interface, you can see we're making some HTML here and sticking it in the page in our JavaScript. The user interface, the interaction with the server to go out and get the data and the management of state. All of that is kind of a black box. And so if something goes wrong, or if you want to reuse any portion of this code or God help you if you want to test any portion of this code, then really all you can do is test that the end result happened. It's very difficult to test any individual steps along the way. And it's difficult to, it's difficult to, like I said, derive any benefit from this code elsewhere in your application, especially as your application grows. And so you'll very quickly end up with something that looks like that code I just showed. So the story is really that get some elements and do something with them takes us so far. And it's really, really tempting to keep using that get some elements and do something with them strategy because we've grown so accustomed to it and it's so warm and fuzzy to us. It's really tempting to continue to use that strategy as the needs of our applications get more and more complex. And the reality is that as your application gets more and more complex, you need to start rethinking kind of the fundamental way that you think about your application. So in this talk, I want to look at how we would build something like this slightly more complex application. Of course, how many people have heard of client side MVC? Alright, how many people are using some sort of client side MVC framework? Alright, a decent number of you will talk about that a little bit more in a minute. Just like jQuery, I need you to stay within the pool of light I have been told I need to stay within this aura. Sorry, video person. Here it goes. So just like jQuery kind of changed everything as far as how we how we dealt with, you know, client side development back in 2006, 2007, 2008. And that was kind of the hotness and that was kind of the skill and learn. I think what we're seeing now is that it's becoming more and more kind of expected that you know jQuery and the new hotness, the new thing, the new, the new like thing to put on your to do list if you have that was a joke. Not even intentionally though, the thing to put on your to do list, if you haven't yet is learning about client side MVC. Of course, you know, some people will be like, it's not really MVC, it's MVVM or MVP or MVP, I don't even know. And so I like what Alex Sexton calls it. Because that pretty much covers it all. So the examples that I'm going to show you use backbone. Of course, there are lots and lots and lots and lots of choices out there. I've ordered them alphabetically so as not to express any favoritism. And this is just a tiny, tiny portion of the choices out there. And we did a training yesterday, a pre conference jQuery training yesterday and someone came up to me afterwards, a couple people came up to us afterwards and they asked two interesting questions. The first question was, you know, we were working on this application and we think that maybe we should look beyond jQuery and maybe maybe we need to start considering one of these client side MVC frameworks and like how do we know when it's time to start considering this. And my answer to them was, you know, if you're asking this question, it's time. It's probably past time that you'd be thinking about this. So if your voice is going off in the back of your head that maybe this would make life easier, it probably will. The other question that they asked, that someone else asked was, how do I choose? How do I know which one of these is right for me? And I think that right now we don't know. Backbone came out about 18 months ago. I gave a version of this talk about 19 months ago and Backbone hadn't, didn't exist last time that I gave a talk kind of like this. And so Backbone came out and it was kind of the answer to jQuery isn't enough, I need something more and Backbone was kind of the answer to that. About 12 months ago Ember came out and Ember was sort of the answer to, Backbone isn't enough, I need something more than that. And so I don't think, we don't have an answer yet. It depends a lot on what your needs are. My advice to them and my advice to you is that if you are trying to pick a framework, try them, go to to do MVC, just Google to do MVC and look, that shows a bunch of different examples of all these different frameworks making to do apps. So go to to do MVC and check that out and see what you see and then make some prototypes and you see what it feels like to use each of them. Backbone is really easy to learn. Ember is a little bit harder to learn, it's more complex but like Yehuda was saying to me at lunch, he was like, we embrace the fact that we are more complex because we also do more for you. So maybe in 12 to 24 months I'll be able to get up here and tell you, oh use that one but I don't think that we know yet. So before I dig into the backbone code, I wanted to talk a little bit about one of the challenges that we face when we start moving our code out of a giant document ready block, for example, is we might want to have our code in more than one file and for the sake of our development sanity we might want to have our code in more than one file. Of course we want to serve as few files as practically possible in production and we want to be able to write modularized code that is loosely coupled, maintain that in individual files, be able to express dependencies between our files and so be able to say this file requires these two views, this page requires these two views. We need a way to express that and RequireJS is a great tool for that. I just wanted to talk about it for a minute because I don't think anyone else is talking about it at this conference and it's something I think is really valuable. So RequireJS lets you write little modules like this, so this says I need jQuery, I need this text template HTML and I'm going to return a function from, so I'm defining a module and my module's definition is this function that gets returned. So return a function that places that HTML in the body, not a very exciting thing. But the cool thing about this is that we can have one script tag, both in development and in production, we can have one script tag on our page. That script tag loads RequireJS itself and then points to a configuration. That configuration looks like this, this configuration sort of tells RequireJS everything that it needs to know about how to load all the dependencies for your application. And RequireJS resolves all these dependencies asynchronously, kicks off your code, it's amazing. And so ultimately our main JavaScript file, our app.js, looks like that, there's nothing in it except a pointer to hey, make me a router. And we can structure our code in all these different small files that make the development experience a whole lot more pleasant. And tomorrow you'll learn about Grunt from Ben Alman. Grunt is a command line automation tool written in JavaScript that runs on Node that can take, it has tasks and some of the tasks that it has are tasks that integrate with RequireJS. So you can automate the production builds of all of these tiny files into one production ready file when you're ready to go into production. So I just wanna mention that but let's take a look now at this actual app and how we would start to think about approaching this when we think about it in terms of an application instead of as a website. This is not my water but we're gonna pretend it is and I'm gonna drink it. Probably Adam's, we hugged, it's cool. So when we think about our application as an application and not as just a website, then it's useful to start by thinking about the different responsibilities that our code is gonna have, that different pieces of our code is gonna have, are gonna, grammar. So we have the user interface piece which is the piece that we're most accustomed to working with and the one that we think about as front-end developers all the time. We have the user interface piece, like what is it going to look like on the screen? And also when a user interacts with this user interface, what is going to happen? What events are we going to listen for on the user interface? Are we gonna be listening for clicks or focus or submits or those sorts of things? Number two, we need to manage state. And this is something that in jQuery land, you're kinda, you have a few different options. You can use the DOM to manage state, you can use data, the data method to manage state or data attributes to manage state. You can do your own state management by just keeping objects around. And of course you also need to deal with data in general and so going to the server and getting data. In client-side application development, we wanna be a bit more rigorous about how we are working with data, getting data from the server. We don't wanna be making raw calls to dollar.ajax to go get our data. We wanna have some nicer structures around that. We also wanna make sure that state management is separate from our user interface. And then finally, we need to be thinking about how we're going to broker communication between our application state and data and the user interface. So when something changes in our data, how is that change gonna manifest itself in the user interface? When a user interacts with the user interface, how are we gonna get that interaction? How is that gonna manifest itself in the data? So in our little search app, where again we're just typing in a search term, we go get some results. The results are of different types. We display the different types. We keep track of the recent searches. So in this little app, we have three different views. We have our search form, we have our results area, and we have the recent searches. And of course when the user clicks, when the user submits a search, there's two things that we need to do. In the user interface, we need to update this results area. We need to update the recent searches area. And we also of course need to, in order to make that happen, we need to go fetch the data. And so backbone is not as opinionated about how to do this as I wish. I tend to introduce the concept of a controller into backbone, even though backbone doesn't strictly, they use routes. Back when I, I like to have a more strict concept of a controller. And so in this demo app, which is on GitHub, so you'll see the link later if you want to poke around in it. In this demo app, I have the idea of a controller and the controller sets up these views. It listens for the views to announce user interaction. So these views, they don't go, when you click that search form, for example, and we'll see this in a minute, when you click the submit button on that search form, the search form doesn't go get the data. The search form just announces that someone has searched for something and its job is done. And then it's up to the controller to say, oh, I care about that. And then the controller tells the, in the case of backbone tells the collection, hey, go get me some data for the search term. And then when that data comes back, it gets that data to the right places. So finally, we have this, I listed them in a different order on the first slide because it's easier to explain that way. I've gone sort of in a different order here. But finally, we have our actual estate management or our data management. So for that, for this simple little app, we have sort of four different kinds of things that we're managing. Number one, we're managing the searches collection. It keeps track of which, what the recent searches have been. So that's where we'll store, every time someone searches for something, we'll add a new search term to that. Number two, we have the search data, search results collection. I've named that terribly. We have a search results collection that actually goes and gets the search results from the server. We have an app model that kind of keeps track of general application state, including the current search. And then we have a search model for that represents the individual searches. So those individual searches become entries in the searches collection. So it's up to these pieces to do the actual, in the case of the search results collection where we need to go talk to the server, it's up to the collection to go talk to the server. The search form doesn't talk to the server. The search form just announces that something has happened and that message ultimately gets to the search collection which goes and gets the data. And when that new data comes in, it announces, hey, I have new data. And then that message gets back over to the results area. So importantly, models and in the case of back bone collections may be used to manage actual data that lives on the server and that you need to go get. But they can also be used to manage more just state information or data that never really leaves the browser but that you need in order to keep track of what's going on in your application. So they can be used for both. So if we draw a picture of kind of what our app looks like when we break it down. Like I said, our search form announces that someone has searched for something. So we click on that button and it makes an announcement that someone has searched for this term. And then the search controller hears that announcement and it says, search results data, here's the new term that I need you to search for. It also says to that list of searches, hey, someone just searched for this. And then when the search results collection goes off to the server, it gets its data. And then when that comes back, it's actually the search results view is waiting for these search results collection to announce it has new data. When the search results view is hears that the search results collection has new data, then the search results view takes that data and uses it to update itself. Likewise, when the recent searches collection announces that it has a new data, then this recent searches view updates itself. So if we look back at our naive jQuery example, and I don't use naive in like a mean way, but just like how you would write this if you weren't thinking about client-side application organization. If we look back at our naive jQuery example, the view, this kind of is the view and the model and it's everything. And so this whole piece of code is responsible for fetching the data and updating itself. And this is where that gets you. We went over that before. So let's zero in on this what the code looks like for this transaction of making a search. So here's our search form. Well, here's a little bit of our search form view. And it's pretty simple. So we say that when the search form is submitted, then we want to run the underscore on the search method of our search view. And it does some stuff to make sure that someone actually entered a term and blah, blah, blah. But once it's done verifying that this is worth announcing, then it triggers an event on itself called search. And it passes to that as an argument in that event, the term that was searched for. And so this is it. This is all that this view does. It doesn't care what happens next. And that's a key concept in when you're thinking about actually developing applications is writing code where this is just sort of fire and forget. And it's up to the controller to decide what happens next. So our controller is waiting to hear that announcement. So it says, hey, when the search form announces a search event, then run this update function. And we won't go into what all the update function is doing in too much detail, but ultimately what it does is it goes out and it tells the search results collection to go get some new data. And it tells the recent searches collection that there is a new search. So we get that message to the model, to the collections, the search results collection, and the recent searches collection. And then when they announce that they have new data, the results area and the recent searches area are waiting for that new data to arrive. And so here we add a new search term, for example. So this is us updating our list of recent searches. And so when we add a new search term to our list of recent searches, then our results view, here you can see, it's waiting to do this. So it is waiting for a add or change event to happen on that search data collection. And when it does, then it empties and updates itself. One of the really cool things about this approach, and I encourage you, it's hard to go through all the code for this in this talk. I don't even try. So I encourage you to poke around in the code that's on GitHub and poke around in the actual demo app that's up on Nojitsu. But one of the things that's really cool about having these loosely coupled modules that do one thing and don't get all wrapped up in the whole process, is that it's actually incredibly testable. And so I used Mocha to write some tests for this. And you can also, if you download the code and fire up the server, you can actually see these tests running and see the tests and all that. But it's incredibly testable. It's incredibly easy to test. So we can write a test that says, hey, can you verify that when there's a new search made, can we verify that the time, so what happened there is that if a user searches for a term that they've searched for before, then we don't make a new entry in the recent searches. We just update the time stamp on that existing search so that they'll end up being ordered properly in that recent searches area. And so we wanna verify that when someone makes a search for something that they've searched for before and we call this update method, we wanna make sure that this update method does indeed update the time. And so we can check to make sure that when we call this update method, we do indeed update the time. And so we can, when we break our code down into these tiny little bits and get away from these long chains and get away from these giant callback functions attached to events, when we write individual little bits of code that do one thing and do it well, we can write tests that give us a high degree of confidence that our code is actually doing what we expect it to do. So likewise we can test that when there's a new search, that the recent searches area gets updated as it should. We can write really simple little five line tests like okay, I expect to not see Baz and then I'm gonna search for Baz and then I expect to see Baz in the recent searches area. And so we can write really simple tests that verify that those transactions are happening as we expected them to. I'm, well my computer says I have two minutes left. This says I have seven minutes left. I don't know which one's which. So I'll spend a minute talking about this which is, I work for Boku. I do training and stuff there as well as doing consulting and we have a couple of trainings coming up that you might be interested in since you're here. What I really wanna talk about is one that we have coming up in September. It's not even on the website yet, but I'll tell you about it and that's we're gonna, if you're interested in this testing stuff which I think a year from now that's what I'll be here talking about is testing because I think that's kind of the next thing for us as a front end developer community. Like okay, we got through browser differences. We're gonna figure out how to develop client side apps. Like I feel good about that. I feel like we're on the right track to that. And then the next thing that we have to figure out is as the things that we're building get more and more and more complex, we're going to have to figure out how to automate the quality assurance of them. We're going to need to figure out how to prove without clicking buttons all day that the code that we wrote works. And so I think that that's kind of the next thing and I'm excited about doing a training on it. At Boku later in the fall. So if you're interested in that go there, sign up for the mailing list or follow us, et cetera. And that's me. So thank you very much. And check out the demo on GitHub and you can check it out on Nojitsu too if you want to just like search for things for fun. Thank you. Thank you.