Google Groups

Re: [jquery-bugs-team] File Size Considerations

Yehuda Katz Nov 17, 2011 9:22 AM
Posted in group: jQuery Bugs Team
For what it's worth, if we can get closure compiler to work reliably, without requiring end developers and plugin authors to drastically change *their* style of writing code, I think this would be a big win. That said, aren't the same problems we're encountering making jQuery itself compatible going to rear their heads over and over again with plugins and end-developer code? The documentation for making your JS code "closure compiler advanced mode ready" is pretty meager…
Yehuda Katz
(ph) 718.877.1325

On Thu, Nov 17, 2011 at 6:47 AM, John Resig <> wrote:
I'm still waiting to hear back from my email yesterday - I can
certainly do that.


On Thu, Nov 17, 2011 at 9:41 AM, Jörn Zaefferer
<> wrote:
> As this list is public anyway, let's ask Chad to join this discussion?
> On Thu, Nov 17, 2011 at 15:38, John Resig <> wrote:
>> > A few things immediately come to mind...
>> > Closure Compiler (CC) was originally built for use with Google's Closure
>> > lib, which doesn't have the sort of adoption that jQuery does - think of
>> > it
>> > as naive in that sense. (Yes, I know the lib is used in gmail and a slew
>> > of
>> > other Google app products, but that means nothing compared to the number
>> > of
>> > developers writing web applications with jQuery... I'm going to guess
>> > that
>> > since Google doesn't support IE6 or 7, Closure lib doesn't either)
>> Yep, that's true - they also make a number of assumptions about
>> browser support (they don't do feature detection, as far as I know).
>> Although none of that really affects the compiler.
>> > And plugins? What happens when CC removes the path,
>> > because
>> > it's not used in my program, but I have plugins that use it?
>> Well, that won't happen - because inherently you have to bundle all of
>> your scripts together - including pugins. You can't just make a
>> "smaller jQuery" - you have to do jQuery + plugins + site code ->
>> compressed code. That is the development model that CC supports.
>> > How many site developers actually compile and compress their own jQuery?
>> At this point? Probably around 0% - but I bet that's mostly because
>> jQuery breaks if you try to use the advanced compilation mode in CC
>> (and that it isn't advertised very well - every time I explain what it
>> is to an audience I blow their minds).
>> > How does CC know what feature detected logic paths to remove?
>> It doesn't. It might make sense to rewrite some of our feature
>> detection logic to be in the module of:
>> var blahCheck = function() {
>>    // do feature test
>> };
>> // later
>> jQuery.fn.fooMethod = function() {
>>    var checkResults = blahCheck();
>>    jQuery.fn.fooMethod = function() {
>>        // real definition of method
>>    };
>>    return jQuery.fn.fooMethod.apply( this, arguments );
>> };
>> (I bet we could come up with a helper method that simplifies this
>> process drastically.) Although this particular style of writing the
>> code will remove the feature test if the associated method is un-used.
>> > Does anyone really want to re-introduce the .jar file to the repo?
>> That's pretty much the least important reason to not do this. It's not
>> clear to me if we'd really even need the .jar file in the repo - but
>> we would want to have it on the web site as a web service.
>> --John