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 >> discuss@jquery.com >> http://jquery.com/discuss/ > > > _______________________________________________ > jQuery mailing list > discuss@jquery.com > http://jquery.com/discuss/ _______________________________________________ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
