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.
- Unneeded modules can be removed by the user.
- No extra compilation and no advanced mode compatibility required.
- 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.
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>
>> > 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.