Google Groups

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

Julian Aubourg Nov 17, 2011 10:33 AM
Posted in group: jQuery Bugs Team
I seriously doubt you'll be able to manually remove the JSONP transport using Closure given how the use of a transport depends on the dataType option (even part of it) and I don't think Closure will ever get smart enough to understand this (and I'm not certain it should in that instance).

That's the grief I have against this approach. Real power-users will prefer fine-grained control (understand modules). Interestingly, ajax is already modularized internally.

And I find it a bit harsh to draw the line between power-user that will want a shorter jQuery and non-power-users that would be some kind of morons that just dump jQuery as is (whereas the general consensus is to link to the minified version on the Google CDN with a local fallback at the end of the body -- something you'll find pretty much everywhere on the web today).

2011/11/17 Jörn Zaefferer <>
Afaik Dart actually uses Closure Compiler to minify the JS output. Currently its much more likely that Dart is going away then Closure Compiler going away.

As for any changes to jQuery to adapt to Closure Compiler: Currently it looks like none of those are really necessary, as long as the compiler can get more clever, that is, add more passes to understand how jQuery works.

As for "some power users": Without options to trim down jQuery, alternatives like zepto and ender will become much more important for those power users. The various frontend projects I'm currently involved in at SoundCloud still use jQuery, but for what we need it actually carries way too much overhead. We already use Closure Compiler to minify our JS output, but without advanced mode.

The idea here really is that I could put my app through CC in advanced mode, it notices that I don't use JSONP nor any effects, and kicks those out, saving me a good amount of KBs, without any manual optimization like ender would require. Thats a lot more significant then shaving off a single kilobyte by removing a few methods here and there.

All the non-power users that just include jQuery unminified don't care about any of this one way or the other. 

On Thu, Nov 17, 2011 at 19:01, Julian Aubourg <> wrote:
Let me get the reasoning straight:
1) some power-users want to be able to strip jQuery down to the core (so to speak),
2) we decide to support and promote the use of Closure to that end,
3) we make changes in the code that actually will make jQuery bigger (and not just slightly bigger given how often we use $.each to factor method definitions) for every users save for power-users

All of this in the hope said power-users will embrace Closure? I'd call that a gigantic leap of faith if not an outright insult to the majority of our users who'll see jQuery's size go up.

I just don't buy "all magic" solutions.

I'd rather concentrate on smart deprecation and separation of some components from core (effects and ajax come to mind) before rushing and adapting jQuery for Closure. I still think the tool itself is not mature enough if it cannot pre-execute "static" $.each statements (though I suppose this is all due to Closure being warry of modification of built-in prototypes). I mean, this is typically the kind of things a real compiler (understand, C, C++, Java compiler) is able to do when using optimization (especially inlining) options.

I also have a lot of concerns regarding Google and their general effort towards JavaScript tools. What if Google shuts Closure down if and when they switch to Dart for their in-house products? Who would maintain it? the jQuery team?

I really think we have safer and less involved ways to reduce jQuery's size before we lock ourselves in a vendor-dependant solution.

If it only involved rewriting two or three functions, I wouldn't mind, but we're talking about unrolling all factored function defs + transforming the way we deal with support properties. Is it worth it? Aren't we being a bit brutal here?

My 2 cents though,

-- Julian

2011/11/17 Yehuda Katz <>
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