

Jquery.com uses only 34% of jQuery - bolinfest
http://blog.bolinfest.com/2011/04/jquerycom-uses-only-34-of-jquery.html

======
weego
I really feel the headline should be "Non-issue used for article to drive
advert for my FireFox addon". There was really nothing of interest there; the
whole point of the kind of toolkit (jQuery) is to have good coverage across as
many common tasks as possible, but if you need very specific functionality you
end up with something of a scatter-gun. Not being able to compile you own
intensely specific version is a trade off between ease of setup over results,
personally I would say it is the correct choice (for standard web use, I
wholeheartedly disagree with they way that jquery mobile is heading).

------
Jd
The benefit of using the whole jQuery library on a single page is that it will
likely already be cached, particularly if you are using the Google version.

The largest time expenditure is on the loading from an external server, not
the processing once it is local. Don't think the author understands this.

~~~
nsfmc
actually, i think the author _does_ understand this and in the case of
stackoverflow, i think he's obliquely making the case that many of the effects
could otherwise be achieved with css without creating the performance and
memory hits you might get from using $().

in most cases, js performance is a non issue, but when it is, it's interesting
to see how and where you can optimize, which is really what his add-on (again,
obliquely the real point of the post) seems to target.

~~~
Jd
Some what ridiculous that we must figure out what the point of his post is
instead of him just telling us.

------
edanm
From the Article:

"From these preliminary results, I believe that most sites that use jQuery
could considerably reduce the amount of JavaScript that they serve by using
Closure. As always, compiling custom JavaScript for every page must be weighed
against caching benefits, though I suspect that the Compiler could find a
healthy subset of jQuery that is universal to all pages on a particular site."

This is the interesting point - is there a subset of jQuery that includes
enough for most sites? That subset could potentially be served alongside the
main jQuery release, and if enough sites use it, it might be worth it.

Otherwise, right now, caching means jQuery bloat isn't too big a problem, I
believe.

~~~
evilduck
Sizzle.js maybe? I've tossed CDN jQuery into a couple projects to get Sizzle
and jQuery's AJAX wrappers, but usually ignoring the visual effects
capabilities of jQuery entirely.

Honestly though, I've never done anything at large enough scale that serving
something like 14kb instead of 29kb mattered to me or my users.

------
tosh
I think picking jQuery as an example wasn't the best choice since it probably
is already cached for sites that use google's or other popular CDNs. This is
true for StackOverflow (one of the examples in the article).

The main point of the article still stands though. Closure and similar tools
make a lot of sense because they can reduce the size of js quite a bit.
Especially for huge apps that require several libraries but only use parts of
them it can make a huge difference.

