Google Groups

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

Dan Heberden Nov 17, 2011 11:22 AM
Posted in group: jQuery Bugs Team
can have pieces of it ( pieces of ajax, etc) *removed

On Thu, Nov 17, 2011 at 11:21 AM, Dan Heberden <> wrote:
It sounds like there are two parallel thoughts going. 

1) Remove stuff, possibly modularize components and make a smaller, leaner jQuery that possibly can have pieces of it ( pieces of ajax, etc )
2) Work with the CC team to make jQuery compatible to a full measure to get every possible reduction gain per project

These both seem worth looking at, ya? Instead of requiring CC, offering support for those that wish to take advantage of that tool. 

While I don't agree that CC will be going anywhere, I don't see every user power-user wanting to depend on it. 

On Thu, Nov 17, 2011 at 11:01 AM, Julian Aubourg <> wrote:
2011/11/17 John Resig <>
> 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).

Isn't that just an edge that we can approach when we get to it? The
important thing is if you don't use Ajax at all, or no animations, or
no queue-ing code, etc. etc. then we have large swathes of reclaimed
file size for the user. BUT the major difference between Closure
Compiler and a "builder" (like what jQuery UI has) is that all of
these decisions are made automatically, when you want to deploy to
production, based upon your existing code base.

It's not an edge case, it's the difference between a truly modular approach and a magic box. You will require a building process anyway: why on earth you would remove control from your power-users is beyond me.

Just make a survey online and see what people want:
1) Closure based optimization
2) Modular jQuery

I think I can guess the answer.

> 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).

I'm not sure what you're referring to here - but the short of it is
that the majority of users don't care what file size jQuery is, if
it's minified, if it's gzipped, or whatever and will just include it
into their site regardless. The people that DO care about file size
(gzip, etc.) would love to have additional options. It would make
jQuery far more appealing as a library and would give us the ability
to grow. We're paranoid about file size, to the point where we're
thinking about removing features that people are actually using. This
does not make sense and we have to provide an alternative.


I was just answering to the quite "paternal" take Jörn seemed to have of our non-power users ;)