 Can everyone hear me all right? Good. I tend to be loud anyway, so that's always fun. All right, so I've got a couple quick polls for you. How many have seen the initial contextual jQuery video from 2010 or the one from the jQuery UK? Does anyone watch that? Just a few. All right, that's fine. That works out great because I'm going to give you a little review. We're going to talk about some really fun things today. My goal anytime I get up to talk is to give you ammo to go back to your jobs on Monday and have something that you can integrate into your work right away. So hopefully everyone here learns something today or thinks about something different or maybe approaches a project slightly different because of the talk today. All right, so the contextual jQuery series, there's a video for the most updated version of the first part, which is a jQuery UK. That's bit.ly contextual one. Don't worry too much about typing all these down. I'll post the slides afterwards and tweet them out. Contextual jQuery in practice was back in Boston last year, and that kind of went in a little bit more detail. That overlaps the most with what I'm going to cover today. And then the third part in this series is just in time, basically initialization and then user action. So that's what we're going to cover today. Contextual jQuery is a term that I coined and it kind of describes a way to approach jQuery projects that solves a number of problems. One of the problems it solves is that everything's ready and DOM ready. And this is a, you see this especially as people are getting started with jQuery or you're working on a multi-page site that keeps growing, keeps growing, don't have a ton of structure there yet. Pretty soon you get this kind of concept where, oh, I got to initialize all my dialogues. Maybe I'm going to set up a contact form. Don't worry about parsing this too much. I'll point out code when it's super relevant. Maybe it will make some Ajax requests and then you see my comment that I'll just say 100 lines of more code like this. And basically the concept is that you want to make sure every part of that page is ready all the time, any time that person's on that page. And we'll learn here just in a few minutes that's a little inefficient. The other one is finding and initializing just too many elements. So there's 1200 items in this list of this overzealous customer of yours and they're all drag and drop pieces that you're going to have an interface for. Well, that's a lot of items to initialize when they're really only going to drag and drop your four items in that session. Maybe another one is you have some special hijacking you're doing and you're trying to bind to every single element anchor on the page. In this particular case, the way this code is written, it would go and find all those elements and create separate events for them. Again, not tremendously efficient. Social widgets are like the worst kill for performance and trying to get things to load well. And even video widgets and other pieces that people put on your page don't have a ton of control over. Those things are highly inefficient at times and can really hurt performance. So you take the situation where you have ten articles and five share widgets on each one. If you just go with the concept, I'm going to make everything ready all the time, you're going to have all of those widgets loading. And that's just a ton of bandwidth DNS requests and other things that are going to slow your page down. All right, another one that we might not think about much. You've heard of require systems and build systems and ways to offset this, but just not even that complicated. Just kind of think about when you have large chunks of functionality that have limited use. So when there's an unbalanced bandwidth, amount of stuff you're downloading, maybe even the amount of stuff you're running, to usefulness ratio. So say you have an awesome startup and you launch your website and every single page has a sign up form at the bottom for your new service. Well, along with that sign up form is you have the latest and greatest automatically determines if your username is ready to go, if it's already taken, if that email address is already signed up. And you have that stuff running on every single time the page loads, regardless of if someone's just browsing your site looking to learn more information. That's a situation where you have an unbalanced amount of code. You have validation libraries, you have code, maybe you're even using something like Amplify Request to abstract your Ajax Request. You're loading all of this stuff to manage a piece of the page that they're going to rarely use. You want them to use it, but a lot of times it's going to be slowing down your site for no reason. An example I gave here is a contact dialogue and when you open the dialogue there's a map of your town. You would never want to initialize that prior to showing it because that's just a waste, especially if it shows up on every page. Alright, so all of these share a common issue and a common issue is that they're willing to sacrifice low time, waste memory, and often waste bandwidth to handle the fear that everything is ready to go at any particular time when a user would go to interact with it. Now, you would never do this in real life and if you've seen the video, any of the stuff that I've done before, the favorite saying is to write code like you spend money. And if you were anticipating this year going to 15 conferences, or not a 10 to 15 conference, say you found 15 conferences that looked interesting to you, you wouldn't go buy the early bird ticket to all 15 conferences and then decide which two you're going to. That'd be a complete waste of money, it'd be foolish, and everyone would be laughing at you. We do that with code, we load bunches and bunches of code, we run tons of stuff, we initialize all these things, when in reality most users are not going to use every part of a page all the time, every time they're there. It's just unlikely, it's highly unlikely. And so what's contextual, jQuery tries to get you to do is to focus your efforts on what you anticipate the user is going to be doing, what they might need to interface with, and kind of get those things ready at that point. So you have very fast load times, but stuff still works. Just again, a lot of this is summary, the videos that are available that will be in the slide notes, those will cover some of this in greater detail, just so we can get to our core topic today. A couple things that are handled, we suggest moving anything that's like hide, show, any visual stuff that you're running in document ready just to get the page to look right, should really be moved to CSS. Anything you can possibly do, you can use JS, no JS classes, you can use any number of things to move a lot of that to the CSS. So you're not running that stuff, running that showing and hiding with JavaScript. That will speed up some things. Streamline your document ready calls, make sure there's fewer selectors and less initialization. Again, you're going to be a little scared, we're going to talk about how to initialize that stuff later, that's what the topic is today. But you want to really get as much of that as your document ready as possible. Leverage delegated events, if you're not using those to the best of your ability, you're really missing out because it can really give you some great improvements because no selection has to run for those to be bound and ready to go. Whereas most events, traditional event binding, you're having to find the items first so that takes time and then actually go ahead and make the binding. Again, one of the parts of contextual jQuery is coming up with your own HTML conventions, things that you will follow throughout your website. They can change from project to project but throughout your website, you're going to follow these conventions and you can use those conventions to make highly reusable code that leverages a lot of these other benefits. And finally, instead of thinking of the page as this massive blob that you have to get already at the same time, you start to focus on individual components and how a user might interact with those and what would be triggers to indicate that they're planning to do something else that you can then make sure is ready to go for them. And this goes beyond just saving time. This goes ahead and you can even start loading stuff ahead of time before they request it to speed up the perceived speed of your site. So you can use this in not just this micro optimization way but also in general pieces across your site. So we've solved these amazing problems by following this thing called contextual jQuery which, you know, summarizing today, not going too much into detail, but it introduces new problems. So whereas once everything was ready to go all the time, now we have a situation where a very real risk is that a user will go to interact with a portion of your page that while the page loaded quickly, that component is not ready to go. And so they have a bad user experience because they can't, you know, manage the carousel or they can't sign up for your product. I mean, that would be devastating. So the other one is the user may be forced to wait. If you've waited to load some remote content, they may be forced to wait while you work on getting that solved quickly because you were trying to save time in the beginning. So that's what we're going to focus on today. And it's really a simple fix. All you have to do is anticipate what the user is going to do and do it. Right? That's pretty simple. All right. So it's not a simple fix. It's an easy to understand fix but not exactly a simple fix. Good news is you don't have to be a psychic. Your users are giving you information all the time about what they're doing on your site. I'm not talking about metrics, about analytics, just simple stuff that they're doing that you can pick up on. Every time an event fires from user interaction, they're providing feedback to your code about what's happening and maybe even what they're about to do. You have that feedback mechanism all the time and maybe you've not thought of it in that respect but that was really the user communicating with your code, giving indication about what they're about to do. It's the turning signal on a car that people fail to use. That type of thing where they're sending these signals or giving these events about what's happening on the page. And even the pages themselves, if you just think about this in a larger context, the pages themselves can indicate what the user is about to do next. And you can start optimizing for that situation so you're almost anticipating their needs. The interaction points that they're going to come up with, there's a number of them and there's probably more than just this list. But obviously a click or a tap, it's obvious. We know that they're interacting with a page and we can respond to that. Mouse enter, mouse leave. This is great when you're dealing with desktop applications. Obviously it has no application in touch devices at all. If you're building a responsive site, this will have limited use for you. Another one we're going to talk about briefly is mouse enter, mouse leave but with a delay. So you kind of can tell when they're over an element, but you wait to interact with it until they've been there a certain amount of time to kind of gauge how actually important they're going to find that part of the page. Focus and blur. This is one of my favorite. This one's really neat and it's one I think you'll find interesting when we get to that. Scrolling is another one you find leveraged quite a bit. It can be very bad if done wrong, but this definitely has usefulness. There's another indicator that they're doing something on your page and you can kind of anticipate based on not what they're typing but the fact that they're typing this part of your page, what they're going to do next. And then finally the resizing. That happens when they resize the browser and you have a responsive design or when they change orientation on their device, that type of concept, you can respond to those type of events. So let's talk about these in a little bit more detail. Click and tap. This is the most obvious form of determining user intent. They basically have just screamed at you, I want to do this and they click there or they tap there and they give an indication. So the action's definite. This is definitely your most foolproof way of indicating what a user wants to do. If they click contact us, you know what they want to do? Probably contact you or find your phone number or get to that page but you know that that's where they want to go. They've just been very clear about it. However, if what they've clicked on depends on external content, by the time they click it's too late. They're going to have to wait now for that content to load and hopefully you're showing some indication that that's happening. But again, it's too late. It's not really anticipating it. It's too late to catch up. So this is a great fit with local content that involve complex setup tasks. So maybe getting a bunch of dialogues ready to go. Instead of setting them all up right away, you can wait until they click on the button. That happens very quickly but you can move it out of document ready and just into when you need it. If you do tend to use it with remote actions and we'll talk about safeguards here in a bit, where this is kind of a safety net, then you do want to make sure you have loading indicators ready to provide feedback to the user that they're not waiting indefinitely for something to happen. You're aware that they're waiting. Alright, some tips really quickly here. When you're dealing with a click and tap events, depending on what you're developing for, always delegate this method. Almost always. There's always exceptions in everything I covered today. There's going to be exceptions. There's going to be things you find that don't work quite right and need to be done differently. But this is a great one to delegate and just take away that initial selection. Instead, bind it to a delegated event and let that fire when they interact with your page. Kind of treat this like the first step in a wizard. So if they're clicking on an item to show a dialogue, well, the very next step that they're about to see is a dialogue. So set that up and make sure everything's ready to go there. Now, again, if they click on something that's going to toggle and show content, that content that they're showing has a bunch of social widgets and a bunch of stuff that could be potentially slow to page load, don't show it until they go to show the content. And then you can go ahead and load that for them. Alright, mouse enter and mouse leave. These ones are fun, but again, have limited use on mobile devices unless they have a mouse feedback mechanism on the device. The action has high probability, but again, it has a lot of false positives. So just the fact that they move the mouse over an element doesn't mean they want to interact with it. It just could be they're getting on their way to where they're going and their mouse happened to go over the element. It's definitely more expensive to listen for, especially if you're delegating the event because every element in that area is going to be triggering this and testing against it. So this one has a little bit more limited usefulness. It works great for drag-and-drop implementations that we mentioned earlier. You don't want to initialize a thousand elements if they're going to only interact with three. So that's a great implementation for it. And again, I already mentioned it's useless on touch devices. Let's look at this example really quickly. Nice short example, document ready. I have div.item and I'm going to call draggable on it. Well, if I have a thousand items, it's got to find all those items. It's got to set those things all up. It's going to increase the memory footprint. And again, we're just spending tons and tons of money, tons of code that we don't know the user's actually going to need to use. So one way we could refactor this is to delegate on mouse enter to the document. Again, I'll explain in a second why you would want to do something slightly different. But just to give a quick example, this is delegating the event. It's going to find any item, any div with a class of item that does not have a class of UIDraggable. We don't want to double initialize these things. But if it doesn't have a class of UIDraggable, we're going to go ahead and set this up. Towards the end of the talk, I'm going to cover one-time initialization patterns like I'm using here. So you can avoid double initialization. So what this ends up doing is when UIDraggable is set up, it adds a class automatically to the element. So this will only trigger on the first mouse enter of an element that is not yet draggable. It will set itself up, and in future, it won't trigger this event. Now, a couple tips. Oh, here, I have an example. I forgot about that. Alright, so if you've been on TechCrunch's site, they've changed this in the last couple months a little bit. Not the design, but how they interact with this particular widget. But do you see the social widgets right there? Those aren't actually interactive widgets yet. They're just little pictures or indications of what could be there. For the longest time, if you mouse over any part of the article, that would immediately convert to the social widgets. So what they said was if they mouse over any part of this article, they're probably going to want to share it, I'll set this stuff up. The problem was if you were scrolling down the page and your mouse is in the middle and you're kind of moving around, it was just setting up all these widgets. So it's not necessarily the most efficient. So what they've done is they've made it so now if you only mouse over that area of the widget, then it loads in the social widgets. So they've been able to have all those things that they wanted on their page show 10, 15, 20 articles without the performance hit of loading in all of those social widgets right away. So they're implementing something very similar to what we're talking about today. Couple tips. When you do delegate, something that has anything to do with mouse events, delegation you can choose what is that the top level container that actually has the event that's listening for its children. Try to get that close to the items that are affected by it as possible. For instance, if all those div items were inside of a UL, go ahead and make that extra expense of finding that UL to start and delegate against that element. So you're not delegating and you're not binding to a thousand elements but you are delegating to its parent. That way there's a lot less events bubbling up that have to fail that test. So you can optimize that way. And then again, this is kind of like your last resort. If you can't use any of the other events and triggers we're talking about today, then maybe mouse enter is the right one for you but some of the other ones are going to be better and more performant. So keep that in mind. Alright, mouse enter, mouse leave with a delay. This one's a little better. How many of you is hover intent on a website? Okay, that's basically what we're talking about. I'm going to give an example that's a little bit more in depth than hover intent. The concept is you're going to say mouse enter, mouse leave, indicates they're about to interact with this component. Maybe I should set it up but you're going to wait just a little bit for them to find out if they're actually hanging there or they're just moving across the page somewhere else. It has less false positives which is great and that increases the probability even more. One thing I noticed the third point here requires a click safety net. If they move over something like say those widgets and they're just sitting there waiting for you to initialize and they start clicking on the Twitter one, you want to try to have a backup plan that would work really well so when you're optimizing you don't totally break the experience for the user. Hover intent works but again right now currently still have to find. I think there might be a beta that has some delegation involved but I use Ben Allman's do time out plugin. It's awesome for managing this type of advanced timing situation and I'll, when I post the slides also put some notes at the end and I have side examples of what that might look like but it's again you're basically saying alright hey they just moused over 500 milliseconds if they haven't left I'm going to go ahead and set this up and you have another way to cancel and another way to fire it immediately if they click and you have basically all of your options tied up in just a few lines of code so it works out really well. Alright scrolling this action has medium probability so it's not really high probability because the fact that they're scrolling doesn't necessarily indicate that they want to interact with that part of the page. However what it does do is it very clearly describes what they can't interact with. So if they're at the top of your site and you have this awesome footer widget with 50 million options they cannot interact with it until they're toward the bottom of the site. So what it does do is it does narrow the field of what exactly can be used at that time. So you can leverage this information to avoid setting up that crazy awesome footer that your CEO wanted until they're getting close to maybe 75% down the page and then you can set it up. And again that type of calculation shouldn't happen on every single scroll event that is a really bad way to kill your performance. But you can do some of this stuff by getting it ahead of time, getting information from the elements you need and then determining when they're about to scroll into view. If that sounds a little too complicated there are plugins that help you with this jQuery waypoints and jQuery sonar are two examples that help you with figuring out when stuff is coming into view. Couple tips work with that cache comparison data. You don't want to be calling offset on an element on every single scroll down the page. You just kill the performance and it was definitely not everything that would even be remotely helpful to what we're talking about today. So what you'd want to do is find out maybe on Dom Ready you'll do one request to find out where that element is on the page or maybe you'll wait just a little bit and figure out where that element is or how tall the page is. You can do it a number of different ways and then finding the scroll top from the window is very inexpensive. So you just compare one number against another number and determine what to do from there. So if you are working with some more advanced stuff where you do need to kind of find information while you're scrolling then you're going to want to throttle or debounce that. Yesterday I think it was either Meno or Elijah I don't remember covered throttle and debounce plugin from Ben Alman. That's great. If you're already using underscore it also has those methods and you can use that as well. So depending on what I'm doing with the project I'll use one or the other. Alright this one's the most fun because I think this is the one that kind of slips our mind and we don't think about as much. Maybe you've thought about some of these other ones in some form or fashion. But have you thought about the fact that form validation doesn't matter if they don't use your form and you can tell when they're using your form because they interact with the form elements. It's really really straightforward. So I mean your simple validation which is don't send an empty form go ahead and set up at the beginning. But all your advanced stuff like you need to have an email address it needs to work this way you need to have a user name that I'm going to validate against the server. None of those things matter until they've actually started interacting with your form. So you can actually listen to the focus event which is actually if you're delegating it's focus in and focus out to work around some event leveling bugs in some browsers. But it's focus in and focus out when you're using delegated events and again when I'm saying delegated you can use on and you're using it using the second parameter that gives you what element you're listening for. So this is great for if you're initializing autocomplete maybe wanting to get stuff from the server that's going to populate that at one time. Date pickers, validations, any part of form that you need to interact with first to submit. Those are all great times to set that stuff up. Again you find these type of wastes happen when stuff starts to be on every page of the site. But again there's no reason you can't if you're starting to think about it differently interact with these things on even pages that just have one form. Alright this one's fun. This was a little less useful than the input. Basically by the time they focus on a form and they're in that form unless you're just tabbing through your page chances are they're going to interact with it. They say the focus one's more useful. But this would be good if say you had a multi-step wizard and it's going to be four or five steps and they have to fill in the first step to get to the second step. Well you can render that page without all those other components there not even trying to request the AJAX ahead of time until they enter into one of your fields and start typing. At that point they're basically just screamed at you I'm going to be using this form you might as well get the next pieces of it. So at that point when you have they started interacting started typing on that form element and you could start to load in the additional pages of that wizard to make sure everything's ready to go. So now you've really balanced your cost benefit to make sure the user has what they need but that they're getting the fastest experience in the meantime. Alright so resize really comes into play when you're working with responsive designs where the functionality depends on the available screen size. So we're working on a project currently at Append 2 where at a certain breakpoint they have this really interactive video player and as soon as you hit around 600 pixels somewhere in there I think it's like 670 you know how breakpoints work you break it where the design breaks. It switches to not having that much of rich interactivity. So if they loaded it on say a kindle fire and they loaded it in a vertical orientation I wouldn't want to go ahead and set up that rich video player with the hope that they might turn the device sideways that wouldn't really make sense I might just not set that stuff up just yet. I could determine though when they did rotate their device and all sudden now they're getting a different layout that has that player in it. At that point I could spend that money again of interacting with that and setting up the widget. So resize works well for there. Again if you're doing it a lot or you're doing anything expensive, any expensive calculations in that callback make sure you throttle or debounce it and those things just to mitigate those issues. Alright so here's the crux of all of this. I've just given you a bunch of indicators but how do you use them? Which one of those ones I just covered is the most important? Well it's really hard to say and it's different in each situation so what you really want to look for is a beacon interaction alright so it's the first interaction that provides sufficient indication of intent alright that's a really long statement that just says you're really sure they're about to do something and you're going to respond to that. So the definition of a beacon is a fire or light set up on a high or prominent position as a warning, signal or celebration and we're using in this term the concept of a signal it's the user alerting you that they're doing something and you can respond to it in a certain way. So these are some beacons. These are concrete interactions. If someone clicked the next button on a slideshow widget for instance you know that they're interacting with the slideshow. They expect page 2 to show up potentially 3, 4, 5 and 10 and they're expecting these things to work that way. So that's a concrete indication. A mouse down or a touch start on a draggable element is an indication that they want to drag it. So make sure at that point you haven't set up that time or before. Clicking on a contact us link again we mentioned this earlier. These are all concrete beacons that say hey the very next thing that's going to happen is this and you can anticipate it. So then you have probability based indications. These are the ones where you entered an input field and we're like well they're there they're probably going to want to use the form. Let's get everything ready to go. Again the wizard I mentioned a mousing over a draggable element all of these are you're trying to judge. You're like okay I think they might be wanting to use this. Same thing with scrolling to the bottom of a page. They might want to interact with that form. At this point there's no harm in setting it up. Let's go ahead and do it. So let's talk about a real example. We've given a lot of philosophy, a lot of ideas, a lot of bits and pieces. So let's look at this slideshow. It's not really let's assume that it's smaller than this on a real website. So our slideshow example here is we're going to have any number, n number of slides and there's going to be next and left arrows. It's not a carousel. It's not going to automatically go through these things. It's a slideshow. They're going to have to interact with it. So we have three or four of these per page. We've got this really cool photography portfolio site we're working on and we want to make this you know adhere to these principles we're learning today. So the first way we might approach this is we have something with a class of slideshow and some UL in here with a class of slides and we're like all right we've got a list of slides here. There's links around the images and this goes on you know to as many slides as you have. Which is fine this is a typical way to set it up and then when I'm done ready you say hey I'm going to call my fancy slideshow plugin and we're ready to go off to the races. So every single page they hit now you're going to be setting up that and potentially wrapping each of those elements and additional elements setting up adding your arrows. It's a high expense for people that may or may not interact with certain parts of your page. So let's look how we could refactor this how we could do this differently. One thing I would do is I'd afford myself I'd put a little money up front again code I'd put a little code up front that says let's put my navigation in place here ahead of time. So I'm going to put it in here with my classes I'm expecting I'll have the first one disabled and the next one not disabled. So I put this in ahead of time so now I've added bandwidth right but I'm going to be able to use a very little bit of HTML to leverage this new this new thing that we're doing. So in this particular case I'm going to use this syntax sorry it's on so many lines it actually fits larger but you know I meant to zoom in so everyone could read these better. Is that better? Alright could have yelled at me you know that would have been acceptable. Sorry about that. Alright so I broke it so it would be able to do this. So in this case we're listening for a click event on some element that has a class of slideshow and again we're using a single initialization pattern that says that it doesn't have a class of slideshow ready and then where that's kind of our scope for the parent and then we're looking for this next slide. So what we've done is we've given a very specific rule that says in these situations on any of these widgets not any one particular one on any of these widgets if that next slide button is clicked now instead of setting the slideshow up at the beginning I'm just listening for that one event when it happens I'm going to first find the slideshow I'm going to find it's a parent element so I'm going to find the closest slideshow so I have a reference to it. I'm going to go ahead and initialize it and remember click next so not only am I going to initialize it I'm going to go ahead and advance that to the next piece so you might say well what about the slideshow is showing up wrong because the JavaScript is not there yet. Again move as much as you can to the CSS just handle that initial state of your page so you can handle a lot of that with the CSS so it shows up correctly to begin with. So now we have a situation where none of those elements are there are actually interactive until they interact with it themselves and they click on next at which point you can set that up. So this is just an example of something you can do but again we used a beacon event we listened for that initial click it's the first way it's the only way they can basically interact with that element to start. The other button is disabled so we have a really clear point of entry that we can then use and leverage. So now you're in a situation where you have oh great at one time I knew by the time the page was done rendering everything was ready to go now how do I manage the initialization. So there's a bunch of patterns we're going to cover just the basic ones today. There's more advanced ones using a finite state machine that are really fun for more advanced apps. Finite state machine works great with backbone type applications. But let's talk about the basic patterns quickly. Just a simple flag so in this case outside my event I bind a flag you notice I'm still finding an element I'm running a selection which we're trying to talk about not doing. In this case I'm going to find this contact us element when you click on it if dialogue is not populated that's with the not you know the thing is what it's called. Brain dump there. Alright anyway it's going to say the not operator there and it's going to reverse it. So if it doesn't exist it's going to go ahead and find that and set up a dialogue on it. If it does exist it's going to hit that else statement and just go ahead and open the dialogue. So the first time you click the button it sets up the dialogue. Second time you click the button after they've closed it it just opens the dialogue. So that's like the simplest one time initialization. You can use a jQuery one method so you have again similar concept except this time I'm going to go ahead and set it with a single event. So the first time this click is fired it's going to fire the top one first it's going to set up that dialogue and the second one is going to open it and basically it's going to unbind that first event. So then the second time it's clicked there's no event to set it up and it just opens. I don't use this one really much at all but you may find situations where you have one off stuff that might be helpful with this. So then we get to class name based and you know there's caveats with maintaining state in the DOM but in this particular case we're going to be adding a class called isReady. So when you on mouse enter the slideshow if it's not ready I'm going to go ahead and add the class of isReady but in there where it says code that's where you'd actually set it up. So that's class name based. This one here class and delegation this is my favorite. This is the one we've been showing today a couple times basically you make your delegated event only match what you need when it's not set up. So in this case I say if I clicked in the slideshow and it's not doesn't have a class of isReady. So as long as it doesn't have a class of isReady I'm going to match this and I'm going to fire the callback. In that callback I set it up and I add the class. Now again jQuery UI adds classes all the time so you can generally just leverage the classes it already has if you're using a widget or something from there. But in this case we're just going to explicitly add an additional class. The nice thing about this is now the delegation handle is never firing this again. We don't have to worry about it ever double initializing because it doesn't need to happen. It's already ruled it out. Alright, so I've rushed a little bit. We're going to take time for just a couple questions. That's what the questions are far and then I have a special thing I want to show right towards the end. So we have about three or so minutes for questions. Is there anything I can answer for you? Yeah, so the question was what's more efficient using the SizzleSelector type of concept there that I had. Let's go back to the example real quick. It said colon not and it's all part of the selector. Is that faster or is it better to just listen for the click and filter it by running an internal statement. So to answer your question it's going to depend on a couple things. It's going to depend on the type of application you're building. If the type of application you're building is a game and there's thousands of click events while they're interacting or tap events while they're interacting with your game then that could potentially be inefficient but it's going to still be more efficient than hitting your call back every time and manually checking if the class is there. I don't have a JS perf I can link you to that says that exact thing but having less code and it's also easier to understand what's happening. It just won't fire again. But I don't know if that answers your question. It does depend on how much to interact with your page. Most people don't click all around a page 15 times. It will special on multi-page apps. They're off the page after just a short amount of time. A single-page application just depends on what they're doing. And the question was if we have multiple blocks of document ready will that affect the performance? It's more of a maintenance thing. That's normally why you have that split up that way. If you could consolidate it and it's all in the same file I would do that but if it's for maintenance and it's separate I would look to focus on what's in that, what's running in each of those document readies and see if that can be moved off to a later initialization. The exciting thing I want to show you tonight is a preview or this afternoon is a preview of what the new jQuery designs are going to look like. So a while ago I started a work effort on this. Since then Darcy Clark, a number of people in the jQuery team, the jQuery board and a bunch of volunteers last night have been working on this. Another group that's done a ton of work on the inside of the pages is 47 Media. Jonathan Longnecker and Nate Croft. And so this is a culmination we were of what we're working on and what we'll be launching in the next couple weeks. So let me just go ahead and switch over here to give you an idea. We're trying to this is a comp so it's not responsive or anything. That's why there's white on the side. But we're trying to unify all of our sites so there's a global navigation that will let you quickly jump between our primary projects which are, this is kind of small up at the top. They're special people in the back. But the jQuery, jQuery UI, jQuery mobile, they can then open up and display all the projects, see more information about those. The stuff will be consistent. Right now you're on jQuery UI and you click on blog it's going to take you one place but if you're another part of the site click blog it might take you somewhere else. So this is all to unify across the sites. The outer frame, the entire site's responsive so it does scale down to mobile devices and that works really well. JQuery, let's see here, jQuery UI, again we have a consistent look and feel throughout the sites. So they all have different color coding and they all work that way. And then the one I'm really excited about is the jQuery plugin site. And so this will be I think the primary focus of probably the first site to get the new design. But it's going to have this incredible new look. It has information, you can fork it, you can see the github activity. And again all of this is going to be just responsive and we're trying to set an example for how sites should be built and again have that type of quality you'd expect from the jQuery project. So really excited to see this coming through in the next couple of weeks so we want to help with this, talk to Richard, talk to Adam, talk to the jQuery team about volunteering because there's still a lot of work to do, the designs are almost done, but there's still a lot of implementation. So we made progress last night but there's a lot more to do. So this is what you can expect to see in the next couple of weeks from the project. And with that I'm over time so thank you very much.