jQuery Keynote 2010


These are my notes from the jQuery keynote given by John Resig at the jQuery conference in Mountain View, California

14 days of jQuery was a huge success

  • jQuery 1.4: We improved our delegation support and got
  • performance imporovements.
  • jQuery 1.4.1: bug fixes and performance improvements
  • jQuery UI 1.8 RC1
  • Forums
  • New API Site
  • jQuery Metups
  • jQuery.org


We've seen explosive growth in jQuery, especially compared to other JS frameworks. At the end of every year, around the holiday season, each project always sees a dip in interest due to people travelling. To get over this, in 2009 and 2010 we started off the new year and do a major release to pick up our traffic after everyone is back from vacation. (It helps that jQuery's birthday is January 18.)

We're pretty solidly dominating the market of javaScript toolkits. Currently about 1 in 3 websites on the internet uses jQuery, which is pretty awesome. We're up 8% globally since September.

Last month, jQuery.com had 26M page views and 3.8M uniques (up from 1.7M in September!) We've been improving the reliability of our sites and making the site more useful, for example with the new API browser.

What's coming up?

The Widget Factory was being considered for core, but we are going to pass on bringing this into core. We couldn't find a way to de-couple it from the inherent jQuery UI-ness that exists. It's really hard to extract in a way that's useful for other plugins.

Script Loading is technically simple to solve, but logistically very challenging. We want to preserve execution order and do dependency management. We wanted this in jQuery 1.4, but we ended up holding off because we weren't completely satisfied with the code.

Script loaders are frequently mis-used. They can be used to dramatically speed up your website, but sometimes you'll find users who are new who require one module and hope things magically work, which unfortunately can come at a major penalty in performance. We want to make sure users don't make that mistake.

We want to provide the ability to download script asynchronously and in parallel, hopefully from some highly-cached URL like a CDN. This is something we continue to look at, especially with dependency management. In most server-side languages, you import some file, and any of the file's dependencies are loaded, and that happens in a matter of milliseconds. In a browser, it becomes a huge issue, and hundreds of milliseconds. You're doing a whole bunch of synchronous HTTP requests, which is horribly slow. We are not planning on shipping a script loader that does dynamic dependency management: the ability for someone to shoot themselves in the foot is far too great. But I think we can ship a script loader that loads based on static dependencies, quickly and in parallel.

The only way to guarantee execution order from remote domains is to wrap your scripts in some container function. So, you can't grab any script from the internet and include it in your page; you have to modify it first. Including a script loader could require you to edit all your script files. However, if we put the plugin files on a CDN, we could wrap the scripts automatically. We're still considering this.

There's been a lot of interest in Templating in jQuery and a lot of great templating plugins.

Data Binding is a way of connecting the view represented on the page, and the underlying data represented in that HTML. This is what we hope to achieve with our data binding plugin.

We want to make sure that this plugin supports progressive enhancement from the beginning, like we do in jQuery UI. You will be able to extract all data from existing elements on the page. Additionally, you can sync and pull additional data from a server. We'll specify additional formats so that you can, for example, load a table with some data pre-loaded on it, and users with JavaScript enabled will be able to load additional data from the server.

Additionally, you can attach additional displays to a single data view. If you have a list of users that you can click through and a view showing the current user, you can do that in five lines of code. This is very complex and hard to achieve, but we think we've stumbled upon an excellent API that gives you the power and terseness that you'd expect from jQuery.

We're pushing standardization. By this point, it's pretty obvious that jQuery is THE way to interact with the DOM. Almost every other framework has implemented the jQuery API. We see an opportunity to communicate with standards bodies to make sure that everything gets appropriately implemented in all browsers, so that we don't have to keep doing this!

In the ideal world, JavaScript libraries would not exist. We can try to get browsers to provide better APIs and have them ship by default.

I've been talking with the different standardization bodies to try to come up with a good API that everyone is happy with that we can start shipping in browsers. I want it to be easy to use and easy to extend, but allowing room for performance to grow out of it, and also a security model.

All of this centers around NodeList. If you do some queries now, you'll get NodeLists but there's not a whole lot you can do with them. I'm proposing to make them a more useful, first-class citizen, to allow developers to create custom NodeLists, and extend the NodeList prototype with custom functionality.

jQuery on Mobile Devices is a phenomenal amount of work, but it's something that we feel is very important. When I talked last fall about wanting to develop for mobile devices, we didn't have a clear strategy yet. Since then, it's become clear that a lot of the things we thought we knew about mobile browser development weren't true. Importantly, we want to be able to ship a copy of jQuery that is just like regular jQuery, and not some special one-off build of jQuery. We don't want a jQuery mobile build, we just want jQuery to work properly.

We decided to make sure that jQuery as it stands today works on mobile devices, in addition to all the desktop devices that we currently support. We're expanding our browser coverage quite dramatically.

But, what mobile browsers should we support? Yahoo and Google have browser usage information, but they are not releasing it at all, especially what versions of mobile browsers access their site.

One of the few sources that releases information is StatCounter. They've started to release information about what browsers are being used globally, which is interesting to us because jQuery is so much larger than just the US.

The top browser globally is Opera (we don't know if it's Opera Mini, which is a proxy, or Opera Mobile.) The data on mobile browsers is still not complete, and we still have to sit down and figure out which browser to support one-by-one.

We currently support:

  • iPhone, iPod touch, iPad
  • Android 2.1
  • Nokia S60v5
  • Palm Pre

We're working to support:

  • Opera Mobile
  • IE Mobile 6.5 & 7
  • Android 1.6+
  • Blackberry 6.0
  • Nokia Maemo
  • Fennec (on Maemo)

We won't support Opera Mini, because it cuts off JavaScript after two seconds and ships the data in some non-HTML format.

That's more platforms than we support on the desktop! Providing this level of support is very time-intensive.

For testing, we've been using TestSwarm. We have a lot of mobile devices running automated tests for each build. This is something we're pretty excited about, and it's really cool to see the automated tests running in action. This will help us tackle many more platforms.

[John showed some pages from http://swarm.jquery.com ]


Thanks to all the speakers, coordinators and sponsors.

Thanks also to John for speaking.

Did you enjoy this post? Please spread the word.