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

Reply via email to