Google Groups

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

John Resig Nov 17, 2011 10:28 AM
Posted in group: jQuery Bugs Team
On Thu, Nov 17, 2011 at 1:01 PM, 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

To be clear: This isn't something that we have to do, in fact the
closure team has already mentioned that this is something that they
can work around on their end. We just may need to provide inline
comment hints, or something of that nature.

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

Look, here are the facts: Ever since the very first release of jQuery
the file size has gone up with every single release. I don't think
we've ever had a release that significantly reduced the file size, no
matter how hard we've tried. We can't blame adding new features as we
haven't really added significant new features to the code base in a
long time - this is all from bug fixes.

Stripping off 1.3KB of code from a 30+KB library is not the solution
that users are clamoring for. Nor is stripping down the code base or
removing features. Closure Compiler gives us a very real solution to
the increasing file size of jQuery by allowing users to have a choice
in what they can use - and in a way that will fully work with their
applications and in a way that matches best practices. We literally
cannot hope for a better solution.

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

This isn't magic, it's really quite literal. We're providing a very
real solution to the bloat in the jQuery code base by allowing users
to only use the features that they need. They will have a code base
that will literally be un-optimizable beyond that point, they can't
hope to have a better solution than that.

> 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?

Oh come on, this is quite specious, at best. We've *never* worried
about issues like this. Let's assume the absolute worst case: Google
gives up on closure entirely and we need a bug fix. In that case we
pay a Java developer to fix the bug for us.

> 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?

It is completely worth it, 100%.