As is often the case, there is a trade-off between the convenience of having functionality in a single file, and file size. I often don't need any ajax, but I'm happy to not have to deal with multiple files just to get it.
Personally, I really don't care for "download manager" package builder things. It seems like once you've built a few different versions of jQuery, you've ended up worse off than if you had just used one bigger version and let caching do its thing.
How would including all of dimensions in the core affect the filesize?
And while we're on the subject, how about the form plugin? What's another 8k? ;)
--Erik
<div><span class="gmail_quote">
On 9/8/07, <b class="gmail_sendername">John Resig</b> <<a href="mailto:jeresig@gmail.com">
jeresig@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Right now, we're looking at the difference between high 24k/low 25k
without and high 25k with .offset() included. (900 bytes, total) So
filesize is much less of an issue here.
Off-list, Brandon brought up an excellent point: "Honestly, we are the
only library that doesn't include such dimensions oriented methods in
the core."
Which is a really important point. I think we could see a definite
increase in interesting applications with the default inclusion of
this method.
And Yehuda brought up: "We don't have an offset method because it's in
a plugin, as per jquery's philosophy; our lack of bundling technology
is hurting us on that front"
I do, definitely, think that bundling (having a good downloader
application) is one piece of the puzzle - but it also adds a severe
level of complexity to the library - no longer is jQuery a
drop-dead-simple, everyone uses the same file, include.
Honestly, I don't think we'd be having this discussion if .offset()
wasn't already in a plugin - it would be the obvious choice to have it
be included, by default. It's such an essential piece of functionality
that its loss is a serious gap for the library. (loss in the sense of
being "not immediately available")
I've now added .offset() back into the default build with the hope
that the UI code (and other plugins) will be able to transition away
from it's .offset() to the new core .offset(). I no longer expect this
to happen this weekend, but it would be good to have this happen as
soon as possible, once the code arrives.
--John
On 9/8/07, Dan G. Switzer, II <
<a href="mailto:dswitzer@pengoworks.com">
dswitzer@pengoworks.com</a>> wrote:
>
> >> > If I had the option of using jQuery with or without the Dimensions
> >Plugin,
> >> > I'd always use the version w/the Dimensions Plugin built in.
> >
> >Yeah !
> >dimensions.js packed is up to 5Ko if I remember well. If it was me I
> >would include it in jQuery itself, if not, it should definitely be in
> >the core of jQuery UI.
>
> I'd rather see it included with the core jQuery library. I'm in the boat of
> people who don't mind seeing the library grow a little bit. To me anything
> under 30K is acceptable. I also see the Dimensions plug-in as really crucial
> for anything other than just basic DOM insertion.
>
>
> >
>
</blockquote></div>