File Size Considerations

Showing 1-99 of 99 messages
File Size Considerations John Resig 11/16/11 3:48 PM
Hi All -

Sorry I've been rather swamped the past couple weeks! I had some
thoughts regarding the recent file size/deprecation discussions. I
feel that our way of tackling the issue should be done in multiple
steps:

1) First and foremost, get jQuery working in Google Closure Advanced
Optimization mode. If we can get it so that a user can get a
super-stripped-down version of jQuery by adding in their site code and
jQuery itself this would be a major win - and one that would likely
solve most of the size concerns that we hear now.

2) Deprecate and move bits of code that no one is using to plugins. A
bunch of these are in the spreadsheet (getData/setData,
.data("events"), etc.).

3) Start decoupling bits of internal logic to allow Closure to work
even better. For example, make sure that we're using as little of the
other methods in jQuery, inside core, to avoid pulling in external
modules. Right now I suspect that even a basic statement like
$(function(){ }); will pull in core, events, data, and a bunch of
other modules.

4) Figure out a way to ship a version of jQuery that only deals with
IE 8 and up. Namely: Figure out how to effectively strip out the
non-qsa bits of Sizzle and any bug fixes that may be not relevant.

After all of this is done then we can start looking at removing things
that are inherently not ideal but are still being used. I worry that
we may be trying to drop not-ideal features just to get more filesize
- which shouldn't be our top concern, we still have a ton of work to
do to try and get filesize down in other ways.

If the response from the community has been anything it's been: Give
us a way to customize our jQuery build (closure compiler does this)
and give us a way to drop old browsers (slightly mis-guided, people
think we have more bug fixes than we actually do - I think closure
compiler will help a lot of this but we can still explore it anyway).

--John

Re: [jquery-bugs-team] File Size Considerations Dave Methvin 11/16/11 4:31 PM
Hey John, great to hear from  you!

I like the idea of using Closure, and making sure we minimize
dependencies will definitely be important to having it work
effectively. Still, having perhaps one "light" version would be nice
as well since it could be distributed on CDNs. Many people won't want
to go through the hassle of using Closure on their code.

> Right now I suspect that even a basic statement like
> $(function(){ }); will pull in core, events, data, and a bunch of
> other modules.

Yep, and ready isn't something I think we'd want to make optional. If
we're willing to give up the .bind("ready") event (I put it on the
list) it seems like ready could be done by a simple callback list and
no events at all.

It would seem pretty simple to decouple effects and ajax at minimum.
People making use of CSS transitions may be able to get away without
effects, for example, and someone who just uses JSONP may not need our
full-blown ajax. Throw the non-qSA Sizzle code out and we're looking
at something a lot smaller.

We should think about keeping this simple to use as well as being
small. If users have to make a lot of decisions about which version to
download or if we just point them to the advanced optimization docs
for Closure, they are just going to use the all-in-one file anyway.
Right now they know that everything at api.jquery.com is in the same
file, if we split it up we'll need to think about how that split will
be documented.

> After all of this is done then we can start looking at removing things
> that are inherently not ideal but are still being used.

The key is to give people enough notice and a reasonable migration
path. Although we've talked about removing things as soon as version
1.8, it may be that we can't make any big moves until 2.0. But the
sooner we let people know where we are headed, the sooner they can
change what they're doing -- or let us know we're being unreasonable,
and we can change our plans.

Finally, we need to figure out how this will affect UI and Mobile and
how we can do a smooth transition.

Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/16/11 4:57 PM


On Wed, Nov 16, 2011 at 6:48 PM, John Resig <jer...@gmail.com> wrote:
Hi All -

Sorry I've been rather swamped the past couple weeks! I had some
thoughts regarding the recent file size/deprecation discussions. I
feel that our way of tackling the issue should be done in multiple
steps:

1) First and foremost, get jQuery working in Google Closure Advanced
Optimization mode. If we can get it so that a user can get a
super-stripped-down version of jQuery by adding in their site code and
jQuery itself this would be a major win - and one that would likely
solve most of the size concerns that we hear now.
 
I agree, but we still have the problem of defining functions with .each(), which we do a lot.


2) Deprecate and move bits of code that no one is using to plugins. A
bunch of these are in the spreadsheet (getData/setData,
.data("events"), etc.).

3) Start decoupling bits of internal logic to allow Closure to work
even better. For example, make sure that we're using as little of the
other methods in jQuery, inside core, to avoid pulling in external
modules. Right now I suspect that even a basic statement like
$(function(){ }); will pull in core, events, data, and a bunch of
other modules.

4) Figure out a way to ship a version of jQuery that only deals with
IE 8 and up. Namely: Figure out how to effectively strip out the
non-qsa bits of Sizzle and any bug fixes that may be not relevant.
 
This one concerns me for a few reasons.

- A major advantage to jQuery is the simplicity of a single file.  jQuery's usage is still growing and I think a single file has helped that along.
- Maintaining two jQuerys at once could be a pain.
- IE6-7 will still be around for a while longer and even if they were not supported, we would still need all of the non-qsa in Sizzle, if only to maintain the current implementation for filtering.
 
 
After all of this is done then we can start looking at removing things
that are inherently not ideal but are still being used. I worry that
we may be trying to drop not-ideal features just to get more filesize
- which shouldn't be our top concern, we still have a ton of work to
do to try and get filesize down in other ways.

If the response from the community has been anything it's been: Give
us a way to customize our jQuery build (closure compiler does this)
and give us a way to drop old browsers (slightly mis-guided, people
think we have more bug fixes than we actually do - I think closure
compiler will help a lot of this but we can still explore it anyway).

--John

Re: [jquery-bugs-team] File Size Considerations Addy Osmani 11/16/11 5:18 PM

Pardon my ignorance - it appears a lot of the work that's been started so far focuses on trimming down the (immediate) filesize, whilst point 1) would probably be a more important win in the long term. Is this work something the closure compiler team will be working on or is there a plan for how that's going to be tackled internally? 

(I ask as the last time this was discussed we were waiting on further input fron the closure compiler team)

I think a dual solution (CDN single IE8+ file and a closure compiler optimizable version) would make the most sense.

Sent from my iPhone
Re: [jquery-bugs-team] File Size Considerations John Resig 11/16/11 5:26 PM
> I agree, but we still have the problem of defining functions with .each(),
> which we do a lot.

And those are changes that I think we should make. Even if our file
size jumps by (say) 1KB gzipped, it would totally be worth it to give
people the ability to completely customize their builds.

> This one concerns me for a few reasons.
> - A major advantage to jQuery is the simplicity of a single file.  jQuery's
> usage is still growing and I think a single file has helped that along.
> - Maintaining two jQuerys at once could be a pain.
> - IE6-7 will still be around for a while longer and even if they were not
> supported, we would still need all of the non-qsa in Sizzle, if only to
> maintain the current implementation for filtering.

I agree completely - and to clarify what I was talking about with
point #4. I'm not talking about a separate build for jQuery (I really
don't want a separate build of jQuery) I'm talking about finding a way
to optionally have closure compile out the un-needed IE code paths, if
that is so desired.

--John

Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/16/11 5:26 PM


On Wed, Nov 16, 2011 at 8:18 PM, Addy Osmani <addyo...@gmail.com> wrote:

Pardon my ignorance - it appears a lot of the work that's been started so far focuses on trimming down the (immediate) filesize, whilst point 1) would probably be a more important win in the long term.
I think this is John's argument as well.
 
Is this work something the closure compiler team will be working on or is there a plan for how that's going to be tackled internally? 

(I ask as the last time this was discussed we were waiting on further input fron the closure compiler team)
+1
 

I think a dual solution (CDN single IE8+ file and a closure compiler optimizable version) would make the most sense.
Just to be clear on my own position, I am currently against an IE8+ jQuery. I'd be glad to hear a rebuttal.

Re: [jquery-bugs-team] File Size Considerations John Resig 11/16/11 5:28 PM
> Pardon my ignorance - it appears a lot of the work that's been started so
> far focuses on trimming down the (immediate) filesize, whilst point 1) would
> probably be a more important win in the long term. Is this work something
> the closure compiler team will be working on or is there a plan for how
> that's going to be tackled internally?
> (I ask as the last time this was discussed we were waiting on further input
> fron the closure compiler team)

Yep, we're talking with them right now - although there are still a
number of changes that we need to make on our end - and I feel that
they should be a top priority. Almost all file size concerns become
moot when you have this tool. If you're worried about file size, or
specific modules, or specific methods - just run it through the
compiler and it'll strip out everything that isn't being used. This is
absolutely huge and would be a big win for everyone using jQuery.

--John

Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/16/11 5:28 PM


On Wed, Nov 16, 2011 at 8:26 PM, John Resig <jer...@gmail.com> wrote:
> I agree, but we still have the problem of defining functions with .each(),
> which we do a lot.

And those are changes that I think we should make. Even if our file
size jumps by (say) 1KB gzipped, it would totally be worth it to give
people the ability to completely customize their builds.
I can see how this would be worth it.
 
 
> This one concerns me for a few reasons.
> - A major advantage to jQuery is the simplicity of a single file.  jQuery's
> usage is still growing and I think a single file has helped that along.
> - Maintaining two jQuerys at once could be a pain.
> - IE6-7 will still be around for a while longer and even if they were not
> supported, we would still need all of the non-qsa in Sizzle, if only to
> maintain the current implementation for filtering.

I agree completely - and to clarify what I was talking about with
point #4. I'm not talking about a separate build for jQuery (I really
don't want a separate build of jQuery) I'm talking about finding a way
to optionally have closure compile out the un-needed IE code paths, if
that is so desired.
Ah I see.  Thank you for clarifying.
 

--John

Re: [jquery-bugs-team] File Size Considerations John Resig 11/16/11 5:31 PM
> I like the idea of using Closure, and making sure we minimize
> dependencies will definitely be important to having it work
> effectively. Still, having perhaps one "light" version would be nice
> as well since it could be distributed on CDNs. Many people won't want
> to go through the hassle of using Closure on their code.

I disagree that we should have a "light" version of jQuery. If we do
the compiler implementation right then he whole "small/light version
of jQuery" debate becomes moot. The ultimate problem with a "light"
version of jQuery is that in the end it'll still have features that a
person doesn't want OR features missing that they do want. Why even
bother building this code base when it won't fit the strict
requirements of a power user.

In the end the people clamoring for smaller file size are real power
users - we can meet their needs by supporting closure properly (even
if it'll take some help from the closure team).

--John

Re: [jquery-bugs-team] File Size Considerations Addy Osmani 11/16/11 5:39 PM

I disagree that we should have a "light" version of jQuery. If we do
the compiler implementation right then he whole "small/light version
of jQuery" debate becomes moot. 

I completely agree with this. It makes more sense to have a single
(full) version that's available for all, much like the way we have
now, with the right tools to bring the filesize down further for those that
absolutely need or want it. 


--

Addy Osmani

Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams member
Blogger at: http://addyosmani.com

Re: [jquery-bugs-team] File Size Considerations Rick Waldron 11/16/11 5:41 PM
On Nov 16, 2011, at 8:26 PM, Timmy Willison <timmyw...@gmail.com> wrote:



On Wed, Nov 16, 2011 at 8:18 PM, Addy Osmani <addyo...@gmail.com> wrote:

Pardon my ignorance - it appears a lot of the work that's been started so far focuses on trimming down the (immediate) filesize, whilst point 1) would probably be a more important win in the long term.
I think this is John's argument as well.
 
Is this work something the closure compiler team will be working on or is there a plan for how that's going to be tackled internally? 

(I ask as the last time this was discussed we were waiting on further input fron the closure compiler team)
+1
 

I think a dual solution (CDN single IE8+ file and a closure compiler optimizable version) would make the most sense.
Just to be clear on my own position, I am currently against an IE8+ jQuery. I'd be glad to hear a rebuttal.


How about a +1? A fragmented jQuery ecosystem will be a bugs nightmare.
Re: [jquery-bugs-team] File Size Considerations John Resig 11/16/11 5:45 PM
> How about a +1? A fragmented jQuery ecosystem will be a bugs nightmare.

I agree. I feel that the step to saving bytes (stripping out un-needed
code) should be a conscious one made by those that are aware of the
consequences. We could even build a simple web API (or just point
people toward Google's REST API) to help people get up to speed.

--John

Re: [jquery-bugs-team] File Size Considerations Dave Methvin 11/16/11 5:51 PM
> In the end the people clamoring for smaller file size are real power
> users - we can meet their needs by supporting closure properly (even
> if it'll take some help from the closure team).

My concern about just pointing people in the direction of Closure is
that very few people will be able to use it; even if we can get jQuery
to work with Closure, they may face a challenge with their other code
and plugins. So first we need to get our own house in order, see where
that gets us, then communicate to our developers and plugin community
what we think the best practices should be.
To Addy's point, many of the features in the spreadsheet affect not
only the size of their own existence, but the ability to decouple and
refactor. For example, .bind("ready") means you need events for ready,
":radio" selector means you need Sizzle extensions and not just qSA,
data events create a coupling to events, etc. So taking them out will
allow Closure to work better.

Re: [jquery-bugs-team] File Size Considerations John Resig 11/16/11 5:56 PM
> My concern about just pointing people in the direction of Closure is
> that very few people will be able to use it; even if we can get jQuery
> to work with Closure, they may face a challenge with their other code
> and plugins. So first we need to get our own house in order, see where
> that gets us, then communicate to our developers and plugin community
> what we think the best practices should be.

When I talk about closure I'm not really talking about putting up a
message that's like "oh hey, go to this closure site and try to figure
out how to use it - good luck!" more that we should provide the
service directly on our site, have very clear documentation as to how
it works (and known limitations), and really help people to build
smaller apps.

Agreed - plugins will be an interesting mix, but at least in those
cases it's likely that the code won't be stripped out, it'll just have
extra file size. If we run our own service we could even do stuff like
check to see if you're using a known bad plugin and suggest something
else - stuff like that.

> To Addy's point, many of the features in the spreadsheet affect not
> only the size of their own existence, but the ability to decouple and
> refactor. For example, .bind("ready") means you need events for ready,
> ":radio" selector means you need Sizzle extensions and not just qSA,
> data events create a coupling to events, etc. So taking them out will
> allow Closure to work better.

Absolutely - although those are just extra layers of improvements. In
the meantime we really need to fix our communication with the user
base - and the best way to do that isn't to knock off 500b - 1KB of
file size (even though that'd be nice) it's to make it so that people
can, at least, strip out some of the major modules automatically, if
they're not using them.

--John

Re: [jquery-bugs-team] File Size Considerations Rick Waldron 11/16/11 5:57 PM
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)

And plugins? What happens when CC removes the jQuery.fn.foo path, because it's not used in my program, but I have plugins that use it?

How many site developers actually compile and compress their own jQuery? 

How does CC know what feature detected logic paths to remove?

Does anyone really want to re-introduce the .jar file to the repo?

Just questions to consider, I'm sure there are good answers to all of them.

Rick 
Re: [jquery-bugs-team] File Size Considerations Rick Waldron 11/16/11 5:59 PM
Sorry, did not intentionally echo the plugins discussion - I was typing that when those came in.
Re: [jquery-bugs-team] File Size Considerations John Resig 11/17/11 6:38 AM
> 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 jQuery.fn.foo 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

Re: [jquery-bugs-team] File Size Considerations Jörn Zaefferer 11/17/11 6:41 AM
As this list is public anyway, let's ask Chad to join this discussion?
Re: [jquery-bugs-team] File Size Considerations John Resig 11/17/11 6:47 AM
I'm still waiting to hear back from my email yesterday - I can
certainly do that.

--John

Re: [jquery-bugs-team] File Size Considerations Yehuda Katz 11/17/11 9:22 AM
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
Re: [jquery-bugs-team] File Size Considerations Julian Aubourg 11/17/11 10:01 AM
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 <wyc...@gmail.com>

Re: [jquery-bugs-team] File Size Considerations Jörn Zaefferer 11/17/11 10:14 AM
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. 
Re: [jquery-bugs-team] File Size Considerations Dave Methvin 11/17/11 10:24 AM
> 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…

There is someone who wrote up what they did for Dojo, it's pretty brutal:

http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf

What we need to do to get Closure to recognize and remove dead code
seem like the intensely anal-retentive form of the same things we need
to do if we are going to manually split up modules. That includes
refactoring internals, plus deprecating and removing (or at least
warning against the use of) APIs that pull in lots of stuff when they
don't really need to.

For example, the $.fn.load() API calls one of two subsystems, event or
ajax, depending on its args. Closure isn't going to know which you
mean, both are referenced. The simplest thing would be to deprecate
and eventually remove at least one of those meanings. In the
spreadsheet I had assumed it would be the event one.

Pulling in all of ajax is something that I think a lot of people may
want to avoid. If I have an app that only uses simple jsonp requests,
it would be nice to use a small basic jsonp plugin instead. Since we
have a single monolithic api with dozens of options, I don't see a way
for Closure to help us there without refactoring the internals
somehow, which is why I suggested some way to essentially expose the
transports so that someone using just jsonp wouldn't pay for the code
it takes to deal with http headers and data types in cross-domain ajax
etc.

I think we're going to have users looking at us funny if the changes
required to make a Closure-friendly jQuery end up increasing file size
significantly and the only way to shrink it down is to run both their
code and jQuery itself through a Closure processor at our site.
Especially if the process doesn't go smoothly because their own code
or third-party plugins don't understand Closure's rules. We have
enough trouble getting people to upgrade when all they need to do is
change the version number on their <script> tags

Still, it seems like many of the immediate steps are the same
regardless of whether Closure can ultimately help us out or not. We
need to identify the intended or unintended dependencies between the
parts of jQuery and figure out ways to minimize them.

Re: [jquery-bugs-team] File Size Considerations John Resig 11/17/11 10:28 AM
On Thu, Nov 17, 2011 at 1:01 PM, Julian Aubourg <j...@ubourg.net> 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%.

--John

Re: [jquery-bugs-team] File Size Considerations Julian Aubourg 11/17/11 10:33 AM
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 <joern.z...@googlemail.com>

Re: [jquery-bugs-team] File Size Considerations John Resig 11/17/11 10:36 AM
> What we need to do to get Closure to recognize and remove dead code
> seem like the intensely anal-retentive form of the same things we need
> to do if we are going to manually split up modules. That includes
> refactoring internals, plus deprecating and removing (or at least
> warning against the use of) APIs that pull in lots of stuff when they
> don't really need to.
>
> For example, the $.fn.load() API calls one of two subsystems, event or
> ajax, depending on its args. Closure isn't going to know which you
> mean, both are referenced. The simplest thing would be to deprecate
> and eventually remove at least one of those meanings. In the
> spreadsheet I had assumed it would be the event one.

Does it really matter in this case though? Maybe if you use .load()
then you just end up loading 2 modules - so what? We could make people
aware of that issue and steer them away from it.

Ultimately though that method is the extreme edge case. You're right
that what we would need to do is being very clear about exactly what
functionality we need and what methods depend upon other ones. The one
major advantage that we have here with CC is that it'll reward code
that's highly broken down into individual methods rather than
monolithic, inter-connected, code bases - which is something that
we've been pushing for, for a while, as well.

> Pulling in all of ajax is something that I think a lot of people may
> want to avoid. If I have an app that only uses simple jsonp requests,
> it would be nice to use a small basic jsonp plugin instead. Since we
> have a single monolithic api with dozens of options, I don't see a way
> for Closure to help us there without refactoring the internals
> somehow, which is why I suggested some way to essentially expose the
> transports so that someone using just jsonp wouldn't pay for the code
> it takes to deal with http headers and data types in cross-domain ajax
> etc.

Absolutely - and these are cases that we can optimize for anyway. We
don't have to have 100% amazing compilation out of the gate. It's
incredibly important that we show that this is something that we think
is important, that we're working on, and that we want to try and
provide the best experience possible to our users.

> I think we're going to have users looking at us funny if the changes
> required to make a Closure-friendly jQuery end up increasing file size
> significantly and the only way to shrink it down is to run both their
> code and jQuery itself through a Closure processor at our site.
> Especially if the process doesn't go smoothly because their own code
> or third-party plugins don't understand Closure's rules. We have
> enough trouble getting people to upgrade when all they need to do is
> change the version number on their <script> tags

Nothing that I've seen so far increases the file size significantly,
most of what they're requesting are more comments on method
signatures. Most of the other changes are ones that they can make on
their end.

> Still, it seems like many of the immediate steps are the same
> regardless of whether Closure can ultimately help us out or not. We
> need to identify the intended or unintended dependencies between the
> parts of jQuery and figure out ways to minimize them.

Yep, absolutely.

--John

Re: [jquery-bugs-team] File Size Considerations John Resig 11/17/11 10:41 AM
> 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.


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

--John

Re: [jquery-bugs-team] File Size Considerations Rick Waldron 11/17/11 10:53 AM
Just a quick note... I tried advanced compression for a "program" that included all of jQuery and this:

$(function() {
console.log( "All I need is core and events" );
});

Presently, the difference is about 1k. 

Closure Compiler seems to automatically create these 3 globals:

var k=true,n=null,p=false;

Re: [jquery-bugs-team] File Size Considerations John Resig 11/17/11 10:56 AM
Yeah, I think the code to strip out .extend()ed code and .each()ed
code hasn't landed yet --- which means that pretty much nothing is
removed at this point :)

--John

Re: [jquery-bugs-team] File Size Considerations Julian Aubourg 11/17/11 10:56 AM
2011/11/17 John Resig <jer...@gmail.com>
On Thu, Nov 17, 2011 at 1:01 PM, Julian Aubourg <j...@ubourg.net> 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.


Then I suggest we wait for Closure to actually demonstrate this ability before considering it.
 
> 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.


Well, thank you... no significant new features, really? Glad to learn I just fixed bugs. Man, you know how to talk to your contributors :P
 
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 completely disagree. This is an engineer argument with some blind hope that an automated tool will do a better job than a group of humans. History is clearly not on your side here. If we had ajax pulled out core, for instance, it would amount to more than 1.3kB, wouldn't it? Or am I to understand I've been bugged about the size of ajax for nothing? What's the arm in making ajax an official plugin?
 
> 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.


No, we're not. We're directing them to a black box which, as of today, requires an insane amount of code tuning in order to use advanced otimizations (what we're aiming for here). We're basically refusing to offer a real solution but rather hope that a third-party tool will do the trick. The answer is quite simple and has been implemented by other libs: it's called modularization. Interestingly, it wouldn't require more work than what we seem to be ready to do to support Closure.
 
> 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.


We should be careful about this now, John. The general approach Google has of the web has changed dramatically in the past year. Shutting down Google Labs is a big signal imo. Closure is one of these very complex and demanding projects that need a big guy behind to be able to move forward. A Java dev on jQuery's payroll wouldn't cut it.

If Closure was maintained by another big company with a track-record of abandonning tech as they go, would you still recommand it as a future-proof solution?
 
> 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%.

--John

I think you're very optimistic about what Closure will be able to deliver.
Re: [jquery-bugs-team] File Size Considerations Rick Waldron 11/17/11 11:01 AM
Ah, I see. I thought this was something that CC was already capable of

Rick
Re: [jquery-bugs-team] File Size Considerations Julian Aubourg 11/17/11 11:01 AM
2011/11/17 John Resig <jer...@gmail.com>

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

--John

I was just answering to the quite "paternal" take Jörn seemed to have of our non-power users ;)
Re: [jquery-bugs-team] File Size Considerations Dan Heberden 11/17/11 11:21 AM
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. 
Re: [jquery-bugs-team] File Size Considerations Dan Heberden 11/17/11 11:22 AM
can have pieces of it ( pieces of ajax, etc) *removed
Re: [jquery-bugs-team] File Size Considerations Yehuda Katz 11/17/11 12:04 PM
Seems like my question was answered. The CC solution will not work easily for end-developer code with plugins, unless the end developer and all the plugins he is using have gone through the same effort to CC-optimize their code. From what I've seen, that effort is non-trivial, especially when compared with "I don't need Ajax, so I won't include Ajax".

I totally agree that customizing your build is an advanced feature, and that we shouldn't be distributing N (or even 2) builds of jQuery, but I don't think that CC is the answer here. John, where am I going wrong?

Yehuda Katz
(ph) 718.877.1325
Re: [jquery-bugs-team] File Size Considerations Alex Sexton 11/17/11 1:35 PM
It's likely not going to go over too well with at least half of you, but I thought I'd share that I actually started porting jQuery over to AMD a few weeks ago. I've had some travel the last week or so, so it will need another push, but I have core.js completely separated into dependent modules and passing all of the core unit tests, etc.


Other pieces are not going to be as easy. support.js is a bit of a mess when it comes to unnecessary dependencies and will be a bit of a challenge to overcome.

gzip is pretty friendly to the amd wrappers in my experience, but it likely wouldn't make the default any smaller. It would give a clear way for us to provide a builder for people that manages it's own dependencies based on the actual full file of code. If someone wanted to go crazy, they could even hook into our AMD system and write their app with just our pieces.

It all feels a little weird because all the different parts end up on a global, but it's nothing tragic.

I'll probably keep working on it regardless, but I figured I'd bring it up since it's in the general vicinity of discussion of options for code size reduction.

Alex
Re: [jquery-bugs-team] File Size Considerations Dave Methvin 11/17/11 2:11 PM
> It's likely not going to go over too well with at least half of you, but I
> thought I'd share that I actually started porting jQuery over to AMD a few
> weeks ago.

No problem from me, and the refactoring we're doing to eliminate some
of these dependencies should help things out in that department.

> Other pieces are not going to be as easy. support.js is a bit of a mess when
> it comes to unnecessary dependencies and will be a bit of a challenge to
> overcome.

We just started talking about making as much of that as possible
evaluated lazily, so that it wouldn't need to be done at load time.
That would help the AMD solution out as well.

Re: [jquery-bugs-team] File Size Considerations Addy Osmani 11/17/11 2:48 PM
@Alex I'm heavily using AMD on a weekly basis. Whilst I'm not sure whether or not others will see it as a viable alternative to the work being done with GC, I'd definitely be willing to lend a hand if you need some help.--

Addy Osmani

Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams member
Blogger at: http://addyosmani.com

Re: [jquery-bugs-team] File Size Considerations Mike Sherov 11/17/11 2:55 PM
I've stayed out of this discussion because I'm the new guy, and these considerations are over my head at the moment. However, I'm with Addy, I'd also be willing to pitch in a skunkworks project exploring moving to AMD.
Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/17/11 4:08 PM


To continue the module train of thought:
Yes we did, but to make it completely modular would require moving some of the support tests to their corresponding modules.  For instance, I don't think jQuery.support.opacity should run lazily.  It should run on pageload so that the hook can get properly defined before use (and I'm sure that test is used plenty in user code or plugins).  But to be completely modular, that test would have to be at the top of css.js.  And even if it DID run lazily, you see what I'm getting at.  Support tests would no longer be modular.  support.js probably wouldn't exist.  Maybe that's ok, but that would probably be a requirement.

On the side of CC, there's no question that it would provide the best possible file size optimization...ideally. But it should be easy to use and not a nightmare to maintain or implement for the Closure team.

Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 7:32 AM
I feel like I've missed some important discussion in which we're
making jQuery "modular" - a rather dramatic departure from anything
we've done so far and a rather stark change for the project as a
whole. Is there more information on this?

--John

Re: [jquery-bugs-team] File Size Considerations Alex Sexton 11/18/11 7:51 AM

I merely created that branch for myself and shared it because it was relevant. Didn't mean to impose any ill will.

Fwiw, we wouldnt have to expose its modularity programaticly if we didn't want to.

Alex

Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/18/11 8:33 AM


On Fri, Nov 18, 2011 at 10:51 AM, Alex Sexton <alexs...@gmail.com> wrote:

I merely created that branch for myself and shared it because it was relevant. Didn't mean to impose any ill will.

I've been asked about modular jQuery more than advanced compilation.  I'm glad you've done some work on this already.  You're probably one of the best people to do it. 

Fwiw, we wouldnt have to expose its modularity programaticly if we didn't want to.

Alex

On Nov 18, 2011 9:32 AM, "John Resig" <jer...@gmail.com> wrote:
I feel like I've missed some important discussion in which we're
making jQuery "modular" - a rather dramatic departure from anything
we've done so far and a rather stark change for the project as a
whole. Is there more information on this?
 
True, it is a big change, but maybe it is a change worth making?

The cons that I can think of are:

- It has the potential to increase overall filesize (we probably wouldn't want to do both this and cc).
- It would have a major effect on the overall structure of the library.
- It would be a weight on the simplicity of a single file (this may be a good enough reason not to do it).
- We would probably need to take the time to create a builder similar to UI or Modernizr.

Pros:

- Unneeded modules can be removed by the user.
- No extra compilation and no advanced mode compatibility required.
- We can be compliant with the AMD specification and promote javascript modularity as best practice.
- We could even consider including require so that define/require/exports work automatically for AMD-compatible jQuery plugins (I know, that could be a stretch).
- We can do it without requiring changes to Closure

We could ask the community and see what answers we get.

Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 8:48 AM
The major con is that we would have to break up the library into such
finite modules as to be effective. Even in the best case we'll still
have people asking for less methods/file size. If they only use
.html() (for example) then why do they need append/prepend/etc.?

Modularity is a very crude solution to what we're trying to solve: We
want to give users the ability to only have to download the code that
they need for their application, and nothing more. The reason why
people are asking for modularity, as opposed to closure compiler, is
that modularity/dependency management is in the zeitgeist of the
JavaScript community, whereas Closure Compiler is "scary" and
confusing and not well understood. We're in a major position to
actually do it right, with collaboration from Google and other
community members, to be able to ship an incredibly stripped version
of the code that matches their needs.

To clarify an earlier criticism: Plugin authors won't have to do
massive re-coding - they'll only have to make changes if their code is
particularly inter-connected and massive (as our code base tends to
be). But in the end they don't *have to* do that, that's only if they
want the utmost benefit of the compiler (which is something that
should aspire to, but not necessarily achieve on day 1).

--John

Re: [jquery-bugs-team] File Size Considerations Julian Aubourg 11/18/11 11:05 AM
The reason people ask for modularity is because it's controllable.

We can go on and on and on and on about this discussion but it all boils down to this: are you expecting our power-users to adopt Closure and change their code to adapt to it just because we say so? Obviously they won't, first and foremost because, most of the time, it is NOT THEIR code. It's not a question of fear (I had to read the 'scary' word twice: WTF?). Devs are not little children that are afraid of the wind: they are pragmatic people. And you can go against a trend for so much time before realizing there may be reasons behind the trend: modules are here to stay. Like it, hate it, it's a fact.

Reality check please.

We are so late to the party it's almost laughable: the penetration of script loaders and dependency managers (AMD-compliant on top) is far beyond anything we can hope to establish by partnering with the Google Closure project (you can even blame Paul Irish and Modernizr for this :P). See, people already have a build system and Closure is not part of it (at least not with advanced settings, the only ones with a real added value), requireJS/yepnope/labJS (take your pick) are, together with any minifier that will outperform Closure when modifying the code is not desired or not an option (that is, pretty much, ALWAYS).

See, WE (but I should say YOU because I wasn't around then), the jQuery project, taught people to rely on small, focussed third-party scripts one can pick and choose given one's needs: they are plugins and they made jQuery the success it is today. The community generalized them and now we have modules. You're not supposed to modify a plugin/module, one only needs to look at how difficult it is for dependency managers today to have people add the necessary wrapping to promote legacy code into full-fledged modules to take a good measure of the problem... and we're just talking simple wrapping here, nothing as heavy as what Closure would require. Or, to be closer to home, think about the troubles we have with popular jQuery plugins at each major release.

So what would happen if we were to rely on Closure for file size reduction without modularization? Nothing. People will still pick their plugins, modules, legacy scripts, they will concat them together and use a brute-force approach minifier. Why? Because as soon as only one of these scripts is not compliant enough with Closure, then  you can forget about advanced settings and, then, Closure offers strictly no benefit when compared to any other minifier: jQuery will still be a gigantic monolithic pain in the ass.

Just try and imagine the traction needed to have all code on the internet comply with Closure. Why you say? Because it's not just about jQuery and jQuery plugins (though just thinking about jQuery plugins makes me giddy), it's also about third-party stuff like swfObject and others that will be concatanated into the final build file and given to Closure. Please ponder this for a second. People will not separate their files into two distinct categories to make us/you/Closure happy: it's an unnecessary effort given the reward, they wouldn't need it if jQuery was modularized and they know it (they are power-users already using modules, remember?).

Given the amount of thought the whole community has given into modularization, to think people favor modular builds over Closure optimization out of fear is insanely naive or plain pretentious. They do it because it's the practical solution, not some out-of-this-world solution that will work with 2 scripts you have control over or on the highly constrained GWT-generated JavaScript.

In an ideal world, Closure (if done properly -- which it is still not as of today) would outperform any module system. I'm an engineer, and I admire the compiler and what it can do like the next engineer. Sadly, in the real world, it will amount to NIL. Let's not delude ourselves here. Let's build onto what the community has been doing while we were looking elsewhere, not against it. What are we now? The IE6-era Microsoft of JavaScript libraries? Do we feel so self-important now that the community (including CommonJS, the W3C and pretty much everyone except a few in the project) has to be wrong and we are right?

2011/11/18 John Resig <jer...@gmail.com>

Re: [jquery-bugs-team] File Size Considerations Dave Methvin 11/18/11 11:19 AM
> The major con is that we would have to break up the library into such
> finite modules as to be effective. Even in the best case we'll still
> have people asking for less methods/file size. If they only use
> .html() (for example) then why do they need append/prepend/etc.?

I don't think anyone on the team is advocating that we own the job of
breaking up jQuery into little AMD-compliant pieces. I'd just say we
shouldn't be hostile to anyone who wants to explore that path. Many of
the same things that let people achieve that will probably also help
to make Closure work better. I'm sure we can learn something from Alex
Sexton's work for example.

> The reason why
> people are asking for modularity, as opposed to closure compiler, is
> that modularity/dependency management is in the zeitgeist of the
> JavaScript community, whereas Closure Compiler is "scary" and
> confusing and not well understood.

I think this is true, but also a warning flag for me. If the people at
the forefront of web development are pushing modularity and script
loaders, it would seem that we should be convincing them first.

Remember that the majority of jQuery users still either don't know
better or don't want to go through the hassle of combining and
compressing their scripts. So if that was too much trouble for them,
CC will be a much higher bar with a much steeper learning curve. Plus,
even if they do use CC, they won't be able to use a CDN for their
custom version and that will cost them bandwidth. So lacking some sort
of really good online tool, I think we should assume that the vast
majority of users will be using the larger monolithic version.

> To clarify an earlier criticism: Plugin authors won't have to do
> massive re-coding - they'll only have to make changes if their code is
> particularly inter-connected and massive (as our code base tends to
> be). But in the end they don't *have to* do that, that's only if they
> want the utmost benefit of the compiler (which is something that
> should aspire to, but not necessarily achieve on day 1).

Won't the CC behavior of renaming externals bite them too unless they
provide an externals file? I don't mind expressing my ignorance on
this, perhaps I am in the group that only needs to be educated to see
that CC can do a lot of the work for me. If so that would be great.

Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 11:29 AM
> We can go on and on and on and on about this discussion but it all boils
> down to this: are you expecting our power-users to adopt Closure and change
> their code to adapt to it just because we say so?

Let's start with this. Closure Compiler does not require developers to
change their code. They do not have to change it to have something
that is functional. They do not have to change it in order to get some
decent compression.

All the changes that I've been discussing have been to the Closure
Compiler itself - with the addition of maybe some comments in our code
base.

There appears to be a rather fundamental understanding of what Closure
Compiler does and what we have to do - or what plugin authors have to
do.

The use case I'm describing is: [ jQuery, Plugin 1, Plugin 2, etc.,
User Code 1, User Code 2, etc. ] -> Closure Compiler Advanced
Compilation -> singlefile.js (and that file is put into the user's
site - at deploy time, for production).

This will allow developers to create the most optimized version of the
code that's physically possible. No one has to create a map of
"external references" - jQuery doesn't, nor do the plugins author.
User's don't have to make any modification to their code - all we're
doing is recommending an optimal best practice that will ship a
minimum number of bytes.

Obviously we can do a lot of education to help developers write beter
code that may be even more compressible. We can learn this as we go
about optimizing jQuery itself - but all of this is secondary and not
a requirement for the very first step.

--John

Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 11:48 AM
> Won't the CC behavior of renaming externals bite them too unless they
> provide an externals file? I don't mind expressing my ignorance on
> this, perhaps I am in the group that only needs to be educated to see
> that CC can do a lot of the work for me. If so that would be great.

As I mentioned in my other message, that is not the case. You only
need to specify externals if you're doing:

[ jQuery, jQuery Plugin 1, jQuery Plugin 2, etc. ] -> Advanced Closure
Compiler -> singlejquery.js + [ User Code 1, User Code 2, etc. ]

If you bundle *everything* together (jQuery, plugins, user code) then
you have none of the "crazy issues" or code rewriting requirements.

--John

Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/18/11 11:59 AM


On Fri, Nov 18, 2011 at 2:29 PM, John Resig <jer...@gmail.com> wrote:
> We can go on and on and on and on about this discussion but it all boils
> down to this: are you expecting our power-users to adopt Closure and change
> their code to adapt to it just because we say so?

Let's start with this. Closure Compiler does not require developers to
change their code. They do not have to change it to have something
that is functional. They do not have to change it in order to get some
decent compression.

All the changes that I've been discussing have been to the Closure
Compiler itself - with the addition of maybe some comments in our code
base.

There appears to be a rather fundamental understanding of what Closure
Compiler does and what we have to do - or what plugin authors have to
do.

The use case I'm describing is: [ jQuery, Plugin 1, Plugin 2, etc.,
User Code 1, User Code 2, etc. ] -> Closure Compiler Advanced
Compilation -> singlefile.js (and that file is put into the user's
site - at deploy time, for production).
 
Thinking about this, I should concede that the module workflow can also work with CC.  
 

This will allow developers to create the most optimized version of the
code that's physically possible. No one has to create a map of
"external references" - jQuery doesn't, nor do the plugins author.
User's don't have to make any modification to their code - all we're
doing is recommending an optimal best practice that will ship a
minimum number of bytes.

Obviously we can do a lot of education to help developers write beter
code that may be even more compressible. We can learn this as we go
about optimizing jQuery itself - but all of this is secondary and not
a requirement for the very first step.

If this is an argument about better load times, there are other issues to consider, and I don't know how this affects either argument.  Some questions:

- Will cutting out unneeded pieces of jQuery actually help page loads?  As soon as one compiles their code + jQuery, the benefit of caching from the CDN is lost (there's no way we can beat the load time when loaded from cache).
- So, how often is jQuery loaded from the CDNs?
- Is it the norm for people to enable gzip on their servers or does this go unnoticed far too often?  If they don't serve it up with gzip, their compilation is wasted effort.  Granted, this may not be an issue for power users, but it could be.
- CC only benefits load time right? Modules benefit load time to a lesser degree, but they come with other (possibly more important?) benefits for code organization and maintenance.


--John

Re: [jquery-bugs-team] File Size Considerations Rick Waldron 11/18/11 12:00 PM
I'm not sure how broad this approach is, but for Bocoup client work (production deliverables) I always use a  specific version (which is always the latest stable and testable) from google cdn and provide a fallback to a self hosted copy of the same version. This approach has been honed over years of client development, the result being a high frequency of getting jQuery for free, the occasional 32k request, then it's cached.  The rest of the application code is built together and served as one or as fragments, and I definitely don't use CC (nor do I want to) and prefer to use uglify. I'd almost say that I take jQuery's presence in my app code for granted and don't really want to have to think about anymore then I already do.

This was not meant to respond to any particular argument for either side, but instead to provide a very real look at a very real use case.

I honestly think that the few voices that want modular jQuery are a small minority compared to jQuery's larger user base. I also contend that the cries of "monolithic libs must die" are from a small minority, we just notice it because we're sensitive to such things as maintainers of a lib. I also find it odd that CC has so much interest in getting jQuery back as a user...

The last part is the conspiracy theorist talking.

Rick

Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/18/11 12:08 PM
I just realized I'm forgetting mobile.  That may answer all of my questions.  Still, it should be noted that CC may not actually provide much benefit for desktop load times.
Re: [jquery-bugs-team] File Size Considerations Dave Methvin 11/18/11 12:19 PM
I've invited the Closure Compiler guys to the group and given them
post/reply privs so we can continue the discussion here.
Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 12:23 PM
> I'm not sure how broad this approach is, but for Bocoup client work (production deliverables) I always use a  specific version (which is always the latest stable and testable) from google cdn and provide a fallback to a self hosted copy of the same version. This approach has been honed over years of client development, the result being a high frequency of getting jQuery for free, the occasional 32k request, then it's cached.  The rest of the application code is built together and served as one or as fragments, and I definitely don't use CC (nor do I want to) and prefer to use uglify. I'd almost say that I take jQuery's presence in my app code for granted and don't really want to have to think about anymore then I already do.
>
> This was not meant to respond to any particular argument for either side, but instead to provide a very real look at a very real use case.

There are two valid use cases for loading JavaScript code optimally
(especially as it relates to jQuery).

The first one is the one that I outlined above. It, demonstrably, has
the smallest filesize. It also has the least number of requests. The
amount of caching the can be expected from a Google CDN is noticeable
but not overwhelming - it is still in the best interest of developers
to ship less bytes then it is to have that possible cache hit.
Especially on mobile you want to do everything in your power to reduce
the number of requests that you make. Every request uses significant
CPU and eats up battery. It goes without saying that the problems
experienced on the desktop are only compounded on mobile.

Steve talked about this here (about 25 minutes in):
http://ontwik.com/jquery/mobile-performance-steve-souders-bay-area-jquery-conf-2011/

Some more details:
http://code.google.com/speed/page-speed/docs/rtt.html#CombineExternalJS

The second use case is one like what Rick describes. You load jQuery
from a CDN (minified and gzipped) with a local fallback. You then
minify and gzip all your local code into another file. Thus on first
page load you have two requests - one to the CDN (possibly cached) and
one to your local server. This is the next optimal way to load code.
You're kind of rolling the dice on the code possibly being cached by
Google - and you're definitely saving money by not having to serve the
file yourself. In this way you can use CC Advanced mode on [ jQuery
Plugins, User Code ] if you wish and you, again, won't have to worry
about external dependencies or anything like that. If this is how you
wish to load your code then the CC discussion is moot - you can keep
on truckin' and everything will work just fine!

> I honestly think that the few voices that want modular jQuery are a small minority compared to jQuery's larger user base. I also contend that the cries of "monolithic libs must die" are from a small minority, we just notice it because we're sensitive to such things as maintainers of a lib. I also find it odd that CC has so much interest in getting jQuery back as a user...

CC has some interest in getting us to work because, unsurprisingly,
when you have 50% of all web sites using your code they really want to
try and make it work. Honestly nothing to conspire about here.

--John

Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 12:30 PM
> If this is an argument about better load times, there are other issues to
> consider, and I don't know how this affects either argument.  Some
> questions:
> - Will cutting out unneeded pieces of jQuery actually help page loads?  As
> soon as one compiles their code + jQuery, the benefit of caching from the
> CDN is lost (there's no way we can beat the load time when loaded from
> cache).
> - So, how often is jQuery loaded from the CDNs?

I read an article that, unfortunately, I'm unable to find again that
put the cache hit rate to be rather low. Combine that with mobile in
which the file may not be cached to begin with and you have more
requests than you need (and doing more DNS lookups to boot).

> - Is it the norm for people to enable gzip on their servers or does this go
> unnoticed far too often?  If they don't serve it up with gzip, their
> compilation is wasted effort.  Granted, this may not be an issue for power
> users, but it could be.

Enabling gzip is the norm for people who care about byte-pinching
unused methods out of their code, yes.

> - CC only benefits load time right? Modules benefit load time to a lesser
> degree, but they come with other (possibly more important?) benefits for
> code organization and maintenance.

If you're not doing a compilation step then modules will have a
negative benefit. If you're doing a compilation step then you might as
well be using a really good compiler - and CC Advanced is the best
there is.

Switching jQuery to a modular system would dramatically change how one
interacts with jQuery. You would no longer just load "jQuery" you now
load the parts of jQuery that you use. All of this would need to be
figured out manually by the user, with room for error, and with
additional bytes shipped. We don't have to look any farther than YUI 3
to see how that worked out.

I discuss that some more here:
http://www.quora.com/How-could-YUI3-improve-its-image-compared-to-jQuery-MooTools-etc

--John

Re: [jquery-bugs-team] File Size Considerations Rick Waldron 11/18/11 12:32 PM
>>
>>   nothing to conspire about here.

That's what they want you to think ;)

>
> --John

Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 12:44 PM
>> If this is an argument about better load times, there are other issues to
>> consider, and I don't know how this affects either argument.  Some
>> questions:
>> - Will cutting out unneeded pieces of jQuery actually help page loads?  As
>> soon as one compiles their code + jQuery, the benefit of caching from the
>> CDN is lost (there's no way we can beat the load time when loaded from
>> cache).
>> - So, how often is jQuery loaded from the CDNs?
>
> I read an article that, unfortunately, I'm unable to find again that
> put the cache hit rate to be rather low. Combine that with mobile in
> which the file may not be cached to begin with and you have more
> requests than you need (and doing more DNS lookups to boot).

Ah, found it:
http://zoompf.com/blog/2010/01/should-you-use-javascript-library-cdns

So the important take away here: Even if you're using Google's CDN,
the likelihood that you'll be getting a pre-cached copy of the library
that's using the same version that you have is rather low. Undoubtedly
the biggest benefit of the Google CDN isn't performance, per se, it's
the fact that it wastes none of your bandwidth, is a reliable server,
and is already minified and gzipped.

To provide a counter-example to Rick, we use this particular technique
(all JS in one file, minified and gzipped) at Khan Academy. (Although
we're not using CC yet, I'm sure we'd love to if given the chance.)

--John

--John

Re: [jquery-bugs-team] File Size Considerations Rick Waldron 11/18/11 12:53 PM
That's awesome, time to flip the script. Thanks for the data

Rick

Re: [jquery-bugs-team] File Size Considerations Alex Sexton 11/18/11 1:16 PM
Just for clarity, the version of jQuery that I'm modularizing still results in the global jQuery and $ object with all the methods on it (when entirely built). This means, like CC, developers don't have to change their code (they just have the option of choosing the features they want in a builder).

Other things to interject for clarity:

- We could still give it out overwhelmingly as a single file. Builder can be secondary.
- To Julian: I wrote the modernizr build tool.
- A builder would be free (complexity wise), since the dependencies are declared in code.
- We don't have to offer the jQuery submodules publicly at all (or we could).

Again, I was mostly just curious to see if it could be done and what the dependency paths looked like. (The AST that's generated from doing this could be just as valuable as the actual code).

It's a long way from happening either way, and I think there are plenty of things we could make smaller and deprecate and support CC better all at the same time. The two solutions are by no means disjoint sets.

Alex
Re: [jquery-bugs-team] File Size Considerations Chad Killingsworth 11/18/11 1:25 PM
This is a large conversation and I'm trying to figure out where the best place to chime in is.

As far as use, you can use CC and jQuery code together now, you just don't get the dead code elimination. That's the biggest improvement we could see by making them compatible. However, I think the improvements won't happen all at once. Once we get the compiler working with jQuery, I expect to see modest gains. However, that will allow us to identify what is blocking the dead code elimination (probably initialization routines that have side-effects).

Outside of Google, making jQuery compatible with CC advanced mode is one of the most requested features. Yes this is for primarily going to be used by power users. To use any code with CC advanced requires some willingness to make changes to your code so it isn't for everyone. Personally I have projects where I'd love to strip out deffereds, ajax and other portions. John is correct that once CC and jQuery are fully compatible a developer should just be able to compile them all together into a single script and CC will remove any dead code.

Compatibility hasn't been a major priority for the CC team until lately. Primarily because we were unsure of whether the jQuery team would be willing to make any modifications to jQuery to facilitate this. It's encouraging to see this level of interest and it should make it easier to get more people on board with these changes.

Chad Killingsworth
Closure-Compiler Project Member
Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 1:39 PM
> Just for clarity, the version of jQuery that I'm modularizing still results
> in the global jQuery and $ object with all the methods on it (when entirely
> built). This means, like CC, developers don't have to change their code
> (they just have the option of choosing the features they want in a builder).
> Other things to interject for clarity:
> - We could still give it out overwhelmingly as a single file. Builder can be
> secondary.
> - To Julian: I wrote the modernizr build tool.
> - A builder would be free (complexity wise), since the dependencies are
> declared in code.
> - We don't have to offer the jQuery submodules publicly at all (or we
> could).
> Again, I was mostly just curious to see if it could be done and what the
> dependency paths looked like. (The AST that's generated from doing this
> could be just as valuable as the actual code).
> It's a long way from happening either way, and I think there are plenty of
> things we could make smaller and deprecate and support CC better all at the
> same time. The two solutions are by no means disjoint sets.

Good to know, thanks for the details Alex. I agree that the ASTs would
be immensely useful for us, as a project - as that would give us the
ability to do all sorts of analysis and optimization (could help with
your project, CC optimization, and just general optimization).

To explain a little bit more about my position regarding modularity:
When I first release jQuery (in January 2006, before it even had a
version) I included a builder mechanism. Back then people were far
more paranoid about file size than they are now. I think all of
jQuery, uncompressed, was smaller than it is now minified and gzipped.
So it goes.

My major issues with a module build system (I assume you mean some
sort of web site, like what jQuery UI has):

- It creates a fragmented version of jQuery. You can no longer look at
the version of jQuery and make determinations about what features
may/may not exist. With jQuery you know that you'll always get THE
jQuery with everything that you need in it, guaranteed. Granted it'll
probably have more in it than you'll use in a simple application but
you won't ever have to worry about making the decisions about what to
include/exclude.

To be clear about the distinction between this and what you would get
with a proper CC-using process is that in your mode you'll have:

[ jQuery - Undesired Modules ] -> Build System -> Compressed jQuery ->
[ Compressed jQuery + jQuery Plugins + User Code ] -> Some Minifier ->
singlefile.js

Thus it'll require two steps to build a performance-optimized system,
whereas the proposed system CC-using system will only have one build
step (we could even look at hosting the minified single file on our
CDN, already gzipped, which would give users one less hurdle to jump).

- It requires extremely precise module categorization and description.
We've already found this to be very confusing with the existing jQuery
code base and API documentation. For example: .text(), most users
don't know if that's part of Attributes or Manipulation or some other
module.

- It's a course tool to solve a fine-grained problem. Modularity
doesn't exist on a "module" level it exists on a method level. As I'm
sure you're finding out there is no consistent dependency path inside
jQuery modules. Some methods in in Manipulation require the Traversal
module, some don't. If you use a method that doesn't then why should
you be forced to include the Traversal module anyway? This is a
problem that Closure Compiler Advanced mode solves completely and
modularity only solves partially.

As far as I can tell the biggest use case for a module picker is "I
want a jQuery with no animations and no Ajax" (or some combination
thereof). In fact you could probably simplify the entire
module-picking experience by just having "jQuery", "Effects", and
"Ajax". Of course then you come down to the weird edge cases: are
.show() and .hide() effects? Is parameter serialization part of Ajax?
(and so on) Closure Compiler's dead code elimination will nuke these
completely and without reservation. Thankfully since they're rather
standalone (Ajax especially) it'll be trivial for that to be removed
and compiled into the code.

--John

Re: [jquery-bugs-team] File Size Considerations Alex Sexton 11/18/11 1:54 PM
All very valid points. The only things that stood out to me that seemed different than what I was doing was:

- Whether we use CC or a builder, we will have fragmented jQueries. (People will no longer be able to just add a plugin to the site later without rebuilding). In the case of modularity, the output of the modules is finite. With CC, there could be weird errors, like where ajax exists, but it no longer supports callbacks (that might be a strawman, but you get what I mean. Dead code can be mid function). The benefit of CC in this regard is only that someone would have to _un_concat someone's code to end up with it somewhere else, whereas concat in the modular case would be optional.

- The current way I'm building the modules is absolutely in a 'by-need-only' dependencies. So the situation where we pull in Traversal even though we never use it would not happen unless the user chose to include ALL parts of Manipulation, or any one of the parts that actually requires it. It's not required at a base level.

I can certainly understand the downsides of it. I don't think it's a good default option. I simply find it more enjoyable to work on tiny little portions of code in separate files so I focus on the heart of each small module. It helps me hone in on problems. This is certainly a personal preference though (hence my own fork).

Hope that helps.
Alex
Re: [jquery-bugs-team] File Size Considerations Julian Aubourg 11/18/11 3:03 PM
All right, I see you decide to ignore the elephant in the room. I'll put it there for the last time:
  • people do not have control over the code they use (plugins, etc),
  • Closure will only give better results than other minifiers IF AND WHEN code is compliant
You choose to ignore those facts, fine. If you put them together, they pretty much invalidate the whole approach but heh, what do I know, right?

And while we struggle with our "education" effort, someone will come and make a modular jQuery that people will actually use because it's bloody simple and straight-forward.

Sometimes I just wonder why I even care.

2011/11/18 John Resig <jer...@gmail.com>

Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 3:25 PM
> All right, I see you decide to ignore the elephant in the room. I'll put it
> there for the last time:
>
> people do not have control over the code they use (plugins, etc),
> Closure will only give better results than other minifiers IF AND WHEN code
> is compliant

Neither of these points invalidate using Closure Compiler. In the
absolute worst case the plugin code will be no worse off than just
using the normal Closure Compiler, giving them a compressed version of
the plugin. In the best case the methods that they don't use will be
stripped out. To reiterate: jQuery plugins do not need to make
explicit changes in order to be useful in this system - at worst
they'll just be compressed like any other piece of code, at best
unused code will be stripped out.

As to jQuery Core, we won't have to make changes to the code to get
basic compliance - all of those changes are happening on Closure
Compiler's side. We can go above-and-beyond and do internal code
reorganization to, perhaps, get even better compression metrics - but
the stripping out of unused methods (and especially of unused modules,
like effects and ajax) is a very real thing that'll be possible
without any changes on our end.

--John

Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 3:37 PM
> - Whether we use CC or a builder, we will have fragmented jQueries. (People
> will no longer be able to just add a plugin to the site later without
> rebuilding). In the case of modularity, the output of the modules is finite.
> With CC, there could be weird errors, like where ajax exists, but it no
> longer supports callbacks (that might be a strawman, but you get what I
> mean. Dead code can be mid function). The benefit of CC in this regard is
> only that someone would have to _un_concat someone's code to end up with it
> somewhere else, whereas concat in the modular case would be optional.

Having to do a re-build is certainly a reality of both systems and
both have their pros and cons.

- With CC the fragmentation is less of a problem as it explicitly
forces you to do a re-build every single time you do a new deploy
that's going to production. You have to make no changes during
development - and you still get to use every method that is available
in jQuery without having to do separate downloads or re-determination
of what modules you'll need. Since there is never any separate jQuery
file that is a portion of the full jQuery file (the "fragment jQuery"
only ever exists in a completely compiled form, integrated with the
rest of the code base) then the fragmentation is almost certainly less
of a problem.

- With a builder you end up making the code/module decisions up front
(you'll need to determine your requirements before development and if
you change your mind while coding you'll have to do a new build to get
the new code). Additionally the current state of the jQuery build will
not be obvious to anyone other than the developer who built it
originally (and maybe even then not entirely so). Since the choices
about what modules to use are done up-front and during development
there is a much higher cost to the developer to actually work under
this process, you'll have to iterate often and have an innate
understanding of your code base.

(As to the strawman example, I'm not sure if that'll be an issue or
not - I haven't heard about any issues as of yet with jQuery in
advanced mode - beside the obvious one that little to no code is being
removed.)

--John

Re: [jquery-bugs-team] File Size Considerations Mike Taylor 11/18/11 3:46 PM

Colin Snover asked me to pass this feedback along:

miketaylr linked to this discussion and I felt that it would be worthwhile to provide a little feedback, since you guys are discussing a problem that other libraries have encountered and about which I have experience. Unfortunately, I’m not a member of this ML any more and it wants me to send an email before I can rejoin, so I just asked him to pass it along for me. I’m sure you can all find me on IRC if you have questions. :)

Instead of trying to go crazy using code optimisers that are basically impossible to write for (I have tried to use Closure Compiler in advanced optimisations mode before—in my experience, getting it to work is so far from “just add a few comments” that any suggestion that it is that easy is laughable to me), I’d really recommend simply implementing a has.js[1]-compatible interface. The built version of jQuery going to CDNs would simply enable all available features, and end-users wanting an optimised experience would use a simple build tool that transforms has() calls in a way that allows for optimizers with dead code removal (CC standard mode, UglifyJS) to delete those blocks of code. This is especially useful for mobile builds, since browser-specific code branches can quickly and easily be eliminated completely.

The has.js mechanism is simple to use, easy to understand, and requires a minimal amount of work from end-users (all they do is add a hash map of features they want to optimize out in their build scripts). It is also an API that is actively used by other libraries and has been proven to work well for reducing code size. CC-AO, on the other hand, is very difficult to understand and use correctly, requires a huge time investment, and requires code to be structured in ways that are highly unintuitive in JavaScript.

AMD would be an excellent solution to supplement has.js support, since it would allow jQuery to work with existing build tools that already support both (require.js and Dojo builder, off the top of my head). It’s a good idea for many other reasons too, but that’s a discussion for another day.

Cheers,

[1] https://github.com/phiggins42/has.js

On Nov 16, 2011 6:49 PM, "John Resig" <jer...@gmail.com> wrote:
Hi All -

Sorry I've been rather swamped the past couple weeks! I had some
thoughts regarding the recent file size/deprecation discussions. I
feel that our way of tackling the issue should be done in multiple
steps:

1) First and foremost, get jQuery working in Google Closure Advanced
Optimization mode. If we can get it so that a user can get a
super-stripped-down version of jQuery by adding in their site code and
jQuery itself this would be a major win - and one that would likely
solve most of the size concerns that we hear now.

2) Deprecate and move bits of code that no one is using to plugins. A
bunch of these are in the spreadsheet (getData/setData,
.data("events"), etc.).

3) Start decoupling bits of internal logic to allow Closure to work
even better. For example, make sure that we're using as little of the
other methods in jQuery, inside core, to avoid pulling in external
modules. Right now I suspect that even a basic statement like
$(function(){ }); will pull in core, events, data, and a bunch of
other modules.

4) Figure out a way to ship a version of jQuery that only deals with
IE 8 and up. Namely: Figure out how to effectively strip out the
non-qsa bits of Sizzle and any bug fixes that may be not relevant.

After all of this is done then we can start looking at removing things
that are inherently not ideal but are still being used. I worry that
we may be trying to drop not-ideal features just to get more filesize
- which shouldn't be our top concern, we still have a ton of work to
do to try and get filesize down in other ways.

If the response from the community has been anything it's been: Give
us a way to customize our jQuery build (closure compiler does this)
and give us a way to drop old browsers (slightly mis-guided, people
think we have more bug fixes than we actually do - I think closure
compiler will help a lot of this but we can still explore it anyway).

--John
Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/18/11 3:56 PM


I think there are solutions to this that would invalidate this point.  Choices do not necessarily have to be made up front with modules.  We don't necessarily need to have a builder.
For instance, if using require:

define(['jquery/core', 'jquery/effects'], function( $ ) {
    // Use these only, add jquery/ajax to dependencies if needed
});
...or however they would end up being split.

Granted this means multiple files, but only for power users as alex suggested, and it could still be run through CC at build time.


(As to the strawman example, I'm not sure if that'll be an issue or
not - I haven't heard about any issues as of yet with jQuery in
advanced mode - beside the obvious one that little to no code is being
removed.)

--John

Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 4:03 PM
> Instead of trying to go crazy using code optimisers that are basically
> impossible to write for (I have tried to use Closure Compiler in advanced
> optimisations mode before—in my experience, getting it to work is so far
> from “just add a few comments” that any suggestion that it is that easy is
> laughable to me),

In Google Closure Compiler Advanced's current state? Absolutely. We'd
have to change large swathes of code in massive ways to meet its
current expectations. Which is why we're working with the Google
Closure Compiler team on this. They have a lot of solutions to the
current problems that exist and it seems like the resulting changes
that'll be required to have some level of "dead code removal" in
Advanced Compilation mode for jQuery Core will be rather minimal in
comparison. Naturally there would be more work required (possibly a
lot) to have the code base work in a hyper-optimized
never-include-a-byte-more-than-needed way.

--John

Re: [jquery-bugs-team] File Size Considerations Rick Waldron 11/18/11 4:12 PM
One thing I mentioned earlier, but seems to be forgotten is the support aspect... How do we support a lib that we can no longer assume knowledge of?

Rick

Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 4:13 PM
> I’d really recommend simply implementing a
> has.js[1]-compatible interface. The built version of jQuery going to CDNs
> would simply enable all available features, and end-users wanting an
> optimised experience would use a simple build tool that transforms has()
> calls in a way that allows for optimizers with dead code removal (CC
> standard mode, UglifyJS) to delete those blocks of code. This is especially
> useful for mobile builds, since browser-specific code branches can quickly
> and easily be eliminated completely.
>
> The has.js mechanism is simple to use, easy to understand, and requires a
> minimal amount of work from end-users (all they do is add a hash map of
> features they want to optimize out in their build scripts). It is also an
> API that is actively used by other libraries and has been proven to work
> well for reducing code size. CC-AO, on the other hand, is very difficult to
> understand and use correctly, requires a huge time investment, and requires
> code to be structured in ways that are highly unintuitive in JavaScript.

It seems like has.js would be a useful solution for those that want to
do a platform-specific build of jQuery (stripping out IE bug fixes,
for example). Additionally it seems like it would be useful for those
features that don't fall under the immediate prevue of Closure
Compiler (like custom selectors, for example). It doesn't seem like
these two technologies are mutually exclusive - in fact it seems like
has.js can be used in conjunction to catch some of the "rough edges"
and reduce the file size even further.

Following up on the previous "builder" discussion, I feel like
something like this is obviously a power user feature in which
conscious decisions would need to be made about these edge cases - and
thus should be made all the more explicit. As you mentioned, having an
explicit definition object would make sense in this case - it makes
less sense to have to define things like "remove-method" or something
(Closure Compiler can strip the dead code path for that) and more
sense to define something like "native-querySelectorAll-only" (since
that's a browser dependency/conscious choice that the compiler can't
understand).

--John

Re: [jquery-bugs-team] File Size Considerations Addy Osmani 11/18/11 4:18 PM
My two cents: there appear to be two distinct factions debating here, one with a desire to go down the AMD/modular jQuery route and another quite set in opting for GC in advanced optimisation mode. I would personally side with a has.js/AMD solution (if implemented cleanly) however John does make some valid points about GC and why something strictly split up may not make the most sense.

Given Alex has already begun some initial work on the first of these approaches, is there any reason not to explore both paths (for now)?. We could evaluate either internally (or with the public) which is the more sensible option once we *actually* have something proven available that demonstrates why either approach merits being used.

I say this as there's thus far been quite a lot of suggestion about what *may* be possible. We're still at an explorative/experimental point with both so why not continue working towards a point of evaluation? I'd argue both approaches still have to prove themselves.

Sent from my iPad
Re: [jquery-bugs-team] File Size Considerations Yehuda Katz 11/18/11 4:19 PM
I think we are now conflating a *ton* of issues:
  1. There are a number of features that are in very limited use that we would like to deprecate and remove.
  2. There are a number of features that are in wider use that we consider bad practice and would like to deprecate and remove.
  3. There are a number of features that are good (like support for all of the Ajax options), but which we, in retrospect, don't think gained wide enough use to justify their file size.
  4. A number of people are using jQuery in "modern browser only" environments and would like to be able to strip out functionality specifically for older browsers. In general (with some exceptions?), this provides modest, but not major, file size improvements.
  5. More advanced users who know they are not using certain features (such as Ajax or animations) would like the ability to remove them entirely.
This thread has completely ignored the first three of these considerations, and has focused entirely on (5). Colin's proposal focused entirely on the (4). 

I honestly would like to see efforts made to improve the internal module structure of jQuery, but I don't think that it would likely have significant file size benefits for a large number of people. The ability to choose from a much less intense (for us), much less granular set of modules like "DOM, Ajax, Effects" would probably hit 80% of (5) with a tiny % of the work.

Building jQuery builds that targeted very specific feature-detect profiles would be useful in a few cases, but probably not in the majority of cases. The web is still changing a lot, and the ability to have a build of jQuery that will work on "mobile browsers" is not as simple as punching in "the profile for iOS 5.0.0" and calling it a day.

Closure Compiler, if the CC folks agree to significantly improve advanced mode *and* commit to fully and clearly documenting it, seems worthwhile, because the cost-benefit tradeoff (in the case of better engagement with the CC folks) would be very clear.

I think we really need to have a conversation about (1), (2) and (3).

Yehuda Katz
(ph) 718.877.1325
Re: [jquery-bugs-team] File Size Considerations Yehuda Katz 11/18/11 4:22 PM
Can someone explain precisely what problem AMD would be solving and by what mechanism?

Yehuda Katz
(ph) 718.877.1325
Re: [jquery-bugs-team] File Size Considerations Dave Methvin 11/18/11 4:25 PM
On Fri, Nov 18, 2011 at 7:13 PM, John Resig <jer...@gmail.com> wrote:
> Following up on the previous "builder" discussion, I feel like
> something like this is obviously a power user feature in which
> conscious decisions would need to be made about these edge cases - and
> thus should be made all the more explicit. As you mentioned, having an
> explicit definition object would make sense in this case - it makes
> less sense to have to define things like "remove-method" or something
> (Closure Compiler can strip the dead code path for that) and more
> sense to define something like "native-querySelectorAll-only" (since
> that's a browser dependency/conscious choice that the compiler can't
> understand).

If we can convince many/most people to combine and run all their code
through a CC  process there is a lot we can do. Although it does bring
up Rick's issue:

On Fri, Nov 18, 2011 at 7:12 PM, Rick Waldron <waldro...@gmail.com> wrote:
> One thing I mentioned earlier, but seems to be forgotten is the support aspect... How do we support a lib that we can no longer assume knowledge of?

Support, care, and feeding of this CC-based process could end up
taking a significant amount of someone's time, plus the effort
required to track down problems that people have after they use it.
Debugging the code after it's been processed is a challenge, and
although there is a Chrome plugin there are plenty of other
environments where no help would be available. I think we'd need to
see this process in action once CC is modified and determine how
practical it can be.

Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 4:32 PM
>> One thing I mentioned earlier, but seems to be forgotten is the support aspect... How do we support a lib that we can no longer assume knowledge of?
>
> Support, care, and feeding of this CC-based process could end up
> taking a significant amount of someone's time, plus the effort
> required to track down problems that people have after they use it.
> Debugging the code after it's been processed is a challenge, and
> although there is a Chrome plugin there are plenty of other
> environments where no help would be available. I think we'd need to
> see this process in action once CC is modified and determine how
> practical it can be.

Absolutely. ANY builder that we construct or use will require a lot of
love. If the jQuery UI builder is any indicator we'll have scaling
issues to boot. I'd be more inclined, if we had a builder, to have it
be part of the Makefile build process so that people could diddle it
until their heart is content.

On the note of debugging - presumably debugging *any* "properly"
deployed production code would be a challenge. I think everyone here
agrees that when you deploy to production you'll be doing all sorts of
minification and compression - this makes debugging especially hard
any way you slice it (potentially CC-added issues notwithstanding).

--John

Re: [jquery-bugs-team] File Size Considerations Dan Heberden 11/18/11 4:33 PM
Is CC going to affect the other things? If we look into deprecating parts of the API, pull pieces out as plugins, modularize the library to support things like has.js - is looking at and possibly supporting CC going to eliminate those as possibilities? It feels like the thread is arguing those points against each other when, as I said quite a few emails ago, they seem quite parallel. 

If CC wants to work with us to figure out the extend code paths, cool - if we can get support for CC with tools and support from them we can count on, cool. But that doesn't need to prevent us from offering other options, or removing cruft from the library. 
Re: [jquery-bugs-team] File Size Considerations John Resig 11/18/11 4:43 PM
> Is CC going to affect the other things? If we look into deprecating parts of
> the API, pull pieces out as plugins, modularize the library to support
> things like has.js - is looking at and possibly supporting CC going to
> eliminate those as possibilities? It feels like the thread is arguing those
> points against each other when, as I said quite a few emails ago, they seem
> quite parallel.
> If CC wants to work with us to figure out the extend code paths, cool - if
> we can get support for CC with tools and support from them we can count on,
> cool. But that doesn't need to prevent us from offering other options, or
> removing cruft from the library.

It doesn't affect the physical coding efforts, no. API
Deprecation/plugin-ization/has.js can/could all happen regardless of
what's discussed here today.

The one area that's particularly tangential is having a "builder"
tool/modularization. As I discussed with Alex before, this is a
particularly course-grained tool that solves some of the problems that
users are having but in a way that can be done much better with a
deal-code-removal tool like CC.

What the main debate (disregarding the general deprecation/plugin
discussion) seems to be about is having a tool that can give users the
ability to have a smaller jQuery of some sort. I feel like CC has the
potential to provide a better tool in comparison with a traditional
click-checkboxes-for-the-features-you-want style builder (or AMD-style
module loader, for that matter).

--John

Re: [jquery-bugs-team] File Size Considerations Dave Methvin 11/18/11 5:24 PM
On Fri, Nov 18, 2011 at 7:22 PM, Yehuda Katz <wyc...@gmail.com> wrote:
> Can someone explain precisely what problem AMD would be solving and by what
> mechanism?

I don't know about AMD in particular but even after CC processing, I
could see a case where someone might want to split scripts into chunks
and load some of them later.

For example, if you look at fortune500-app.com it's got a 300KB
monolithic compressed file that has all of jQuery and Sproutcore
including the rendering for every view. Waiting for that to load on an
iPad via 3G is no fun. So maybe Closure gets that down to what, 280K?
It's still big. You might want that in two parts, the jQuery stuff and
a boot loader plus some initial loading and login screen, then a
second file that has Sproutcore and the views. But it *still* would be
nice to process the two pieces together in a CC tool so you get the CC
benefit.

I do think this also brings up the question of where to point the
bloat-finger. How much of the typical webapp is jQuery, versus other
code that is unlikely to be trimmable by dead-code elimination? I
wonder what CC could do for Sproutcore.

Re: [jquery-bugs-team] File Size Considerations Alex Sexton 11/18/11 5:42 PM
There are a number of features that are in very limited use that we would like to deprecate and remove.

AMD doesn't help with this. CC doesn't either. If anything AMD makes the removal easier from a file deletion standpoint. But that's just a ridiculous argument and I'm not making it.

There are a number of features that are in wider use that we consider bad practice and would like to deprecate and remove

This is more or less the same as #1, the only difference is the social mechanisms we use to educate people why their favorite features are gone. Code wise it's the same.

There are a number of features that are good (like support for all of the Ajax options), but which we, in retrospect, don't think gained wide enough use to justify their file size.

Again, pretty much the same thing. AMD doesn't go a long way to solve this, but it'd easy to be split out as available as part of a custom build in the builder. Modernizr has the idea of a core Modernizr file that can be built and configured, but then we also pull in the "community-detects" folder as well as some extra tests that we don't think should be in the 'one file version' of Modernizr. We haven't had confusion that I've heard of with people not understanding that Modernizr can have different sets of test, but to be fair the tests are far less dependent on each other.

To all three questions, AMD is not necessarily an answer (certainly not at the cost that it comes at), but it definitely isn't a hinderance to any of those things. You are probably pointing out that the conversation should be centered around that discussion more than the latter, but I mentioned my modular branch as an aside in a discussion about building subsets of jQuery. It was fairly applicable to the context. I am happy to move it to another thread if people still want to talk about it.


To the question of what does AMD solve?- I think all of us are quite aware of Yehuda's dislike for AMD (seriously fine with me), but I'll answer anyways:

I am not proposing exposing the amd modules (unless there is demand and we think we can support it) like other libraries do. I like it simply as a means for code separation and modularization. It is a great tool/pattern in my development chain. That is entirely my opinion. (which is why i just went and started it for myself instead of trying to push it upstream or something). It happens to gain us the ability to build smaller versions of jQuery because it has explicit dependencies listed on every module. I think even just the AST that that dependency tree would give us could be useful in our quest for smaller file size. I think that builder is something that some people want. I understand there are risks in allowing built copies to float around in the wild.

You also seemed worried that the pieces were so granular, and that it'd be a good idea to pull in the larger chunks. I may agree in most situations. It would be cake to make the interface for the builder reflect this decision. jquery.ajax = require(['all','the','subparts','of','ajax']...

--
The only other thing I wanted to get in before I go party tonight (way more important!) is that I've just about solved the builder scale problem with the modernizr build tool in the past. It runs the entire build client-side. I ported uglifyjs to the browser and then run all the operations (r.js is also written in javascript - likely portable as long as the file requests are not cross domain) in the browser and then we use the file api and/or a flash fallback to let you download it. Static.

I didn't mean to derail anything here. I think getting more closure compiler compat is a great idea. I am not passionate enough about this decision to try and force anything on anyone. I just thought it would be cool to try to do.

Apologies on length.

Alex
Re: [jquery-bugs-team] File Size Considerations Alex Sexton 11/18/11 5:46 PM
Please note that I accidentally used two hyphens to separate my two topics of discussion and google may hide the second one from you as if my auto-signature on my emails was a silly argument about clientside build tools.

moar email.
Re: [jquery-bugs-team] File Size Considerations Yehuda Katz 11/18/11 9:24 PM
I think it's worth noting that for all the intellectual effort people put into modularization (this goes back to basically the beginning of jQuery), at the end of the day, jQuery's success was largely built on one-and-only-one build.

jQuery started by saying "basically everyone needs DOM, Ajax, Effects, and Events". Other libraries broke those up into individual pieces, but jQuery took a stand that a single, conventional distribution that everyone can understand beats a bunch of small libraries that people can pick and choose on. At the end of the day, the social pressures involved in technology adoption inside companies fell squarely on the side of this philosophy.

There is large social benefit to being able to be dropped into any project that uses jQuery and knowing what tools are available in the toolchest. There is some small cost to this, but the benefits are huge. As jQuery has grown, this has also helped us provide extremely good support to literally millions of websites using jQuery. Plugins are one thing, but jQuery has strong, usually unwavering opinions about what it is and how to use it. This lets people like Dave Methvin (and many others) field a mind-boggling number of mind-boggling bugs on a daily basis.

Before we start making "jQuery" mean any number of things, let's think hard about why we adopted this philosophy to begin with.

P.S. One of the nice things about CC is that (if done correctly) it doesn't affect this. As a developer using jQuery, I have exactly the same tools in the toolchest, and some "magic black box" decides what pieces of code I don't need. If I later start to use a new method, it will automagically get pulled in. I am somewhat skeptical of the ability to deliver on this promise, but CC doesn't have the same problems that a user-facing modularization effort has.

Yehuda Katz
(ph) 718.877.1325
Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/19/11 9:20 AM


On Fri, Nov 18, 2011 at 7:18 PM, Addy <addyo...@gmail.com> wrote:
My two cents: there appear to be two distinct factions debating here, one with a desire to go down the AMD/modular jQuery route and another quite set in opting for GC in advanced optimisation mode. I would personally side with a has.js/AMD solution (if implemented cleanly) however John does make some valid points about GC and why something strictly split up may not make the most sense.

Given Alex has already begun some initial work on the first of these approaches, is there any reason not to explore both paths (for now)?. We could evaluate either internally (or with the public) which is the more sensible option once we *actually* have something proven available that demonstrates why either approach merits being used.

I say this as there's thus far been quite a lot of suggestion about what *may* be possible. We're still at an explorative/experimental point with both so why not continue working towards a point of evaluation? I'd argue both approaches still have to prove themselves.
This is a very good point.  It may turn out that both provide great advantages.

Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/19/11 9:28 AM


On Fri, Nov 18, 2011 at 7:19 PM, Yehuda Katz <wyc...@gmail.com> wrote:
I think we are now conflating a *ton* of issues:
  1. There are a number of features that are in very limited use that we would like to deprecate and remove.
  2. There are a number of features that are in wider use that we consider bad practice and would like to deprecate and remove.
  3. There are a number of features that are good (like support for all of the Ajax options), but which we, in retrospect, don't think gained wide enough use to justify their file size.
  4. A number of people are using jQuery in "modern browser only" environments and would like to be able to strip out functionality specifically for older browsers. In general (with some exceptions?), this provides modest, but not major, file size improvements.
  5. More advanced users who know they are not using certain features (such as Ajax or animations) would like the ability to remove them entirely.
This thread has completely ignored the first three of these considerations, and has focused entirely on (5). Colin's proposal focused entirely on the (4). 

The first three are important to think about, but I don't think they're necessarily related to this discussion.  They are more immediate issues that will be considered for 1.8+ regardless of the outcome of the discussion concerning modules and/or CC.
 

I honestly would like to see efforts made to improve the internal module structure of jQuery, but I don't think that it would likely have significant file size benefits for a large number of people. The ability to choose from a much less intense (for us), much less granular set of modules like "DOM, Ajax, Effects" would probably hit 80% of (5) with a tiny % of the work.
+1
 

Building jQuery builds that targeted very specific feature-detect profiles would be useful in a few cases, but probably not in the majority of cases. The web is still changing a lot, and the ability to have a build of jQuery that will work on "mobile browsers" is not as simple as punching in "the profile for iOS 5.0.0" and calling it a day.

Closure Compiler, if the CC folks agree to significantly improve advanced mode *and* commit to fully and clearly documenting it, seems worthwhile, because the cost-benefit tradeoff (in the case of better engagement with the CC folks) would be very clear.
+1

Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/19/11 9:41 AM


On Fri, Nov 18, 2011 at 7:22 PM, Yehuda Katz <wyc...@gmail.com> wrote:
Can someone explain precisely what problem AMD would be solving and by what mechanism?

We already implement some of the principles of modularity and it has been very beneficial from a maintenance perspective.  We have separated modules into files containing closures to structure the code into manageable pieces, but we can do better.  Currently, the separations are somewhat arbitrary and it would be advantageous for us to explore the real dependencies for each module.  In other words, the main problem I see AMD solving is code organization.  The ability to remove the Ajax module or the effects module without having to worry about breaking other code is huge win imho, but I cannot argue that AMD solves our file size issues.

Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/19/11 9:42 AM


On Fri, Nov 18, 2011 at 7:25 PM, Dave Methvin <dave.m...@gmail.com> wrote:
Another good point, which I think supplements Addy's point. 

Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/19/11 9:50 AM


On Sat, Nov 19, 2011 at 12:24 AM, Yehuda Katz <wyc...@gmail.com> wrote:
I think it's worth noting that for all the intellectual effort people put into modularization (this goes back to basically the beginning of jQuery), at the end of the day, jQuery's success was largely built on one-and-only-one build.

jQuery started by saying "basically everyone needs DOM, Ajax, Effects, and Events". Other libraries broke those up into individual pieces, but jQuery took a stand that a single, conventional distribution that everyone can understand beats a bunch of small libraries that people can pick and choose on. At the end of the day, the social pressures involved in technology adoption inside companies fell squarely on the side of this philosophy.
+1
 

There is large social benefit to being able to be dropped into any project that uses jQuery and knowing what tools are available in the toolchest. There is some small cost to this, but the benefits are huge. As jQuery has grown, this has also helped us provide extremely good support to literally millions of websites using jQuery. Plugins are one thing, but jQuery has strong, usually unwavering opinions about what it is and how to use it. This lets people like Dave Methvin (and many others) field a mind-boggling number of mind-boggling bugs on a daily basis.

Before we start making "jQuery" mean any number of things, let's think hard about why we adopted this philosophy to begin with.

P.S. One of the nice things about CC is that (if done correctly) it doesn't affect this. As a developer using jQuery, I have exactly the same tools in the toolchest, and some "magic black box" decides what pieces of code I don't need. If I later start to use a new method, it will automagically get pulled in. I am somewhat skeptical of the ability to deliver on this promise, but CC doesn't have the same problems that a user-facing modularization effort has.
 
This is a good point.  Nevertheless, I am not necessarily arguing for user-facing AMD.

Re: [jquery-bugs-team] File Size Considerations Karl Swedberg 11/19/11 9:52 AM
On Nov 19, 2011, at 12:24 AM, Yehuda Katz wrote:

> I think it's worth noting that for all the intellectual effort people put into modularization (this goes back to basically the beginning of jQuery), at the end of the day, jQuery's success was largely built on one-and-only-one build.
>
> jQuery started by saying "basically everyone needs DOM, Ajax, Effects, and Events". Other libraries broke those up into individual pieces, but jQuery took a stand that a single, conventional distribution that everyone can understand beats a bunch of small libraries that people can pick and choose on. At the end of the day, the social pressures involved in technology adoption inside companies fell squarely on the side of this philosophy.
>
> There is large social benefit to being able to be dropped into any project that uses jQuery and knowing what tools are available in the toolchest. There is some small cost to this, but the benefits are huge. As jQuery has grown, this has also helped us provide extremely good support to literally millions of websites using jQuery. Plugins are one thing, but jQuery has strong, usually unwavering opinions about what it is and how to use it. This lets people like Dave Methvin (and many others) field a mind-boggling number of mind-boggling bugs on a daily basis.
>
> Before we start making "jQuery" mean any number of things, let's think hard about why we adopted this philosophy to begin with.
>
> P.S. One of the nice things about CC is that (if done correctly) it doesn't affect this. As a developer using jQuery, I have exactly the same tools in the toolchest, and some "magic black box" decides what pieces of code I don't need. If I later start to use a new method, it will automagically get pulled in. I am somewhat skeptical of the ability to deliver on this promise, but CC doesn't have the same problems that a user-facing modularization effort has.

This is exactly the thought I keep having as I read through this thread. Rick and Dave have also noted the debugging and support issues inherent in any solution that involves either modularizing or pruning jQuery's code base. Dealing with bug triage/support is already a Herculean task. Imagine having to ask about which modules are being loaded for every single bug report and support request. Same thing goes for CC, but if it's something that is implemented into build process, it seems to me that it would be easier to track down the source of an issue if it works with the un-CCed code but not the CCed.

Whether we pursue increased modularity or CC compliance or both, I think the worst thing we could do is jump the gun on making these things easy to use for the casual programmer (with an online builder or some such). At least at first, the barrier to entry for these things should be relatively high.

One nice thing about CC from a support perspective is that it could be fairly easy for a developer to flip the "advanced, code-pruning mode" switch to determine whether a problem is due to CC or some other artifact of deploying code to a production environment. If turning the advanced mode off fixes the problem, then the bug goes to the Google CC team. Or is that an oversimplification?

--Karl

Re: [jquery-bugs-team] File Size Considerations Rick Waldron 11/19/11 11:54 AM
Just getting caught up on the thread, there are a lot of great ideas here when you step back and take it all in at once.

So they say competition breeds innovation, right? I'd like to ask Marijn Haverbeke if he'd be interested in helping jQuery get more advanced code reduction from UglifyJS.

Rick

Re: [jquery-bugs-team] File Size Considerations Alex Sexton 11/19/11 12:12 PM
UglifyJS doesn't do dead code removal. The best we could hope for is better gzipping, I'd imagine.
Re: [jquery-bugs-team] File Size Considerations Rick Waldron 11/19/11 12:38 PM
I'd like to ask Marijn Haverbeke if he'd be interested in helping jQuery get more advanced code reduction from UglifyJS.

I'm not sure which part of that implies that I think that it does...?

Rick
Re: [jquery-bugs-team] File Size Considerations Paul Irish 11/19/11 1:25 PM
On Fri, Nov 18, 2011 at 4:18 PM, Addy <addyo...@gmail.com> wrote:

> Given Alex has already begun some initial work on the first of these
> approaches, is there any reason not to explore both paths (for now)?. We
> could evaluate either internally (or with the public) which is the more
> sensible option once we *actually* have something proven available that
> demonstrates why either approach merits being used.

> I say this as there's thus far been quite a lot of suggestion about what
> *may* be possible. We're still at an explorative/experimental point with
> both so why not continue working towards a point of evaluation? I'd argue
> both approaches still have to prove themselves.

+9000

Alex was already moving ahead for his own sake. It seems like some
people would like to assist him, Sounds good. It's certainly worth
exploring.
Investigating that path doesn't block putting an effort into CC-AO, so
that should be pursued as well.

Re: [jquery-bugs-team] File Size Considerations Alex Sexton 11/19/11 2:35 PM


On Sat, Nov 19, 2011 at 2:38 PM, Rick Waldron <waldro...@gmail.com> wrote:
I'd like to ask Marijn Haverbeke if he'd be interested in helping jQuery get more advanced code reduction from UglifyJS.

I'm not sure which part of that implies that I think that it does...?

Well, it turns out that it actually _does_ have some dead code removal now. 

Also, the context of this conversation is about code removal. That you would mention the above in this conversation implies (to me) that you thought it did. I don't think that's a stretch, and you don't have to be such a buzzkill when someone misunderstands you. Just trying to problem solve.

Alex

Re: [jquery-bugs-team] File Size Considerations Rick Waldron 11/20/11 8:04 AM
I was flat out saying that we should ask Marijn if he'd be interested in developing such features ( I wasn't aware that they already existed) and your response was nothing short of trolling/buzzkilling so I'd say we're even ;)

Rick
Re: [jquery-bugs-team] File Size Considerations Mathias Bynens 11/20/11 8:14 AM
I’m just gonna leave this here…

Re: [jquery-bugs-team] File Size Considerations Addy Osmani 11/20/11 9:26 AM
RE: jquip

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:
I’m just gonna leave this here…




--

Addy Osmani

Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams member
Blogger at: http://addyosmani.com

Re: [jquery-bugs-team] File Size Considerations Yehuda Katz 11/20/11 12:08 PM
Claiming that this is 90% of jQuery is laughable. Removing event delegation, event normalization, support for many selectors in browsers without qSA of course reduces the size, but these features are commonly used and what remains does not, IMHO, make up "90% of the good parts of jQuery".

This is definitely better than Zepto's half-hearted effort, but once he starts adding in the features that people are clamoring for, he'll either have a lot more caveats (like the non-qSA selector caveat), or a bigger size.

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. 

Sent from my iPhone
Re: [jquery-bugs-team] File Size Considerations Addy Osmani 11/20/11 12:13 PM
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.

 

Sent from my iPhone

On Nov 20, 2011, at 9:27 AM, Addy Osmani <addyo...@gmail.com> wrote:

RE: jquip

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:
I’m just gonna leave this here…




--

Addy Osmani

Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams member
Blogger at: http://addyosmani.com

Re: [jquery-bugs-team] File Size Considerations ajpiano 11/20/11 1:14 PM
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!

--adam
Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/20/11 2:31 PM


On Sun, Nov 20, 2011 at 3:13 PM, Addy Osmani <addyo...@gmail.com> wrote:
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. 
Sorry, I don't see jquip as useful at all.  I'm not sure where to start...
 

I'd personally be more interested in seeing where the other two paths (AMD via Alex's fork and of course GC) take us.

 

Sent from my iPhone

On Nov 20, 2011, at 9:27 AM, Addy Osmani <addyo...@gmail.com> wrote:

RE: jquip

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:
I’m just gonna leave this here…




--

Addy Osmani

Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams member
Blogger at: http://addyosmani.com




--

Addy Osmani

Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams member
Blogger at: http://addyosmani.com


Re: [jquery-bugs-team] File Size Considerations Timmy Willison 11/20/11 2:36 PM


On Sun, Nov 20, 2011 at 4:14 PM, adam j. sontag <ajp...@gmail.com> wrote:
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.
 

--adam



  
 
On Sun, Nov 20, 2011 at 3:13 PM, Addy Osmani <addyo...@gmail.com> wrote:
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.

 

Sent from my iPhone

On Nov 20, 2011, at 9:27 AM, Addy Osmani <addyo...@gmail.com> wrote:

RE: jquip

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:
I’m just gonna leave this here…




--

Addy Osmani

Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams member
Blogger at: http://addyosmani.com




--

Addy Osmani

Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams member
Blogger at: http://addyosmani.com



More topics »