The comments thread on the hacker news article about jQuip (http://news.ycombinator.com/item?id=3256667) is an interesting and timely study of where "power users" are coming down, in the present tense, in terms of whether they'd prefer dead code removal or modules for paring down the size of jQuery in their deployments. So far, it seems to be relatively split, with a number of people assuming they can already use CC on jQuery and have it work.
This split obviously mirrors a lot of the discussion here, and as others have pointed out, we'd be unwise to not explore both, if possible. The point of our discussion should not be to decide which of these approaches is "the best" and disprove those who disagree - we must instead realise that there will probably *always* be people who prefer what is a common approach from other languages: "Let me declare the specific modules I need, and then use them in my code. If something breaks because a module isn't included, I'll probably be able to tell pretty easily." There will also be people who prefer to have the whole toolbelt at their disposal, and then have build tools get the code as small as possible, using minification, gzip, and unused code paths. If we only choose to support one, that will not quiet the hordes who still prefer the other approach.
It seems to me that if Closure Compiler addresses the bugs they seem to know exist with compiling jQuery, and we make any tweaks necessary to Core to support it as well, the net result will be status quo-or-better for developers. The concern that somehow if every third-party plugin a user doesn't make changes to support CC, then the user won't see the benefit of dead code removal, strikes me as irrelevant. All we're saying by supporting CC is that "it is possible to have dead code be removed from jQuery by CC," not "the size of your application code with 15 third-party plugins of varying quality is magically going to shrink." The idea here is to let users who are already trying to be extremely conscientious about getting the best compression possible actually do so, not shave 10kb off of sites that are gonna be serving you a meg of JS no matter what. And so if that process necessitates making changes that in turn could be beneficial to people who prefer the modular approach, we shouldn't hide that away.
Just my (a couple more than 2) cents!
This all makes sense to me. I'd be okay with seriously exploring both paths.
This is definitely better than Zepto's half-hearted effort
Ugh. You just had to mention Zepto :p
The jQuery core/bugs team has been doing a lot of thinking about how to reduce the size of jQuery without severe disruption, and the constraint/cost tradeoffs are actually quite different from this initial jquip effort.
Exactly. I don't think anyone could really consider it a serious contributor to the on-going discussions, but it's a useful reference-point if nothing else.
I'd personally be more interested in seeing where the other two paths (AMD via Alex's fork and of course GC) take us.
Interesting implementation - they appear to 'pluginize' all of the various components to core. Not sure this is the best approach nor how well it might fair against AMD, but I think as they mention, tests are in order to gauge just how well theirs might work :)
On Sun, Nov 20, 2011 at 5:14 PM, Mathias Bynens <mat...@qiwi.be> wrote: