Don't most apps reference jQuery from a CDN source (like Google)? In those cases jQuery is probably served from the browser cache. And if "those cases" are "most cases", is having a smaller version of a similar library particularly valuable?
See: https://code.google.com/speed/page-speed/docs/mobile.html#De...
BTW, their Page Speed thing is now available online: https://developers.google.com/pagespeed/
For example: I discovered that my tiny localStorage library was taking 300ms to load, and that was because I was doing feature detection at parse-time and that feature detection attempted to actually set an item in localStorage. I postponed that, and got the load time down to 20ms.
1) You can't always count on users having cached it from the CDN.
2) If it's included on my own server I can be sure they're getting exactly what I intend and there will be less HTTP requests when I include it with the rest of my JS which will only add ~4kb.
3) I'm a bit of a minimalist when it comes to code - for the web at least.
No, but you can always count the MAJORITY of users will have it cached from the CDN.
http://httparchive.org/trends.php#perGlibs
...and that's across all versions of all libraries.
Quite how that correlates with how many of your first-time visitors will already have the library cached – because they happen to have recently visited another site that uses the same version of the same library – depends on how much your visitor demographic intersects with those sites that use the CDN. You then need to offset that against the DNS lookup time requires for the rest of your visitors to work out whether loading the file from Google's CDN makes sense.
If you're talking about repeat visitors, it doesn't matter where the file was served from, so long as you apply the correct cache-controlling headers.
Besides, even when they don't have it, Google's CDN is better than a hit on your servers, both for your IO load, parallelism, delivery speed, etc.
Components don't seem to stay in cache for very long these days because browser caches are max only 50MB (phones are much smaller) and with a bit of surfing it's easy to get to a position where components get ejected.
Also there is no guarantee that retrieving it from Google's CDN is faster than retrieving it from your servers e.g. there's DNS resolution, TCP connections to be setup etc., some of which will already be done for the main site.
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min...
...and it was used by just 2.7% (945) of the 35,204 pages in the dataset. Note that it's not just version fragmentation - you have to take protocol into account too as browsers cache HTTP and HTTPS separately.
The next most popular was:
http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min...
...used by 1.3% (460) of pages, followed by:
http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min...
...used by 0.8% (285) of pages.
At this point there really isn't much of a debate; unless you have evidence to the contrary (e.g. all our visitors come from Facebook, and Facebook use the same version of jQuery as we do) using Google's CDN to load jQuery isn't likely to benefit the majority of your first-time visitors.
http://statichtml.com/2011/google-ajax-libraries-caching.htm...
Of course I'm assuming you're using common best practices with cache-control/expires headers.
That way you could use Google's jQuery file without being vulnerable to them messing with the file contents.
That is the point I was trying to make.
[1] http://www.imperialviolet.org/2011/05/04/pinning.html
[2] http://src.chromium.org/viewvc/chrome/trunk/src/net/base/tra...