I think that the point that I am trying to make is that we create some number of prepackaged files. Each prepackaged file is completely standalone and does not require any other jQuery files to be requested. We decide what functionality set gets bundled into each package and describe that functionality maybe in a comparison table with check marks for included functionality.
Then the average user that does not want to download all the build tools and figure out how to edit the make files to select whatever functionality they might think they need and then broke it because they forgot some dependency, etc. etc. can simply look at the check list and pick the pre-packaged file that covers what they need. This means that the user loads ONE jQuery file, that size of it depends on which package they choose. This makes the chooses limited, clear, and that means there is a high probability of success from the user's point of view - This is good. I just think that we should make it as easy as possible for the new user to jump in and use jQuery. If we can provide a good simple fast dynamic packaging system then great! This is an alternative that is easy to implement a good compromise and requires minimal training to use. Anyone that has the willing to dig into the tools can probably figure out how to make a custom package to fit their needs or to optimize the package to their special requirements. -Steve Corey Jewett wrote: > The problem with all this is that 4 js files totaling 20K is will > typically make your page load slower than 1 20K JS file. There are a > couple reasons: > > 1) round trip time per each additional requests for each file. > Roughly equivalent to ping lag + server processing time. I wouldn't > be surprised if this was an extra 250 millis per request. > > 2) the HTTP RFC suggests a maximum of 4 open connections from a > client to a server. More files == larger backlog of files == poorer > utilization of broadband connections. > > 3) HTTP pipelining (assuming it's even turned on, which it frequently > isn't since it wastes server resources) can theoretically mitigate > #2, but will not do much for #1. It'll cut out repeated setup and > teardown of TCP stacks. > > 4) I haven't done any recent research on it, but don't browsers tend > to cache JS files anyway? > > Now having said all that, if you still want to whittle down the file > size, can I make a vote to maybe yank serialization, but nothing > else. From the response so far it appears that there's a pretty even > split between people who use/don't FX and/or AJAX. Meaning that > pulling either one out is sure to screw up the other half. > > I could get on board with releasing several packages, as somebody > suggested: > > JQuery: src/jquery + src/events + src/fx + src/ajax > JQuery-fx-only: src/jquery + src/events + src/fx > JQuery-ajax-only: src/jquery + src/events + src/ajax > Jquery-dom-only: src/jquery + src/events > JQuery-lite: src/jquery > > This just seems likely to generate a lot of extra support problems on > the mailing list. Can't we just leave it up to people to build their > own if they really want to cut it down below 20K? > > Corey > > > > On Nov 14, 2006, at 2:22 PM, Stephen Woodbridge wrote: > >> John, >> >> That is why I think some prepackaged packages might work better in the >> short term. >> >> Longer term we might want to have plugins define a requires >> statement so >> that is would be easier for a build system to pull in all the required >> modules. >> >> -Steve >> >> John Resig wrote: >>> I'm all for the custom build feature - in fact it was one of the >>> first >>> things included on the jQuery home page when it first launched >>> back in >>> Jan. (I removed it at the 1.0 launch, because it was broken). >>> >>> My biggest worry about having custom builds is that if a user sees >>> something in the documentation (e.g. .height()) and then it doesn't >>> work at all, that'll cause a lot of confusion. Figuring out what >>> package everything is in. It is for this reason that I think any sort >>> of package system has to be documented very explicitly so that people >>> know what they're getting in to. >>> >>> This would also require that all demos, tutorials, and plugins use >>> the >>> lowest comon denominator of code (which will require a lot of >>> rewriting). In all, it's very tricky, and something that we'll >>> want to >>> consider carefully. >>> >>> --John >>> >>> On 11/14/06, Stephen Woodbridge <[EMAIL PROTECTED]> wrote: >>>> I think that it would be great if we had a few bundled "flavors" >>>> like: >>>> >>>> jQuery-minimal.js >>>> jQuery-lite.js >>>> jQuery-standard.js >>>> jQuery-heavy.js >>>> >>>> This way we get the benefit of claiming all the features and can >>>> claim >>>> "starting at only xx bytes" based on the packed size of the minimal >>>> flavor. Providing a other flavors makes it easy for uses to grab a >>>> package of features without having to deal with build issues. >>>> >>>> -Steve >>>> >>>> John Resig wrote: >>>>> Hi Everyone - >>>>> >>>>> I want to start a discussion about the features that should go into >>>>> (or be removed from) the upcoming 1.1 release. I'd like to shoot >>>>> for a >>>>> release by the end of this month. >>>>> >>>>> I know that Joern already has some event code, ready to be >>>>> committed - >>>>> and I have the "non-destructive jQuery" code ready to go. Brandon >>>>> mentioned that he wants to rewrite the jQuery.attr() in time for >>>>> release too. >>>>> >>>>> No significant features are going to be added to this release, >>>>> think >>>>> of it as jQuery 1.0++. >>>>> >>>>> Right now, the jQuery compressed build is teetering around >>>>> 18-19KB, I >>>>> really want to try and cut this down. Any thoughts on particular >>>>> features that should be extracted into a plugin? >>>>> >>>>> For example: Since the 'form' plugin already does serialization >>>>> really >>>>> really well (much better than jQuery's serialization). I'm >>>>> tempted to >>>>> remove the serialization plugin from core and just defer >>>>> everyone to >>>>> using the form plugin. >>>>> >>>>> Also, stuff like .height() and .width() could be removed in >>>>> favor of >>>>> using the (more powerful) methods of the same name in the >>>>> 'Dimensions' >>>>> plugin. >>>>> >>>>> Let me know if you have any ideas. >>>>> >>>>> --John >>> _______________________________________________ >>> jQuery mailing list >>> [email protected] >>> http://jquery.com/discuss/ >> >> _______________________________________________ >> jQuery mailing list >> [email protected] >> http://jquery.com/discuss/ > > > _______________________________________________ > jQuery mailing list > [email protected] > http://jquery.com/discuss/ _______________________________________________ jQuery mailing list [email protected] http://jquery.com/discuss/
