 You'll notice in my presentations that I do like to use memes. I find them to be very helpful in being able to get points across. So my name's Dave Methman. I somehow have ended up as president of jQuery Foundation and the lead developer of jQuery Core. I think the talking heads put it best. How did I get here? But I'm happy to be here. I'm very happy to be here. There are just a few things going on. Some of them are super secret projects, which if you would like to participate in, isn't this is kind of like, you're going on a mission. It could be a suicide mission, but please volunteer. The jQuery Foundation, which we formed earlier this year, really gives us a way to organize all of the work that we want to do to make jQuery successful. And that's not just code. That includes community efforts as well. And one of the things that we do are the conferences. We also try to work hard on the documentation and training and some of the super secret projects are related to these non-software development issues that allow people to use jQuery more effectively. But I don't want to give away too much about that right now. There's a keynote tomorrow by Richard Worth that will tell us a little bit more about what's going on there. Today I want to focus on code, because I like to code. So jQuery Core, if you take a look, we were on a pretty good pace here. We had pretty much a big release every year until last year. And then we kind of went crazy. We had three releases. And people say release early, release often, but those people don't actually have to keep up with all those releases. So we're going to slow it down a little bit. jQuery 1.8, we hope, will be out in July. It's our only major release this year. And if there would be any bugs, you know, we'd come out with 1.8.1, but maybe there won't be any bugs this time. But 1.8 fixed a lot of bugs that somehow managed to get into the previous versions. And like we always do, we use that as an opportunity also to make things faster. And add a few nice things. Quite often these are things that kind of start to crop up as really common problems that everybody faces regardless of their platform. And this time one of those nice things was CSS vendor prefixes, for example. So if you're trying to use, you see a lot of controversy about people who use just the WebKit prefixed CSS properties. And that causes their stuff to break when other vendors try to implement the same properties because hey, they only use WebKit. So we can actually dynamically use the appropriate vendor prefix if necessary for a CSS property that you set. We also dump some unneeded code. As time goes on, there are certain browsers that disappear into the distance. And we use each new major release as an opportunity to throw out things that we don't need anymore. And we also, something that we've started to do in JQuery 1.7 and will continue to do is deprecate what I call trip hazards. They're the things where people use them and they don't quite work the way they expected them to and they start reporting bugs against it because it's just inherently can't work the way people might intuitively think it should work. We deprecated Live, for example, in the last version. We're deprecating, and actually $.browser has been on the chopping block, I think, since JQuery 1.4. But we get people whining all the time, no, please don't take it out. But this time we really mean it. So it doesn't matter how much you cry, you're still not going to get the ice cream. We felt bad about that because we say, use feature, use feature detection, use feature, oh, and here's $browser. So the other thing JQuery 1.8 does is it sets the stage for some future work that we'll be doing. A couple of slides from now you'll see what that's about. In JQuery 1.8, we've got a really nice new build system built on a tool called Grunt. Ben Allman, Ben, where are you? You did a great job. And we've switched a lot of the JQuery projects over to Grunt, and we'll probably have to rewrite it all once Ben builds what he really wants to build. But it's been really handy, especially for the modularity, because it allows you from the command line to just say I want this module, but not this module. But one of the things about it is you really need to understand the dependencies. So it's really for advanced users, especially in 1.8, we don't have any tools that can magically analyze your code and tell you what you're using or what your plugins are using. But if you're building something where you know your dependencies, you know what parts of JQuery you're using, you can exclude those parts or replace them with parts from other third-party libraries that do similar things, but do them differently in a way you want them to be done, maybe because the platform is slightly different. It's a pretty simple option in the build file, and it's documented. We've made the mistake of documenting it, and you can actually figure out how it works by reading the readme file, so you probably will never find it. And there will be some blog posts to come describing it in more detail. So here's kind of where we're going. It's not quite there yet, but it gives you an idea of the kind of size savings that you can get. Let's say you're building a small mobile app, and it doesn't have any third-party dependencies, or if it does, you know exactly what parts of JQuery that third-party plugin uses. Let's say you know that all you really need is JSON-P, you're not using, you know, cross-domain cores or anything like that for your Ajax, so you just decide you're going to use a simple plugin for doing that. In JSON-P.1.7.2, you have one choice. You've got the big lump, and the big lump is 32.8 KB Mend and GZIP. In JQuery 1.8, we expect that's going to be about 24 K, and I'm including the 1.8 K that the JSON-P.js plugin adds. So you're taking out our full Ajax stack and just including a little Ajax plugin that does just what you need for that app. So you can see it can be a pretty big savings. Now there are ways to make that even smaller, but one of the reasons why it's not just a case of somebody going and checking a box and building a magic file is exactly this problem. I searched for best JQuery plugins on Google and you've probably been through this yourself. It's hard to imagine that there's 130 best JQuery plugins like on the face of the plant. I mean there's a lot of good ones, but and then, you know, there's ones like best JQuery plugins on Google. So a lot of people, including me at times, will say, you know, I need a plugin to do this. So you just go out on the internet and you say, I'm going to grab this one and you drop it into your project. But without some type of dependency management, you have no idea what it's using inside. So you're kind of in a world of hurt if you start chopping out pieces of JQuery. It's all just kind of a there's a project that was recently announced where it makes your JavaScript code work by just deleting lines until it runs. And that's kind of what you'd be doing here with JQuery if you don't have good dependency management. Now one of the other things we're investigating in JQuery 1.8 is the closure compiler. It's an experimental branch. It's not something that I, if modularity is for advanced users, closure compilers for really advanced users has a lot of pitfalls to it. You really need to understand the code. You need to understand the closure compiler and the way it works. And because of that, it's not something that I would say the average user will use. But we'd like to work with the closure compiler community to see if we can get this to be an option that's viable for JQuery 1.8. But that will be often a separate branch that we'll be kind of experimenting with after JQuery 1.8 is released. So, beyond 1.8, what's going to happen to JQuery? Well, we have some ideas. This is not one of them. What we want to do in JQuery 1.9 is continue our API cleanup. We've deprecated some things and we want to actually take them out, move them to a compatibility plugin. And the compatibility plugin to me always feels like a crutch. It's one of those things where I don't have the time to really make this work, so I'm just going to include this extra code that throws back in the stuff that we were trying to get rid of. But if that's what you want to do, we'll try to make it possible. And it's going to support all the same browsers that we support today, including IU6. But IU6 is really on live support at this point as far as ours. If you find a new IU6 bug, every once in a while somebody becomes a web developer graduates from high school and says I've discovered a new bug. JQuery doesn't make IU6 work right. And they say yeah, it's been that way for a dozen years. So you just have to learn to live with that. When you resize it, as far as the resize event, twice and we ain't going to catch and throw away one over for you. So once we get past JQuery 1.9, there's going to be JQuery 2.0. I'm not saying there won't be a JQuery 1.10, but that's a different story. This is the exciting part. So JQuery 2.0 will actually come out about the same time frame as JQuery 1.9. It'll have the same API as JQuery 1.9 and it really won't have any major feature additions. So you're giving me the Cosby face right now. Okay. So you bump the big version number and you're not doing anything, right? Well that just makes our job a lot easier. Thank you very much. Now, there is a major change that we're going to make. It's gone. So JQuery 2.0 won't be judged by what we put in. It'll be what we take out. Now, at times we've talked about people have said, you should get rid of IE and we've always said, it's really kind of hard to do that. Why did we do it this way? Well, you can't really do it as a plug-in. If you look at the way the JQuery code is, it's really a death by a thousand cuts kind of thing because you can't put a hook everywhere where you need to remediate IE, old IE. IE 6.7 and 8 just have too many little things that you're just having to always deal with. And we have a solution already for that since we aren't making any major changes between 1.9 and 2.0 from an API standpoint. We already have a solution. We don't really need to make JQuery 2.0 run in old IE because it's in old IE. So, what are some of the things that we get to throw out when we do this? It's a pretty big list. Now, maybe near the bottom I started to exaggerate, but it's pretty bad. And each one of these, again, isn't like thousands of lines of code. It's like three or four or ten lines of code that complicate the whole code path horribly. And every time you look at them, you say oh no, we can't, IE 6 doesn't matter. So there's always this situation where you'd love to clean this up but you can't clean it up. By removing those, we have a lot of opportunities to shrink the code base. It makes it faster because we have to do fewer feature detects at low time. It makes it faster because we have to check fewer of those things at run time. It makes it much smaller because all those little two or three line patches add up. And it allows us to make some design decisions. Like we had to have all of the data attached to an element off in JavaScript land. We couldn't attach it to a DOM element because there are two garbage collectors in IE 6 and 7. And the two garbage collectors never talk to each other. So by being able to eliminate that, we have some opportunities to even change some fundamental design to make things more efficient. And I also want to emphasize that this really is about mobile browsers. It's about modern browsers. So old IE is just basically about desktop but mobile is a lot more than just iOS and WebKit and Android. If you look at the new Microsoft Surface tablet that was announced, it's going to be multiple screen sizes. It's going to be IE 10. And it's going to have multiple input types. It's going to accept a mouse, touch, a stylus, probably be able to do the minority report stuff or, you know, there'll be lots of ways to interact with it. Something like responsive design probably isn't a bad approach to take there. But you can't assume, as a lot of people do, say with an iPad app, okay, you know, if user agent is iPad, then I know the size of the screen and I know it only accepts touch. You can't play those games. You can if you want with jQuery. You can basically make whatever simplifying assumptions you want. But jQuery itself can't make those simplifying assumptions because we don't want to lend it to you. So jQuery 2.0 will support modern browsers. And we want to do that because we want jQuery to work everywhere. And we don't want to break the web. Now you're probably thinking, well, wait a minute, Dave, a couple of slides back. I didn't forget. You told me that now that I use jQuery 2.0, IE users can't use my site. Not the definition of the internet is broken. I don't know what is. Well, we're going to support two versions. A version 1.9 and a version 2.0. And you're probably still because a lot of you are very demanding. I know it. You're probably saying, but Dave, my website, I want to use 2.0 and I don't want to wait, but I still need to use IE678. I know, I feel your pain. I know how that is. So what we've done is we've implemented in jQuery 2.0 what we call the tears of joy policy. You can actually, with conditional comments, if you feel so inclined, include jQuery 1.9 for your IE678 users, and then jQuery 2.0 for your newer browser users. That way you get kind of the best of both worlds. But you don't have to pay the price of all the old IE stuff on a browser. So one of the ways we want to try to keep that under control is to make sure as much as possible that we don't just add a bunch of new features that we have to kind of keep in both versions of 1.9 and 2.0 branches. And so part of that is to only really focus on things that improve global issues, things that exist everywhere. For example, the CSS vendor prefix is a problem that you see everywhere. Beyond that, we're going to emphasize plugins. Sometimes people say, but if you don't include it in core jQuery, then it makes it harder for me because I have to have multiple script tags on my page. And I try to point out, well, you can still use the CD and jQuery, but combine and compress all your plugins into a single file if that's what you want to do. But that way we're not making everyone pay the tax for something that you've decided that just for your site is really important, whatever that is. Touch events are a good example of that. There's two non-standard implementations of touch events. There's the WebKit touch events, probably the ones that if you've done a lot of mobile development lately, you're most familiar with. And then there's MS Pointer, which Microsoft's putting out with Windows 8 and IU10, but there's no standard. The W3C has tried for several years to develop a standard that was based on the WebKit touch events. And Apple seems to be kind of playing a cat and mouse game where they let it get almost to the end of the game and then they go, wait, overtime, we need overtime and say that they are claiming patents. So the W3C right now is stymie, but because of that we're back in this problem of having two completely different event models. This is not the time to try to incorporate touch events directly into jQuery core because if we do that, we're going to probably end up having to tear it all out and do something different and then we've created this dependency inside jQuery that people are going to have to figure out how to back it out. So for now issues like that should be dealt with in plugins until we know where those standards are going. Looking for Timmy. Okay, so I decided to do not do the Lawcat theme here. I'm a Futurama fan, but Timmy Willison is going to say have a few slides and talk about what he's done to make sizzle faster in jQuery 1A.