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).
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.
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.
"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.
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.
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.
[+] [-] weego|15 years ago|reply
[+] [-] Jd|15 years ago|reply
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|15 years ago|reply
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.
[+] [-] edanm|15 years ago|reply
"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|15 years ago|reply
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|15 years ago|reply
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.