 Hello. Sorry for that, folks. I hope the presentation is worth it now, because you got to wait. I know this is the last presentation, and I'm going to be quick, I hope. So the title of my talk is a curated tour of awesome JavaScript sources, which seems like the sort of talk that someone who hasn't written any substantial JavaScript or isn't doing anything famous would give and you wouldn't be wrong. I want to preface my presentation with a confession. I am not a JavaScript developer. And before you guys all go up and lynch me, I want to continue that confession saying, I'm super excited by JavaScript. And that's because I follow some people online, some people that I think are super smart, and they're excited by JavaScript. One of those slides is this one, which says, always bet on JavaScript, which is by this guy. Does anyone know who that is? Yeah, this quote. Another quote is, this law that states anything that can be written in JavaScript will be written in JavaScript. Does anyone know what law, whose law this is? Yeah, it's a high five. So there's prizes for all of these questions. After the session, I'll come and high five you. So JavaScript is completely eating up the world. If you're not excited by JavaScript right now, you're living under a rock, you should get on board and try and learn the language. But there's a problem in the community. And that is something that Harish kind of stepped on with more passion and elegance than I can. But we have a frameworks and libraries problem. We're often lost in framework X and library Y and just writing glue code to make them work to get our stuff done and often not at all concerned about the language itself. And the thing about this is framework X and library Y are only relevant for a few months. And then there's a new hot thing that comes along and everyone's onto that bandwagon. No one remembers pure JavaScript anymore. The language that you used to learn and be excited about that concise little elegant language, you've all forgotten. You're all frameworks and libraries people. Hands up here. If you started using jQuery before you knew about prototypal inheritance. Excellent. So that's the problem with our community. Because JavaScript is so easy to get started with, often people just dig in without actually exploring the language or trying it out. But I'm not saying it's a problem we can't solve. Frameworks and libraries coming out are great. It's also awesome that we have this really vibrant, really active ecosystem of open source software where you see heaps of people contributing to open source and sharing their code. So we can leverage that by reading source from all these libraries and frameworks that are coming out. Hands up if you actually checked Angular source code. I see like 10 hands up in the air. So that's what we're missing out on. We can do all the two-way data binding and the fancy isomorphic JavaScript stuff, but we still don't know how it works underneath. You just write the squiggly brackets and it's magic. Let's learn from the collective wisdom of thousands of developers that have contributed to these projects. Maybe we'll learn a thing or two. And so today I'm gonna be talking about this little library that is quite famous in the client-side JavaScript world called Backbone.js. How many of you have heard of Backbone? How many of you have used Backbone? How many of you have checked Backbone source code? Oh, cool, that's a lot. I see some faces on the audience going, whatever, Backbone, that's so 2012. That's like six months ago. No, Backbone is still relevant. It's simple, it's only 1600 lines of code, the entire framework. It's very popular, some huge companies are using it. It's very mature, it's been out there for a while. It's also tried and tested. It has 230 contributors and more than a thousand watchers on GitHub that are watching every commit that's being made to the framework. So there's a lot of discussion and collective knowledge that's going into Backbone. It may not be in fashion anymore with these new frameworks, with their huge words that do fancy stuff, but even if you check out the source code you might learn a thing or two. So let's just begin. If you guys have your laptops open, then can you please log off Facebook and go on Backbonejs.org and actually load up the source code so you can follow along? Initialization pattern. Does anyone know what this pattern is called in JavaScript? Yep, correct, virtual high five. This is called an immediately invoked function expression. Backbone is using it here so that it's not polluting the global scope and keeping everything Backbone related completely encapsulated within the factory function that's there. And the factory function is great because as we'll see in the next slide, the function that the factory function is passed to can handle all sorts of dependency management that your developers might be using, the people who'll be using your library. So as an example, if someone is using AMD, anyone know the full form of AMD? Sweet. If anyone's using AMD, then you're just getting all of your dependencies and then calling factory with that. If anyone is using Node.js or Common.js style modules, then you're getting, using require to get the dependencies and then calling the factory or plain old global scope. These six lines, it's six lines that you should be adding to any library that you're writing because it will reduce friction for developers who are gonna be using that library by a lot. They don't have to deal with any of the dependency management when trying to invoke your library. It's all done there. It's only six lines. Backbone events. So as the previous speaker was discussing, events are pretty cool and somewhere down the line, every application would be using a couple of events here and there. Backbone implements its own event system and we're gonna look at that. So this is a function that tries to change multiple event names and events passed in as objects into just single event names. If you're in the source code, you can just grab for a events API. Now, if you see the first line, it's a simple if statement that checks for something and then just returns if that condition isn't met. Does anyone know what that pattern is called? I'm sorry? No one? Gang of four design patterns? That's called the guard. So you'll see that a lot in Backbone where it just checks for something and if that condition isn't satisfied, it just returns the result because it's not needed anymore. You can see you can pass in an object instead of a name so you can go on change, do this function, on blur, do this function and it will just go, okay, call on with just the change and call on with just the blur. If you're passing in multiple things like change, space, blur, space, on click, whatever, it just breaks it down using that regex and then calls individually. Really simple function but it's added there just for developer convenience so you can bind those events in multiple ways that's convenient for you. As you can see, if you're passing in change blur, it passes false and just calls like two times. If you're passing in an object, still false. If you're just passing in a single thing, then it returns true and you'll see how this is used later on. So this is a simple on function. So when you go object.on change, do something. Ever wondered how that worked? It's really simple. All it does is make sure that you're calling events API so that it's normalized into single events if it's passing in as an object or multiple events and then it just creates like an underscore events key in the object and stores them there. So if you have some object and you're going change all some function, this is all that it stores, which is mind blowing. Did not know that. Very simple, very easy to follow, very elegant. You can access it directly. I wouldn't recommend that though. Trigger function, very easy. As you can see, another guard, if there are no events, then there's nothing to trigger. Let's just leave. Otherwise it gets the arguments, checks that the trigger function is also the same as everything else. So if you're passing in an object or if you're passing in multiple events, then it normalizes it, it's just one. And then it just fires like the events for like the single thing and all events. All events fired for everything. This trigger events is an interesting function. So if you have some object and you go trigger, change and then some other arguments, it'll be calling trigger events twice, one for just the change function and one for just the change event and one for the all event. You can see that the arguments that it's passing are different. For the change events, it's just the arguments and for the all events it's what was the actual event plus the arguments. Trigger events, this is a very strange function. Why would you do that when you could just use the last line? It's faster. Who would have thunk? Don't be afraid to write ugly code like this if it's backed up by solid performance benchmarks. Call is obviously faster than apply. There's a JS perf that's made by the author of Backbone that compares this style of events with the older style of events and this is like 30% faster. Backbone events off. As you can see, another guard. We're just checking if there are any events. If there are no events, then you can't turn off any events. We're normalizing the events again. If we don't pass in a name, a callback or a context, we want to turn off every event. So you just set this, the underscore events to nothing. Otherwise, you're looking at all of the keys in this. If you provide like a name, so if you just want to turn off, say change, then you're just doing that. Otherwise, if you don't provide a name, you want to turn off, you want to iterate through every event. While you're iterating through every event, you map all of the events to a retain event and just check if a callback was passed. Is the callback matching? Then we don't want to retain it. If a context was passed and the context is matching, then we don't want to retain it. Otherwise, we retain it. And if there are no events to retain, we delete events again. Very simple, very easy to follow. This is great. This is another convenience function. Oftentimes, what you want to do is for your view to listen on events on the model. So this inverts the control so that the view goes, I am listening to this model on this event. So it's sort of like if A was an object and B was an object, it's similar to A on something, but it's like B.listen to A and this event. This is purely like developer convenience. Backbone also makes sure that the events that they added like ages ago are still maintained for backward compatibility. So it's making sure that developers are not pissed off by new stuff. The events mixing. Once you've abstracted away that events mixing, Backbone uses it six times for everything. Make sure that your mix-ins can be added to other classes. Think hard about the abstractions you can make in your mix-ins. If Backbone had an abstracted away events and just written it six times, that would be a thousand lines of code. Let's do a detour and check out the underscore extend method, which is really simple. It's just you give it an object and you give it a list of other objects and all of the properties of the other objects are copied onto this object. This is really, really, really good for writing your mix-ins and extending your classes using mix-ins. This is a very simple example. This is all that it does. Really simple pattern and even the underscore source code is really awesome to check out if you have time. This is really clever. What Backbone does here is it's got a model and it's got functions that underscore provides that it just adds onto the model class. So it's not writing any code. It's not using underscore. It's just saying these functions can be directly used by my object. You'll see that again and this time more prominently for collections. Imagine how much code they're saving just by reusing source code written by some other library and just mixing it in to your classes. Backbone Router. Does anyone here know like how Backbone Routes work? I'm sorry? Yeah, so a hash bank. You define like a route and then let's say you visit a URL. How does it know? I'm sorry? Yeah, so on hashing it has to check which route matches, right? So how does it match? Regixes. Yes. This beast of a function here converts simple Backbone Routes to Regixes. And it's not pretty. Let's say we've got a route here. For those that are not familiar with Backbone Routes, anything that is in parentheses there is optional. Anything with a colon in front, we want to like get that bit of the URL fragment. And anything with a star in before, we want the rest of the string until a question mark. So a really simple route. Pass it to this and we get that regex. It was so big that I can't fit in one line. You know what they say about regexes? Blank. What they say about regexes is, let's say you've got one problem and you decide to use regexes, now you've got two problems. So let's follow along how it does it. Like how does it actually convert this route to a regex? First, it makes sure that anything that is a valid character in a regular expression is escaped properly, which makes sense. But do you see that dollar ampersand there that it's using in the replace call? How many of you knew that that was the last matched part of a match? Less than five people. Excellent. Then we're checking like optional params and making sure we're adding the question mark colon. Does anyone here know what question mark colon does? I'm sorry? Yeah, it's there in a comment. So I'm sure you guys are reading along. So yeah, if you want something matched but you don't want it remembered in your matches, then you use that. And obviously a question mark at the end is, that is optional, so that's what we're doing here. Simple stuff. Next up, we've got named params, which is even weird. How many of you knew you could pass a function to replace? That's one person, two. Whoa, sweet. Yeah, you could pass a function to replace that gets the actual match and whatever optional string that you want to give it. The splat param is easy. That's what we have. And at the end, Batmone adds its own rejects to get any query string parameters. Extract params is simple. All it does is it gets a rejects route and it gets the fragment that is supposed to, is matching that route. And it just makes sure that you execute that fragment with that route and get all the named parameters out of it. So let's say we have this really complicated rejects route and this is the fragment that matched it. Extract params would just give you the stuff that was preceded by a colon, so all the stuff from the URL fragments that you want. The router. Obviously, another guard, you're making sure that if a route is not a regular expression, you convert it to a regular expression using the function we just saw. So this is very Batmone. It's very flexible in the type of arguments they take. So if you're not providing it with a name, then you make sure that the callback is the name. Oh, sorry, if the name is a function. So you can define routes two ways, like a route with a function or a route with a string that is a function in the thing. And it just adds that route to Batmone history and history just keeps track of all these handlers. So when a route is matched, that handler will be called, the router will execute the callback, trigger a few events, just to make sure that anyone that needs to know that the route has changed, knows that the route has changed. This is the Batmone history navigate function. So whenever you wanna change your state in Batmone, you just go navigate to this URL fragment. So you just go navigate to page or post or whatever. It gets the root of the Batmone app, the root where you said your app should live in, gets the fragment. Then it just makes sure that it's not the same fragment as we are on right now, so we don't have to do anything. Does all these complicated stuff, just to make it work with like cross browser issues, make sure that we're using replace state or push state and this pushes that state. If options with that trigger was passed, it calls load URL. Load URL just goes through all of the handlers that the route passed onto Batmone history and sees if any of those handlers has a route that matches like the fragment that we just navigated to. If one of them matches, we call the callback that was passed in with the route. Check URL just checks whether like the current URL is valid and if we need to like navigate to it. So it just checks if like this fragment, it just gets this fragment. Does this iframe stuff for older browsers for compatibility reasons? Make sure that we're not like the same as the current thing. If it has changed, then we're loading the URL. So this is how single page apps work. Like those backbone router and backbone history is all you need to know to know how single page apps work. You specify routes that are converted to regular expressions and stored both on the router and the history. You hijack click events on your site and whenever the click event occurs, you just call navigate function of the history. History navigate will get the fragment from whatever URL you're on and go through all of its handlers that the router passed in and see if any of those handlers can handle that new route. If it does, it calls load URL, which just calls the callback, which calls the function that is handling that route. And that is your single page app except a little bit of a caveat. There's a lot of cross browser issues that backbone deals with here. Backbone extend. I love this pattern in backbone. There are often times when someone new to JavaScript comes up to you and asks, how do I implement classical inheritance in JavaScript? So you know like classical inheritance and you know prototypal inheritance, but do you know how to implement sort of classical inheritance in JavaScript where you can override methods, add static properties, access the parent static properties, access the parent's prototype? One, yes. How many of you can implement this? Oh, sweet. But most people just go, I have no idea. Like, I don't know. This is a pattern that is used by backbone at the very, very end that is used by everything, models, collections, everything. Whenever you're writing a model, you always go backbone.model.extend. This is that extend pattern. What it does is it takes properties that you wanna put on your child's prototype and static properties that you wanna put on child. So obviously the parent is the object that the extend is associated with, so parent is this, create a new child. If there are properties you wanna put on the prototype and it has a property called constructor, then we give child that value. Child is that constructor. Else, we create a new function that just calls the parent's constructor, like it should in classical inheritance. Then we extend the child with parent, so all of the static properties that were on parent and any other static properties that we had passed in. Then we create the surrogate function that just sets the constructor on its prototype to child, the new thing that we created, the new function that we created, and then it sets its prototype to the parent's prototype so we can inherit from the parent's prototype. And then it sets child's prototype to a new surrogate. So you can see the new surrogate is like a proxy into the parent prototype. If there are properties on the prototype that you wanna add, we're extending the child prototype with those properties. So if you wanna override any functions on the child, this is where it gets done. And then we add this underscore underscore super as a direct link to the parent prototype. So if you wanna access any functions that we might have overridden or whatever, we can still access those here. So let's look at a simple example. Got this parent class function that takes an ID and just logs something and calls init. And init just goes in parent class init, and then it has a static property called parent. Simple stuff, you can create a new parent class. Its ID is this, init function's called. You can check the static property and it's parent. Now we added extend to it, go child class, parent class extend. We want to override the init function and override the class name static property. Easy. Now, instead of the parent init, the child init is called, but the constructor is still the same because we didn't pass in a constructor into the prototype properties. And the static property has changed as well. But we still have access to the parent's project. So if you want to call any function on the parent, we still can, and we can get that static property on the parent as well. How awesome is that? Like, mind blown, simple little function that can implement that. So, at the very end, vanilla.js is awesome. Every fancy library framework out there is written in plain old JavaScript. Pick your favorite library, framework, whatever, view source, read what's happening, follow the discussions that are happening about it. Don't just go to Stack Overflow or go to the doc site and just start using it. And just start drinking that kool aid of the magic. And share and learn what you get from it. Share and learn the things that are interesting. That's it. Hey, you got our first question down here. Yeah. You're not a JavaScript guy. Yes, I'm quite sure. There's a lot to the language that I still don't know about. Anyone with a question? Hi, I have a question ready to binding. How you are doing two-way winding in Backbone? Backbone doesn't support two-way binding. So, there's a plugin called Backbone Marionette, which does, I think. So next year's conference, I'll come up with awesome curated sources, some other edition, and I'll figure that out. But I seriously don't know. But it's open source, view source.