Google Groups

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


Timmy Willison Nov 18, 2011 8:33 AM
Posted in group: jQuery Bugs Team


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.


 
--John



On Thu, Nov 17, 2011 at 7:08 PM, Timmy Willison <timmyw...@gmail.com> wrote:
>
>
> On Thu, Nov 17, 2011 at 5:11 PM, Dave Methvin <dave.m...@gmail.com>
> wrote:
>>
>> > 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.
>
>
> 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.
>