To jQuery or not to jQuery?

Question

I rather enjoy adding practical eye-candy to the networking community I've been developing but as things start to stack up I worry about load times.

1. Is it truly faster to have users load (a hopefully cached) copy of jquery from Google's repositories?

2. Does using jQuery for AJAX calls improve/reduce efficiency over basic javascript xmlHTTP requests?

3. Is there a practical way to cut down the number of included scripts? For example, I include jQuery and jQuery UI from google, table sorter, and a growl plug-in.

Answer 1

1. Unless your server is closer and faster than Google's servers (which is highly unlikely, except in an intranet), it is always faster to load from Google.
   ​
   Even if your server is closer and faster than Google's, they will still be faster unless the copy isn't cached and you load it from a different domain. (Because of the two-connection-per-server limit)

2. There should be no measurable difference between a jQuery $.ajax call and a raw XMLHTTPRequest. (Unless you're making millions of AJAX calls, in which case you have other issues)
   However, jQuery's API is far easier to use.

3. You can paste all of your jQuery plugins into a single (minified) file.
   The best minifier currently available is Google's Closure Compiler, followed by Microsoft's AjaxMin.

Answer 2

1.Is it truly faster to have users load (a hopefully cached) copy of jquery from Google's repositories?

It can be, unless your computer is not connected to the internet. If it's a corporate application and the scripts are available locally, I can't imagine a need to use Google's servers.

2.Does using jQuery for AJAX calls improve/reduce efficiency over basic javascript xmlHTTP requests?

The principle reasons for using jQuery are that it's really useful, and that it abstracts away browser differences. Those benefits vastly outweigh any miniscule increase in performance you might get by writing your Ajax calls in bare-metal Javascript.

3.Is there a practical way to cut down the number of included scripts? For example, I include jQuery and jQuery UI from google, table sorter, and a growl plug-in.

Not if you want all of those capabilities.

JQuery UI allows you to download a custom collection of scripts that contains only those capabilities you need.

Answer 3

1.Is it truly faster to have users load (a hopefully cached) copy of jquery from Google's repositories?

Yes. Google's servers are geographically positioned to serve the page from the location closest to the user to improve performance.

2.Does using jQuery for AJAX calls improve/reduce efficiency over basic javascript xmlHTTP requests?

jQuery uses XmlHttpRequest internally, so it won't be any faster. It will only be as quick as the browser's implementation of XmlHttpRequest.

3.Is there a practical way to cut down the number of included scripts? For example, I include jQuery and jQuery UI from google, table sorter, and a growl plug-in.

To cut down on scripts, you'd have to combine them all yourself and host them on your own servers/CDN. Google only provides a limited set of popular AJAX frameworks.

Where jQuery really shines is in its layers of abstraction that help you avoid dealing with cross-browser incompatibilities. In this regard, it does a fairly good job.

It also beats out many other JavaScript frameworks as far as performance. Remember, any time you add a layer of abstraction, you're going to lose some runtime performance. Where you lose that runtime performance, you make up for it by the cost savings to your developers because they can easily develop JavaScript code.

Overall I wouldn't be too concerned about jQuery performance unless you notice it becomes a problem. And in this case, try to identify bottlenecks and optimize those. Simply using jQuery is almost never the reason for a slow site.

Answer 4

Q1: Is it truly faster to have users load (a hopefully cached) copy of jquery from Google's repositories?

Won't the browser simply cache the javascript after it's loaded the first time? I think it's irrelevant if you load it from google or your own server.

I suggest you serve your own versions of jQuery's library to not have sudden problems if a future upgrade of jQuery decommissions a function you used in the application you wrote 2 years ago. (if you use google's latest jQuery.js)

Q2: Does using jQuery for AJAX calls improve/reduce efficiency over basic javascript xmlHTTP requests?

No efficiency change here. Only easier for you to program.

Q3: Is there a practical way to cut down the number of included scripts? For example, I include jQuery and jQuery UI from google, table sorter, and a growl plug-in.

Who cares about the number of included scripts? This shouldn't be a factor in your design decisions. If you need it, use it. If you don't, then don't include it. Host all your libraries on the server running the app on, and stop worrying about that.

Answer 5

Whether loading jQuery from the Google depository is faster or not depends on a lot of factors. Google has a lot of servers, so if your users are spread over the world it's likely that it's closer to a Google server than to your server. On the other hand, the browser has to open another connection which is slower. The only real advantage that you can hope for is that the file is already in the cache so that it doesn't have to be loaded at all.

Using jQuery for ajax calls is not more efficient than doing them yourself. What you gain is that it's easier to use a ready made library.

To reduce the number of files to request you can combine them into a single file. That on the other hand means that you will use all the libraries on all pages. Even if the file is cached, the browser still has to parse all the code.