I love jQuery and like most modern web developers it was the gateway that got me into heavy AJAX development. But like all things that make life easy it comes with a cost and that cost is performance. I find myself caught between using jQuery and just going 100% native at this point in my career. The thing that keeps me using jQuery is its rich set of utility functions, structure and of course the fact that almost everyone uses it.
As someone who focuses almost 100% on 'mobile' platforms I know jQuery is not optimal. In fact my first expectations of jQuery mobile were thinking it was a mobile optimized version of jQuery, not a heavy UI layer. I think jQuery 2.0 is going to be more like what I expected 2 years ago, something much leaner and customizable.
But never fear there are solutions to some of the performance overheads associated with jQuery, Native DOM selection methods. First realize jQuery is an object that can contain a reference to a DOM element(s) based on a selector you supply. A jQuery object is rather large in scope and as such requires time to instantiate, plus when you pass a selector it has to select the targeted DOM node(s).
While jQuery abstracts the need to understand and manage the differences between different browsers you could do this yourself. While I don't recommend you do this for real production applications (especially if you need to hand them off to junior programmers to maintain) I do recommend you get familiar with native DOM functionality.
I saw a recent quote on Twitter (so you know it's true) that 96% of all active browsers support querySelectorAll. While that number may or may not be exactly true, I believe it to be accurate enough. This is significant because it makes traversing and selecting specific nodes using CSS syntax much easier than it was just a few years ago. In other words you do not need jQuery's Sizzle selector engine as much as you did before.
I found a table listing DOM selection methods you might want to reference. The querySelectorAll method returns all elements matching the CSS selector you pass it. Other important methods are getElementById (an oldie but a goodie) and querySelector which returns the first matching element.
To prove my point I created a simple jsPerf test to demonstrate the speed difference between jQuery and the native selection methods. The first two test cases compare getElementById and querySelector against the equivalent jQuery operation. I wrap the test up by creating a new jQuery object with the results of getElementById and querySelector so you can see the speed difference by creating a new jQuery element from a DOM node reference.
As you can see getElementById is the fastest by a long shot. The native querySelecor method is next followed by the normal jQuery calls using the id and class name. This is as expected. I also want to point out the speed gained by creating a new jQuery object from pre-selected node elements, especially when selecting by an id. It is around twice as fast!
The speed gained by passing the node retrieved from querySelector is somewhat faster, not terribly significant though. getElementById is really the fastest selection method available, so it helps a lot. The overhead associated with creating a new jQuery object is felt the most here too. I wont get into the internals of the jQuery Sizzle engine here, but it does add a lot of overhead where today's browsers do not really need it. This is why the jQuery team is working to stream line jQuery. Removing the Sizzle engine alone will save lots of kilobytes making your application faster and then you consider the speed gains by just using native selection methods more direction and you will see applications running a lot faster.
So my point here is use the native selection methods when possible and pass the Node results to jQuery when you need jQuery help. Most modern browsers are going to make your life easier with new DOM selection methods. I think understanding more about the browser's native methods will make you a much better web developer and improve the overall performance and experience your applications have. I am not going to stop using jQuery, but maybe the way I use jQuery.