Here's my 2 cents...
I think the core developers now have a pretty good idea of what the jQuery "core" should and shouldn't be. I some sense, the hardest part is trying to decide how much to include in the base package. It's also one of the largest contributors to the overall size of the library. So, while I like the fact they want to keep the size as small as possible (and it's cool telling people it's less than 20k) I'd much rather see speed optimizations go in and the size increase a little bit. I don't want to see it turn into a beast-but anything under 25K still isn't much data (and even that should be cached for most browser configurations.) As long as feature additions are kept at a minimum, I don't mind an increase in size for performance gains. -Dan _____ From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Glen Lipka Sent: Monday, April 02, 2007 11:35 AM To: jquery-en@googlegroups.com Subject: [jQuery] Re: jQuery selectors speed improvements - A different perspective 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
