 I've been waiting on the edge of my seat so long that I'm so glad it happened. So hello, good afternoon. Thanks so much for coming and letting me talk to you about J3 plugins, how to keep them warm and toasty and a comfortable, cozy backbone view coat. As you can see, I have no slides anymore. Well, it just happens. Okay. Okay, so I'm really glad this happened to be immediately after lunch because I don't have to worry about any complaining that I'm showing you all this bread and carbs and you're all hungry, it's all fine. So, who am I? My name is John Paul. I work for Cognite Ass on the platform engineering team. I know there are a lot of New Yorkers here, so we are hiring, let me know. I love JavaScript. I have dalliances and things with other programming languages every once in a while, but I always come back to JavaScript because it's a great programming language. Well, I'll find me at all of these internet locations over here. I just tweeted my slides in case you would like to follow along with me. So, I want to start off talking to you about invention. So, us as developers, we actually are inventors. We just don't really consider ourselves as this thing. We consider ourselves more the gray beards, not necessarily the gray crazy mad scientist hair, but all we do all the time is create things to make things that work for our users and work for our product. And most often we do that from something else. Developers come at the invention process in what I think is two completely distinct ways. And sometimes we choose one over the other. Some people like starting with completely nothing. They like building up JavaScript applications from their base level. Maybe they don't want jQuery, maybe they don't want backbone, but they like to know every piece of their framework from the beginning. And some other people like to start with things that are existing. I think we're pretty much all in that category. Like backbone, like jQuery plugins. In general, we have deadlines. And once we have deadlines, we're going to have to choose something that's out there that will make us hit these deadlines, work faster, and be able to take existing pieces that are already out there on the internet and put them into our own project. Also, if you don't have this kind of toaster thing that makes the eggs, you should really go out and get one. It is awesome. It's the best invention ever. Make sure you use Pam for the egg trays. So, enter jQuery plugins. So jQuery plugins are what gives us this kind of functionality. It's the multi-tool of the front-end developer. Chances are everything you could possibly want to build has already been built out there in terms of widgets already that you can just take because they're really nicely really licensed from calendar, date pickers, modals, galleries, autocompletes, charts, maps. There's tons. There are hundreds on plugins at jQuery.com. They're about thousands. I should have probably looked at this count before. There are thousands of jQuery plugins out there for you to take. And jQuery's motto itself is write less, do more. This is that in and of itself. You take things that are really licensed for you to use in your own projects, in your own companies. You rely on these other plugins to give you the functionality that, for you to run your own, might take weeks or months to actually build out like a complex charting library or something like that. So when you actually start using these plugins, especially in backbone applications, what this, oh, I just now realized this timer has not started. How do you start this timer? Okay. Let's see what happens. So when you actually start using plugins, it ends up just being mountains of configuration. You copy and paste these things from their readme's and you start typing into your application. Okay, so I want this configuration option to be this and this other configuration option to be that because this is how jQuery plugins are intended to be used. The interface that the creator of the plugin gives to you is a big options object that you can configure and use any way you need it to. So if you look at AdiosMani, he has a blog post about how to build jQuery plugins and jQuery plugin patterns, and he has over, I think, 15 different plugin patterns. This is really great for the jQuery plugin developer because they get to build something that fits their own framework. They get to build something that fits their own company and workflows that they have. If they want to use your prior JS, if they want constructors everywhere and using new, they can build everything the way that they want it to. That kind of flexibility means that there are lots of jQuery plugins, which is awesome. It's great. We all get to share in this kind of environment. But in the end, all these jQuery plugins are barely a level above the spaghetti that we're all running away from when we run into background. We have the jQuery spaghetti. I'm selecting stuff and doing something with it for a long time. And Backbone gives us some sort of structure. When you start integrating in jQuery plugins to your Backbone application or pretty much anywhere, you're not that far a level above jQuery spaghetti. So what I want to do is explain how to wrap your jQuery spaghetti, wrap your jQuery plugins in a warm wrapper of Backbone views. And to show that, so I have a spectrum of toast here and I am personally, personally, I'm a second-row, last-toast kind of guy, but feel free to mentally change this to whichever toast you happen to enjoy. I don't think you can pull off buttering the last one, but whichever one you like, please. So, into Backbone. So Backbone has a few different parts, views, models, collections, routers. It has many more than that, but I'm going to now focus on the views. The view is where we have the most easy way to interface with a jQuery plugin and a way to encapsulate all of the logic that a jQuery plugin might provide for you. So as an example, I just have here the Yahoo! homepage at one point sometime in the past few weeks. Backbone views can be used to make these distinct widgets completely separate. So maybe there is a Backbone view that represents the navigation, a Backbone view that represents the weather and I want to focus in the center. There's a carousel. The carousel is one of the most common jQuery plugins that are out there to be used. I'm pretty sure I have copied and pasted jQuery, carousel, light into a thousand different projects. And a Backbone view can be used to represent all of the different logic that needs to go into what happens in that little center section. So, what do Backbone views do? Backbone views give us many, many things. I'm going to talk about a few of them right here. They give us widget initialization, basically something that says some code that can run when your instance is actually created or maybe when it renders and it binds to the DOM. It also gives a very nice DSL around a dead binding so you don't have to go through the typical select some stuff and then add some events of jQuery by itself. And most importantly, it gives organization. This is the most important part about all of Backbone. What Backbone gives us is a way to organize and structure our thoughts around what is necessary for a client-side application in the browser compared to what we would have done using jQuery. This is just a small example of what maybe Yahoo or whoever was making a carousel without necessarily having a jQuery plugin backing it could have done to create some code that had the same similar interface. So, if I'm in Backbone and I want to start using a plugin, how would I go about doing this? Traditionally, what usually happens is it really is just throw everything into initialize. This is what I've seen a lot of projects. I've done it myself and it really becomes a horrible mess because all I do is copy and paste what I used to have outside in my 10,000 line scripts.js file and then you got a little hiter and you made it main.js or something like that. But all you do is copy that into a Backbone view initialize, render or something like that. So, all this is, is it just moves the spaghetti that's outside inside? It's slightly better quality. This isn't necessarily a Rangoo. Maybe it's a Purnesca Boronese. I don't know exactly. Giada can pull off these words. I know I can't. But we're not necessarily any much, much greater place than we were before. So, we're walking along the toast spectrum. We're a little closer to where I want to go but we're still not as encapsulated as we could be. So, what's wrong with this is that this will really end up with all of the duplication problems that we had earlier. So, everywhere that we want to have this carousel represented. Maybe we want one in the center. Maybe we want a different carousel in navigation. Maybe you want a different carousel on another page. We're just copying and pasting this configuration everywhere. Now, this is, this is a problem and the way we can fix this is trying to stop repeating ourselves. We can separate the details that, that the jQuery plugin needs from the explicit views that actually use that. So, I'm going to move on to creating a carousel view. This carousel view has, it has initialized something that actually starts up that, some code that actually starts up the jQuery plugin and this carousel view can be used in multiple different places. It doesn't actually tie itself to any particular element. I want to show a particular thing here. So, underscore dot default. So, underscore dot default is an amazing piece of underscore that I don't know if everyone knows. It allows you to easily have a, pass it an options object and then add in defaults if it isn't already defined. This is something that's really often used in underscore and backbone. It's also very useful in jQuery. So, what this does is, if I'm using center carousel view like you can see on line 14, that's available. I can pass in options that if I didn't actually necessarily use, I can override them in my central carousel view because carousel view is what manages all of the carousels to all of my application. So, now we're moving, we're moving closer. We have a little bit, we have a lot less duplication. Now we have, where we're closer to the toast where I want to be, where we are wrapping things. But there are still, there are still some problems here and I want to talk about that. So, what's wrong now is that we have a lot of rigidity. What I showed in the previous example was the individual carousel view instances that are created from my carousel view class all have a lot of knowledge around the explicit interface that the G carousel plugin defines. What if one day I want to change that plugin? Because the whole reason I came up with this idea in the first place is because I was working on a project where we had dozens of carousels throughout the whole application and these carousels had a few particular features that fit well very nicely with what J carousel provided. But then the design and product team came up with this awesome new idea that was really easy to implement if I just had used some other plugin that was out there that I didn't happen to choose three months before. And because I followed the copy and paste mistakes and all of this, I had to deal with rewriting large squads of code because the information around J carousel's existence leaked out and that we need to try to stop that kind of thing. So something new will always come along. So we need to fight this pressure as much as possible. There's nothing. So death taxes and change pretty much guaranteed. The urge to a bike shit as well. So what to do here? So I have an answer to this is design patterns. There's been a lot of talks about design patterns lately because in this particular conference while this is the backbone conference, it's kind of sort of the rigor in JavaScript conference so I read like that. Awesome. So I'm a fan of design patterns but I have an issue in how at least I was used to learning it. Design patterns by themselves, if you just go through the Gang of Four book or happen to go through the design patterns in JavaScript book, it's really nice to know that there exists strategy and visitor and observer and all of these things. But without actually having an example we need to concretely understand why on earth I should care that there's something called the visitor pattern or something. So this is the case. I want to show you an example of a design pattern used in real life. So the example here is something I can use to describe, by describing this car. So this is what a car looks like underneath. This is the engine and the wheels and if we really wanted to understand all of this, we could. We could say that I understand how a spark plug works and how that actually drives the motor and I could actually have some maybe we could have one of my friends that I don't really like very much sit there with a spark plug trying to light it. I could have someone trying to turn the wheel behind me and I could maybe get a car working like this without necessarily the nice interface above that I'm used to. But we don't like to drive like this. We don't really like to think like this. We like to have a higher level, easier way to interact with something. For example, the dashboard, the wheels at the bottom. Maybe we know that when you push your foot on the accelerator pedal that that actually means that spark plugs go off and then the fuel line opens up and all of this. But we don't want to know about those dirty secrets behind how a car works. We just get in the car, push the accelerator pedal and when we're good to go we go where we need to go. So what design pattern this is is actually a facade. A facade is a simpler, over something that's much more complicated. We use facades all the time but don't really think about what they are or why they're not. So Backbone has many of them. jQuery has many of them. Backbone's model saved that figures out if it needs to post or patch or put all of this stuff depending on ID. You don't have to worry about that. Backbone just figures this out. Backbone history glosses over the other hell of push tape, which I don't know if anyone's gone through but jQuery is document ready. It does some crazy, actual horrible hacks in trying to get old IEs to try to figure out when the document is ready. It actually continues to scroll the page programmatically until an error is not thrown. Can you imagine writing this in your own code? We like relying on jQuery to handle this. It would be crazy. I would reject that forward. Similarly, so Ajax, there are different variations in different browsers. When you set a value on an input using jQuery, it doesn't care if it's a select box or an input box, it just figures out how it should be doing all of this. What we want to do is strive to get to this level of abstraction where we don't have to worry about the complexity underneath. Let's actually go through the process of building a facade. If I want to write a facade over, let's say jCarousel, or some plug-in in general, the important pieces that my facade needs to actually care about. If I'm in a car, I don't want to have a push button for a go spark plug. I want to have a push accelerator for have all this stuff happen. The way I go about this is there are three distinct parts that could be affected by a jQuery plug-in. The first one we got to start off by thinking about which parts differ around the different instances that you use this jQuery plug-in. If I use a jQuery plug-in for an auto-complete, maybe one of the differences that I have is the URL that I need to hit for the Ajax call to get back the tag that I'm searching for, or something like that. The questions that I ask are, does this jQuery plug-in need to be configured externally, like the example of the Ajax URL? Does the plug-in need to have some sort of external control, like being able to programmatically select an item, or programmatically move a few to the left in a carousel, because maybe Backbone Land will care about this, and the jQuery plug-in under 8 will provide some functionality like that. Additionally, maybe the jQuery plug-in has some advance that you would like to proxy through the backbone, like on slide to the left, or on slide to the right, or on tag selected if you're using an auto-complete plug-in. For a general config, I'll show this example, the particular ones I was showing earlier in my code slides, for a jQuery plug-in. We need to tell it somehow what the selector is for the element that, when you click on it, goes to the next, goes to the left, or goes to the right. Additionally, maybe a property around auto-start, so you want to say when the jQuery plug-in starts up, immediately actually start going through the plug-in. This is where you could go get your really large plethora of options and stick them all here. But chances are, out of the 40 or 50 different configuration options that any jQuery plug-in provides, you only care to override the defaults in a very small amount of cases. Ideally, you're writing your backbone if you use wrappers like this, such that you only need to expose to the places where your backbone can be used, only the information it actually needs to have. Here is an example of a carousel view that is written in such a way that breaks out its options separately from the options that are provided from the instances are separate from what actually goes into configuring the plug-in. So here, I don't want to use the name jcarousel next as my configuration option whenever I instantiate these outside because that would leak the information. I don't want consumers to know that I'm using jcarousel. One day I might rewrite this using the other one that will save me a lot of time when there's a new design or something like that. Or maybe one day I'll decide to forgo a jQuery plug-in what this does is the ability to give your own names to things so you can have a clean interface. And also, you can actually even go through and change names yourself just for semantic purposes. So jcarousel's auto start option is actually called auto. I think this is confusing. Auto doesn't mean something to me. Auto start I think does mean something to me. So when I go through the process of wrapping this plug-in, I can change that name using this pattern and it makes more sense for my application. So the next thing is, so we have the configuration options that we can wrap and change as much as we would like. Also, maybe you need some external control of that plug-in from your backbone layer. So maybe you have the ability to move left or move right or actually start and stop the auto progression of a carousel or anything like that. These are functions that are defined on the backbone view itself. They just happen to proxy through to your jQuery plug-in that has these similar kinds of action methods on them. So here I have an example of an extension to the carousel view. So if you were defining your carousel view, here you can define the methods that you need, like move right, move left, start and stop. And only inside of the definition of this carousel view does it actually need to reference take carousel. So you're just passing everything through. So you're existing on online 16, I can even see, that your existing views that are instances of this carousel view can use these named methods as if they were on backbone by itself and not have to worry about the fact that they happen to be implemented using a jQuery plug-in behind the scenes. The last one is proxy defense. A lot of jQuery plug-ins throw off events. All of the bootstrap things throw off events, like when a tag is selected here in a carousel, there are events that are fired when the animation queue, the automated animation starts and the animation ends. You can use this, for example, to update some counter around how many pictures you've got or something like that. Here, again, you just proxy these things through. When you have, you can define, similar this reminds me of the marionette slides from yesterday, it has its own render and on-clothes and things like that. You can define your own functions that you can provide when you instantiate or extend some of view that are named like the events that would be thrown from the jQuery plug-in. So in this case, jQuery plug-in has a slide start. Slide start is called I have defined an odd slide start that is mapped directly to when this plug-in, when this carousel view is actually instantiated, it checks to see if there is a slide start or slide end function defined on itself. If so, it maps that function directly to, it adds the event to the jQuery plug-in that says when this event happens call this function directly. So the goal here in all of these three different things is to decrease the sensitivity of your code to change. We want to hide all of the complexity behind these backbone patterns so that changes get much much easier when they come down the road in the future because they always will. It's, I took this picture because I really hate it when my toaster goes a little bit too far and suddenly it burns toast. You don't want to get to the stage where you have to worry about the mountain falling down on you because you've made simple changes in what you think are small parts of your application. This particular way of using the facade pattern can start to protect you from that, especially away from the potential spaghetti of jQuery and the jQuery plug-in. So I want to talk a little bit about the law of the meter. So Mark mentioned this yesterday and my obligatory cat video goes here. So the idea behind the law of the meter is that every piece of your code only knows about its closest neighbors and the minimal set of what it could possibly know. So all of the code that actually uses obviously I care about gun safety. So, you don't want to leak out information as much as possible. The code that uses your backbone views that happens for actually jQuery plug-ins, if they never know that their jQuery plug-in exists, you're not breaking the law of the meter. It's also called the principle of least knowledge which makes more sense because I don't know who the meter was or anything like that. And I hope you enjoy the cat. So, my goal was to get you to this toast because I love this toast. The butter melts perfectly. So I hope that it made sense. We are now at a place where we've wrapped the jQuery plug-in, allowed all the functionality that the jQuery plug-in would allow for you to do in a layer that is more pure to what backbone would expect to have. So we're building a backbone application. You can use these kinds of UI widgets backed by jQuery plug-ins, the plethora of jQuery plug-ins out there, to achieve the functionality that you need without necessarily always having across your code dropping down to that level. So, takeaways here. So jQuery plug-ins are a complete necessity. There's really no way around using this kind of code that's out there already because we have deadlines. But you don't have to use them as they are. You can use them in a way that makes sense with your own architecture and your own code base. Find what you need to customize and then build your wrappers in a way that fits those needs. Don't try to go out there and expect what could be needed in the future because in the end you will end up with the same API as the jQuery plug-in itself if you do that. Only take the bits and pieces that you actually need around configuration, around controlling what actions can happen to that jQuery plug-in, around what events that jQuery plug-in and all of these things will end up in a state where a litatory animated gif. You end up in a place where you make a small change and you don't have to worry about the entire world falling down on top of you like this guy does. Okay, so I have some resources here that you can check out in the links. I just tweeted my slides. Please feel free to take a look. Thank you so much. Anyone have questions for John Paul? John K. Paul was because his talk was better than okay. No. I dug myself a hole in that one. Anybody? Nothing? Obviously jQuery plug-ins are like, everyone loves it. Use them directly. Don't worry about all of that. We're going to take... I just wanted to talk a bit about strategies for when to render. A lot of the time, there's problems with initializing plug-ins before the DOM is inserted and stuff like that. So that depends on the... I forget who said this earlier today because I wasn't in all of the talks, but I saw the tweets around backbone in a framework. So it kind of depends on what level you are using above. I have most often used merian activity which gives you callbacks that define when things like that happen. So I haven't really had that issue. Also now a lot of my life is using backbone on server render HTML. So the DOM is always there. I'm just attaching functionality to it and then initializing these plug-ins in a nice way. So I don't really know that depends on your particular framework you're using on top of backbone to tell you or you should have some seam in which to say now it's in the DOM. That's expressed kind of the DOM. Go jQuery plug-ins. Go jQuery plug-ins, right? That was...