Is JQuery much slower than pure JavaScript ?

You might be correct, there can potentially be more abstraction in JQuery with what you are doing when compared to pure JavaScript.

But do note, JavaScript is client side based so it depends on your computer. So if your computer was processing something else it could have appeared that the JavaScript was executing slower. It all depends on what is processing.

If you were using AJAX to send a request to the server, then perhaps the server was being used a bit more and the request on the server’s end simply took a bit longer to execute.

But if you can determine that the environments were pretty much the same, and it is JQuery, I guess it comes down to your personal choice. I have seen the same effect using the Dojo Toolkit, it is much slower than pure JavaScript. But if you are OK with the delay then keep using JQuery, if not, back to pure JavaScript.

I always think about the end-user, what is important to him and it is always the performance issue. Something to think about…

Javascript has gotten very fast in modern browsers, and jQuery is very performance focused. It’s unlikely that you could measure any performance difference beyond a few milliseconds between jQuery and pure javascript, unless it’s for a very specialized purpose.

I suspect there is something else going on that’s throwing you off.

As @ben said, jQuery is pretty quick, but has it’s own pitfalls that come with the simple syntax. If one of my scripts is running slower than expected, there are a few things I tend to look for.

1) selectors – sometimes while writing an initial version of something my selectors won’t be as specific as they should be, so rather than $(‘a’) or even $(’#wrapper a’) you should probably make them as specific as possible, a tie in to a specific id is always best when possible but remember jQuery has to loop through all the available elements that meet your definition from the start. So make that first element as specific as possible (instead of body, use div#header or ul#nav), searching for classes $(’.classname’) can be especially troublesome without something in front of it to narrow down the search. Because you’re familiar with pure javascript, think how you would do it there and keep it close to that when possible.
2) loops – it’s amazing how quickly nested loops can add up, especially when you’re looking for particular attributes or an element as discussed above. The .each() method is powerful and useful, but if you’re using it too much it can really take some time. Three nested loops with only 10 elements a piece has the chance to loop 1000 times, the same loops with only 5 more elements in each takes more than 3 times as long.
3) DOM manipulation is usually the most time and processor intensive aspect of a script. (so creating, inserting, etc)... If I remember correctly, innerHTML is still the quickest way to get things done. So for simple things, and when it’s practical, have your server side piece send formatted html. When that’s not possible, try to create your snippet outside of the document and then drop it in as one piece. So rather than inserting a div, then inserting a list, then inserting the list items, do all of the creation on a snippet outside the document and insert it as a single unit. This makes it so the browser isn’t trying to render each piece as it’s dropped in. See if it makes a difference.

Different browsers still have different points they hang up on, so you may want to try a few to narrow down what’s causing the delay you’re seeing. Usually for me it’s one of the above.

When all else fails, google “optimizing jQuery” and someone has probably run into the problem you’re having before.

Writing something “purely” will always run faster than writing on top of a higher-level framework like jQuery—it’s a trade-off in terms of initial development time and having readable code for revisions. Whenever it’s convenient, I default to pure javascript and use jQuery for the more complex stuff. You can definitely optimize your script’s performance though. One thing to do is every time you call $(selector), save that into a variable instead of running it again the next time you need the same elements. You can also optimize the selectors themselves: there’s a good article I found the other day about the performance of different ways of selecting elements. Especially if your HTML is complicated, it looks like it’s actually not uncommon for some methods to differ by a few hundred milleseconds. Adding a tag name (i.e., “p.class” instead of just ”.class”) to all selectors seems to make a big difference.