Things I would vote to increase the base size with: 1. Dimensions http://jquery.com/plugins/project/dimensions (13k uncompressed / 3 packed) 2. More selectors: http://www.softwareunity.com/sandbox/JQueryMoreSelectors/ (12k uncompressed / ? packed) 3. Speed Improvements (Up to 10k additional?)
However, there is a name missing from this thread. John Resig Esq. It's his vision, and I think he will get the final say. He has to answer what it would take to reconsider the 20k ceiling. For me, I think the base should be focused on enabling the end-developer AND the plugin developer. I think dimensions, and selectors are the meat and potatoes of the base and should come with that out of the box. Speed is less critical for me, but I agree with the perception issue brought up earlier. It should be in the ballpark. Who is good with surverymonkey.com or equivalent? We need some data. Glen On 6/12/07, Su <[EMAIL PROTECTED]> wrote:
On 6/12/07, Glen Lipka <[EMAIL PROTECTED]> wrote: > > This topic comes up every time a speed test emerges. To me, speed is > totally irrelevant in most circumstances that I use jQuery. It does, and it is. That was why I tried to open the consideration out a bit further to the eventuality of something more substantial running into the filesize cap. I'm of the opinion that the true goal is keeping the library (as) small (as possible), except that "small" isn't a number, so an essentially arbitrary one was chosen. And that's fine, otherwise "small" would continually be open to interpretation. Some people say they'd allow up to 25 or 30k, you say up to 50, etc. But I'm also curious to know that the limit isn't also arbitrarily absolute. I'm interested what sort of thing it would take to bring about a serious reconsideration of that limit, without even getting into discussion of the numbers that would be involved. The differences shown in this test, for example, don't seem likely to do it.
