Hi, I also think, that performance is very important for a good library. No one uses jquery without any plugin (even if he / she has written an own plugin which uses jquery). Of course, it is important to have small files. But I think, it is still more important, to have a performant core, which enables to build complex and powerful plugins. There should be a trade off between size and performance.
So, there are to ways: * We need a plugin, that enables to speed up the core. It can be used in web applications, which need a lot of perfomance. It doesn't matter, if some core functions are not used any more (performance is the goal). It is important, that the jquery style still remains and that other jquery plugins will still work (this is very important, I think). * It doesn't matter, if jquery is <20kb or <30kb. But it shouldn't be 100kb. The jquery core enables to write performant applications and it should still be small. There must be a trade off. I like both approaches. But there should be the possibility to speed up the core. I don't want to use another library just because I need to write a performant application. And I don't want to rewrite good plugins just because I cannot use the original jquery core. If we want to have many good plugins, than there should be the possibility to reuse the plugins in every situation. Mathias On 2 Apr., 18:08, "Dan G. Switzer, II" <[EMAIL PROTECTED]> wrote: > 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]://www.iambright.com
