I started writing this right after the jQuery UK event but have only just found time to finish it off sitting in Stansted airport at 7am.

jQuery is a funny thing; it's made JavaScript coding easy for advanced developers and accessible to web designers, and you could even say that the web designer role has very much changed because of it. It's made web interfaces much richer and interactive. But, it's also made us lazy because it's so easy to use. It's time to take a step back and start thinking about best practices. And sometimes that might mean not using jQuery.

I was really pleased to hear Christian Heilmann's talk on moving back to using native methods, rather than always using jQuery (you can read Christian's write-up and get see his slides here). His reasons for this were:

• To encourage education about native browser functionality
• Native browser methods can perform better

This latter point is of particular interest to me. Whilst at Caplin Systems I was part of a development team where performance was critical. We were (they still are) building realtime web libraries and UIs which need to deal with both high frequency of data updates and large data sets displayed within the UI. I met up with Rich Chamberlain, Caplin's dev manager, about a month ago and he reminded me of this. So, I set about comparing document.getElementById('someId') with $('#someId') and unsurprisingly the native method was by far superior.

For the results of this, and to test for yourself, see Considerations when updating the DOM to display realtime data.

What was surprising was just how much better document.getElementById is. You would assume (I haven't looked at the source) that within the $ function that the selector would simply be checked:

$ = function(selector) {
  if( isIdSelector(selector) ) {
    var el = document.getElementById(selector);
    return warpInJQueryStuff(el); // el could be null
  }
  // else …
};

Ok, it's probably nothing like this. But you get the idea. So, what is it that makes using jQuery comparatively so expensive? My guess is that it's the warpInJQueryStuff. One of the parts of jQuery that makes it so powerful (all those functions you can call after selecting elements, and the chaining functionality e.g.

$('.something')
.doSomething()
.doSomethingElse()
.soOn();

The same goes when the selector isn't just an id attribute selector i.e. a more advance CSS query.

$ = function(selector) {
  if( isIdSelector(selector) ) {
    //...
  }
  else if( isQuerySelector(selector) ) {
    var els = document.querySelector(selector); //**TODO: check**
    return wrapInjQueryStuff(els);
  }
  // else …
};

The jQuery library shoots itself in the foot a little bit here because they've added non-CSS selectors (I can't find an example right now but a google suggests this is correct). However, this isn't anything that a RegExp couldn't test for and if the jQuery-specific selectors aren't found then the native function can be used. Again, maybe it's the wrapInjQueryStuff that's the problem?

Anyway, the point is: don't always use jQuery. As with anything, consider what you are trying to achieve and if performance matters, or you just want to learn, use the native methods instead. But remember to check for browser support.

If performance matters and you find this type of thing interesting then Doug Neiner's talk on Contextual jQuery will probably interest you too.