The "selector turbo" plugin is a good idea. But, in this case, all the selector code in the core will be useless using these plugin. Maybe it's a good time to have custom builds.
On 4/2/07, Glen Lipka <[EMAIL PROTECTED]> wrote:
I agree. At many big corporations you already have scripts that are required. Google analytics scripts, Survey scripts, offermatica scripts, e-commerce scripts. Plus the general cruft of legacy scripts for a myriad of purposes. Not to mention all the screenshots and 100K of marketing text. Selling jQuery as the answer for client-side interactivity is much easier when we say, "It's only 20k" This implies using jQuery on sites that need speed and do not have a ton of "selecting" to do. For more intensive sites with larger selecting needs, I think it might be worthwhile to have a "Selector Turbo" plugin that might be large, but will increase selector speed for applications that need it. Is something like this possible? Glen On 4/2/07, Rey Bango <[EMAIL PROTECTED]> wrote: > > > Hi everyone, > > After reading Ralf Engelschall's posting about jQuery select speed > improvements, I have to say that I was so impressed by how a small > change can dramatically help improve performance. As Karl said, awesome > work on the speed enhancements and also on not increasing the file size. > > The latter is a BIG thing for the jQuery project. The general reason > that other libraries such as DomQuery or Base2 can have dramatic speed > enhancements is because they're not focused on keeping down the size of > their files and/or the final compressed product. Its definitely not a > knock at them. Both Dean and Jack are awesome developers and have great > solutions. File size, though, is not they're focus and that gives them a > lot of flexibility in making design decisions that can produce dramatic > results. > > One of the goals of the jQuery project is that we're constantly trying > to improve the features while still maintaining a nice, tight package. I > think to date, the core team has done an absolutely amazing job of > balancing out functionality and performance. Another goal is to nurture > this awesome community so that developers feel empowered to extend the > jQuery core in unique ways that add tremendous value to the whole > project. Again, I think this is something that we've done SO much better > than any project out there. > > I think its important that everyone have an understanding of why certain > things are done on the project so that when you see a comparison test > and wonder why we're not the fastest, you have a clearer picture of how > something like a selector performance test fits into the overall > strategy of the project. > > With that said, I do challenge everyone on the list to continue to look > for ways to improve the library. Everyone on the jQuery Porject team is > VERY receptive to new ideas, especially John Resig. Ralf's code is an > excellent example of a contribution that could make an impact on the > project and I encourage everyone to look for ways to improve the > library. > > We'd also like to hear your opinions on any issue that you think merits > reconsideration. Whether it be file size, components that should be in > core or site documentation, we want to hear about it. > > Thanks for your time. > > Rey Bango > Evangelism Team > jQuery Project > > > -- > BrightLight Development, LLC. > 954-775-1111 (o) > 954-600-2726 (c) > [EMAIL PROTECTED] > http://www.iambright.com >
