[jQuery] Re: SlickSpeed CSS Selector TestSuite
I agree with all the points about jQuery's greatness thus far, but... I have noticed that jQuery's animation can sap an older CPU, even in simpler examples. I understand that the SlickSpeed test is not about animation, but given my anecdotal observations, the user experience on older PCs leaves something to be desired. I am in no way singling out jQuery for this problem, but I am pointing it out here so that maybe, if there is any chance that an speed-optimized version could become available, it would really seal the deal for me and jQuery (and all of my clients as well). This used to be a question of demographics as much as anything else (am I developing sites for grandmas or affluent corporate types), but with the iPhone (which doesn't have a dual-core 2GHz CPU) and other web-enabled devices, the game changes. What are the chances of seeing a speed-optimized library? -- View this message in context: http://www.nabble.com/SlickSpeed-CSS-Selector-TestSuite-tf3907626s15494.html#a11355849 Sent from the JQuery mailing list archive at Nabble.com.
[jQuery] Re: SlickSpeed CSS Selector TestSuite
v1.1.3 will have enhanced performance in many areas including selectors, effects, and animations. It should be out very, very soon. jsrobinson wrote: I agree with all the points about jQuery's greatness thus far, but... I have noticed that jQuery's animation can sap an older CPU, even in simpler examples. I understand that the SlickSpeed test is not about animation, but given my anecdotal observations, the user experience on older PCs leaves something to be desired. I am in no way singling out jQuery for this problem, but I am pointing it out here so that maybe, if there is any chance that an speed-optimized version could become available, it would really seal the deal for me and jQuery (and all of my clients as well). This used to be a question of demographics as much as anything else (am I developing sites for grandmas or affluent corporate types), but with the iPhone (which doesn't have a dual-core 2GHz CPU) and other web-enabled devices, the game changes. What are the chances of seeing a speed-optimized library? -- BrightLight Development, LLC. 954-775- (o) 954-600-2726 (c) [EMAIL PROTECTED] http://www.iambright.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Well, for my intranet projects will better if the selectors are faster even with 100k but have to exists 2 versions, the fasterfat and the slowerthin It´s funny how mootols get an error with div[class|=dialog] and 0ms but jQuery have problems with div:nth-child(2n), div:nth-child(2n+1),div:nth-child(n) and returns 0 elements too, but dont get an error so the time was 543 ms | zero results each On 6/15/07, Toby [EMAIL PROTECTED] wrote: You gotta admit, 1.2mb for that page is explosively large ;¬] From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Glen Lipka Sent: 13 June 2007 17:47 To: jquery-en@googlegroups.com Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite http://www.apple.com/safari/ File size 1.2 megs. If Toby worked on this website, I think he would spontaneously combust. Glen PS. Every page I visit on Apple seems to get bigger and bigger. -- []´s Jean www.suissa.info Ethereal Agency www.etherealagency.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
You gotta admit, 1.2mb for that page is explosively large ;¬] _ From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Glen Lipka Sent: 13 June 2007 17:47 To: jquery-en@googlegroups.com Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite http://www.apple.com/safari/ File size 1.2 megs. If Toby worked on this website, I think he would spontaneously combust. Glen PS. Every page I visit on Apple seems to get bigger and bigger.
[jQuery] Re: SlickSpeed CSS Selector TestSuite
I agree with Glenn on this one. I vote for more speed, we need to fight back. Another 5k doesn't matter that much to me or my clients since all of them have caching on. Maybe an extra plugin?
[jQuery] Re: SlickSpeed CSS Selector TestSuite
In IE6 that seems to be the case, but I discovered that by accident with a buggy script. Haven't deliberately tested what happens in other browsers, I would think that they probably all just return the first element they find with the correct ID but as the behaviour is describes as undefined I wouldn't write any scripts that depend on that. On Jun 13, 1:31 am, Aaron Heimlich [EMAIL PROTECTED] wrote: On 6/12/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote: Plus, what happens if you have: div id=bam / span id=bam / What if you need to retrieve the span tag? If it's checking #bam first, won't it only find the div / element? The DOM2 has this to say: getElementById introduced in DOM Level 2 Returns the Element whose ID is given by elementId. If no such element exists, returns null. Behavior is not defined if more than one element has this ID. Source:http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId I would think that the first one the browser finds is selected, but I can't be certain of that as I've never actually tried to do this. -- Aaron Heimlich Web Developer [EMAIL PROTECTED]://aheimlich.freepgs.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
I hear what everyone is saying about IDs, but lets flip the switch here and what if we have: div class=bam span class=bam This situation is a valid situation, one I normally am in (actually in a link situation). So, what is the fastest selector to retrieve on or another. -- Benjamin Sterling http://www.KenzoMedia.com http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
That's not a good example anyway. It's invalid because there can only be ONE unique ID per page. _ From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Heimlich Sent: Tuesday, June 12, 2007 7:32 PM To: jquery-en@googlegroups.com Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite On 6/12/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote: Plus, what happens if you have: div id=bam / span id=bam / What if you need to retrieve the span tag? If it's checking #bam first, won't it only find the div / element? The DOM2 has this to say: getElementById introduced in DOM Level 2 Returns the Element whose ID is given by elementId. If no such element exists, returns null. Behavior is not defined if more than one element has this ID. Source: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId I would think that the first one the browser finds is selected, but I can't be certain of that as I've never actually tried to do this. -- Aaron Heimlich Web Developer [EMAIL PROTECTED] http://aheimlich.freepgs.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
I've tested it with v1.1.3 and the improvements are enough to make a substantial difference. Rey David Duymelinck wrote: Gilles (Webunity) schreef: I agree with Glenn on this one. I vote for more speed, we need to fight back. Another 5k doesn't matter that much to me or my clients since all of them have caching on. Maybe an extra plugin? I thought John announced speed enchantments in 1.1.3. Is there someone who benchmarked the test release already? I would like to work with a speedy library too but i stay for the syntax and plugins :) I agree with the fact that 20 shouldn't be an absolute figure. -- BrightLight Development, LLC. 954-775- (o) 954-600-2726 (c) [EMAIL PROTECTED] http://www.iambright.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Hi Benjamin,
In this case, these are faster ...
$('div.bam')
$('span.bam')
than this ...
$('.bam')
What I don't know is whether $('div.bam, span.bam') is faster than $
('.bam'). I suspect that it might depend on the what the DOM looks
like on a given page.
--Karl
_
Karl Swedberg
www.englishrules.com
www.learningjquery.com
On Jun 13, 2007, at 8:15 AM, Benjamin Sterling wrote:
I hear what everyone is saying about IDs, but lets flip the switch
here and what if we have:
div class=bam
span class=bam
This situation is a valid situation, one I normally am in (actually
in a link situation). So, what is the fastest selector to retrieve
on or another.
--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Karl,
Thanks, I am going to try to put together a real life example and test out
what is faster. I will try to have something by end of week.
Thanks again.
On 6/13/07, Karl Swedberg [EMAIL PROTECTED] wrote:
Hi Benjamin,
In this case, these are faster ...
$('div.bam')
$('span.bam')
than this ...
$('.bam')
What I don't know is whether $('div.bam, span.bam') is faster than
$('.bam'). I suspect that it might depend on the what the DOM looks like on
a given page.
--Karl
_
Karl Swedberg
www.englishrules.com
www.learningjquery.com
On Jun 13, 2007, at 8:15 AM, Benjamin Sterling wrote:
I hear what everyone is saying about IDs, but lets flip the switch here
and what if we have:
div class=bam
span class=bam
This situation is a valid situation, one I normally am in (actually in a
link situation). So, what is the fastest selector to retrieve on or
another.
--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com
--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
We'll expect something by the end of the day today.
Get on that okay?
;)
_
From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Benjamin Sterling
Sent: Wednesday, June 13, 2007 8:27 AM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite
Karl,
Thanks, I am going to try to put together a real life example and test out
what is faster. I will try to have something by end of week.
Thanks again.
On 6/13/07, Karl Swedberg [EMAIL PROTECTED] wrote:
Hi Benjamin,
In this case, these are faster ...
$('div.bam')
$('span.bam')
than this ...
$('.bam')
What I don't know is whether $('div.bam, span.bam') is faster than
$('.bam'). I suspect that it might depend on the what the DOM looks like on
a given page.
--Karl
_
Karl Swedberg
www.englishrules.com
www.learningjquery.com
On Jun 13, 2007, at 8:15 AM, Benjamin Sterling wrote:
I hear what everyone is saying about IDs, but lets flip the switch here and
what if we have:
div class=bam
span class=bam
This situation is a valid situation, one I normally am in (actually in a
link situation). So, what is the fastest selector to retrieve on or
another.
--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com
--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Too much pressure, I crack easily. :)
On 6/13/07, Andy Matthews [EMAIL PROTECTED] wrote:
We'll expect something by the end of the day today.
Get on that okay?
;)
--
*From:* jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] *On
Behalf Of *Benjamin Sterling
*Sent:* Wednesday, June 13, 2007 8:27 AM
*To:* jquery-en@googlegroups.com
*Subject:* [jQuery] Re: SlickSpeed CSS Selector TestSuite
Karl,
Thanks, I am going to try to put together a real life example and test out
what is faster. I will try to have something by end of week.
Thanks again.
On 6/13/07, Karl Swedberg [EMAIL PROTECTED] wrote:
Hi Benjamin,
In this case, these are faster ...
$('div.bam')
$('span.bam')
than this ...
$('.bam')
What I don't know is whether $('div.bam, span.bam') is faster than
$('.bam'). I suspect that it might depend on the what the DOM looks like on
a given page.
--Karl
_
Karl Swedberg
www.englishrules.com
www.learningjquery.com
On Jun 13, 2007, at 8:15 AM, Benjamin Sterling wrote:
I hear what everyone is saying about IDs, but lets flip the switch here
and what if we have:
div class=bam
span class=bam
This situation is a valid situation, one I normally am in (actually in a
link situation). So, what is the fastest selector to retrieve on or
another.
--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com
--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com
--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Benjamin,
I have a scheduling program with three months worth of calendars on
screen. I build the calendars empty on the server side, and then
populate them with javascript. Each calendar was a table and I was
storing information on each td like, what date was represented,
whether the cell was selected, and a couple of other things.
Now, I still just quite a bit of jQuery on the page, but I'm not always
searching the DOM for information, I've got a couple of structures
(objects), that I search through now for certain information and it sped
up a fair amount. However, I really should take a close look at this
app, and maybe rewrite it from scratch, because it still doesn't pop the
way it should. In fact, it's quite slow. I'm sure there's plenty that
I'm doing wrong with it.
Chris
Benjamin Sterling wrote:
I switched to a different methodology and it sped up
Can you explain what you did? I try to give a full path to an item, ie:
div id=car
div class=part/div
/div
$('div#car div.part')
This may be off topic a bit, but I do believe we should educate people
on the fastest way to select an object.
--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com
--
http://www.cjordan.us
[jQuery] Re: SlickSpeed CSS Selector TestSuite
I vote for smaller footprint... I also think its quite harsh people making their own settled opinions on what the file size should be... I believe it should be as small as possible, not 'sub 100k', or sub '50k' - I heard comments from JS developers already saying 23k is a lot... as a front end developer I see it as a reasonable cost as long as the improvements are seen and or used. In my humble opinion if it was 50k, twice its current size, to settle some speed reports I would stick to using the old version - even upping it to 30k would seem rash in my humble opinion - I believe most speed issues could be addressed by better pathing or syntax considerations. Dont forget http://www.dallaway.com/sloppy/ if you have forgotten what 56k or even ISDN is like... if you want integrity you want gracefulness however your site is accessed. Saying all this, for sites that do require speed as priority and can suffer downloading an additional file maybe a plugin would settle the issue? I love jQuery :¬) -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Gilles (Webunity) Sent: 13 June 2007 10:01 To: jQuery (English) Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite I agree with Glenn on this one. I vote for more speed, we need to fight back. Another 5k doesn't matter that much to me or my clients since all of them have caching on. Maybe an extra plugin?
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Toby, that is a great link, thanks for sharing. Don't forget http://www.dallaway.com/sloppy/ if you have forgotten what 56k or even ISDN is like... if you want integrity you want gracefulness however your site is accessed. Saying all this, for sites that do require speed as priority and can suffer downloading an additional file maybe a plugin would settle the issue? -- Benjamin Sterling http://www.KenzoMedia.com http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
http://www.apple.com/safari/ File size 1.2 megs. If Toby worked on this website, I think he would spontaneously combust. Glen PS. Every page I visit on Apple seems to get bigger and bigger. On 6/13/07, Benjamin Sterling [EMAIL PROTECTED] wrote: Toby, that is a great link, thanks for sharing. Don't forget http://www.dallaway.com/sloppy/ if you have forgotten what 56k or even ISDN is like... if you want integrity you want gracefulness however your site is accessed. Saying all this, for sites that do require speed as priority and can suffer downloading an additional file maybe a plugin would settle the issue? -- Benjamin Sterling http://www.KenzoMedia.com http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
PS. Every page I visit on Apple seems to get bigger and bigger. They must be compensating for a lack of something. -- Benjamin Sterling http://www.KenzoMedia.com http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
It's by the people who won the testing, so that makes it just a little suspect. This is probably just like the testing from about 6 months back in which the jQuery library was several versions older than the most recent. That said, here's what I got: IE 7.0.57/PC - prototype 1.5.1 - 1879 jQuery 1.1.2dev - 3409 MooTools 1.2dev - 1623 ext 1.1b1 - 1206 cssQuery 2.02 - 8057 FF 2.0.0.4/PC - prototype 1.5.1 - 267 jQuery 1.1.2dev - 6940 MooTools 1.2dev - 278 ext 1.1b1 - 1725 cssQuery 2.02 - 9514 Regardless, it appears to be a nice test suite. -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Bil Corry Sent: Tuesday, June 12, 2007 8:49 AM To: jquery-en@googlegroups.com Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite Bil Corry wrote on 6/12/2007 6:43 AM: - SlickSpeed is a CSS selector test suite provided by the MooTools folk. This tool comes at the same time as they release CSS3 support in Mootools, and it compares Prototype, jQuery, MooTools, Ext, and CSS Query. http://ajaxian.com/archives/slickspeed-css-selector-testsuite - Opps, meant to post the results I got: MooTools 1.2dev: 208 ms prototype 1.5.1: 231 ms ext 1.1b1:1385 ms jQuery 1.1.2dev: 5678 ms -- jQuery! cssQuery 2.02:6995 ms - Bil
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Andy Matthews schrieb: It's by the people who won the testing, so that makes it just a little suspect. This is probably just like the testing from about 6 months back in which the jQuery library was several versions older than the most recent. That said, here's what I got: IE 7.0.57/PC - prototype 1.5.1 - 1879 jQuery 1.1.2dev - 3409 MooTools 1.2dev - 1623 ext 1.1b1 - 1206 cssQuery 2.02 - 8057 FF 2.0.0.4/PC - prototype 1.5.1 - 267 jQuery 1.1.2dev - 6940 MooTools 1.2dev - 278 ext 1.1b1 - 1725 cssQuery 2.02 - 9514 my results: FF 2.0.0.4 WinXP-SP2 http://onenterframe.de/temp/ micha
[jQuery] Re: SlickSpeed CSS Selector TestSuite
It's crazy how much faster Prototype, MooTools and ext are. -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Michael Stuhr Sent: Tuesday, June 12, 2007 9:14 AM To: jquery-en@googlegroups.com Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite Andy Matthews schrieb: It's by the people who won the testing, so that makes it just a little suspect. This is probably just like the testing from about 6 months back in which the jQuery library was several versions older than the most recent. That said, here's what I got: IE 7.0.57/PC - prototype 1.5.1 - 1879 jQuery 1.1.2dev - 3409 MooTools 1.2dev - 1623 ext 1.1b1 - 1206 cssQuery 2.02 - 8057 FF 2.0.0.4/PC - prototype 1.5.1 - 267 jQuery 1.1.2dev - 6940 MooTools 1.2dev - 278 ext 1.1b1 - 1725 cssQuery 2.02 - 9514 my results: FF 2.0.0.4 WinXP-SP2 http://onenterframe.de/temp/ micha
[jQuery] Re: SlickSpeed CSS Selector TestSuite
One of the reasons that these libraries have made substantial improvements has been that jQuery has lead the pack in terms of innovation and our efforts have motivated them to finally improve their frameworks. Prototype is probably the best example of this, having been forced to finally formalize the project after sitting in limbo for almost a year, add chaining and even improve its DOM querying. With that said, its definitely our turn to get things ramped up but we're kind of in a quandary. See, one of the benefits of jQuery is its very small file size. We're still the smallest library out there and our overall functionality is on par with any of the ones listed. In terms of overall ease of use, I still think we're the leader. But in keeping a small size we're limited in how much tweaking can be done. Neither PT, Ext or Moo have limitations on file size so they have the flexibility to add much more code to enhance their speed than we do. Our core team certainly has the talent to greatly enhance the selector speeds but we want to continue to provide a nice, small package. So at the end of the day, it comes down to this: - We can increase selector speeds at the expense of file size or - We can continue to focus on providing tight code in a small package and take what is arguably a small hit in speed The reason I say arguably is because unless you're manipulating a HUGE amount of selectors, I'm not sure how much of a visual difference you would see. I know this has been discussed before and that was pretty much the consensus (ie: small # of selectors, no big deal. Large # of selectors, possible concern). Considering that we are, IMO, the project thats most in tune with its community, your feedback is definitely most welcome. Rey... Bil Corry wrote: Bil Corry wrote on 6/12/2007 6:43 AM: - SlickSpeed is a CSS selector test suite provided by the MooTools folk. This tool comes at the same time as they release CSS3 support in Mootools, and it compares Prototype, jQuery, MooTools, Ext, and CSS Query. http://ajaxian.com/archives/slickspeed-css-selector-testsuite - Opps, meant to post the results I got: MooTools 1.2dev: 208 ms prototype 1.5.1: 231 ms ext 1.1b1:1385 ms jQuery 1.1.2dev: 5678 ms -- jQuery! cssQuery 2.02:6995 ms - Bil -- BrightLight Development, LLC. 954-775- (o) 954-600-2726 (c) [EMAIL PROTECTED] http://www.iambright.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Michael Stuhr wrote: my results: FF 2.0.0.4 WinXP-SP2 http://onenterframe.de/temp/ micha Is Jquery slower because it's more compact then? ie. better for light usage? I much prefer the syntax and the community around jquery. I never got any helpful responses from anyone on the mootools forum when I was using that library. Rob
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Don't we have a plugin which might allay some of the speed concerns? I'm LOVING the fact that jQuery is 19k, BUT even if it were to bump up to 25k or 30k, it would STILL be the smallest overall library. And honestly, these days, people spend 100k just on one IMAGE, which doesn't even provide any functionality. I'd say that increasing the library size up to 10k would be an acceptable compromise to get increased speed and flexibility. Thoughts? -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Rey Bango Sent: Tuesday, June 12, 2007 9:25 AM To: jquery-en@googlegroups.com Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite One of the reasons that these libraries have made substantial improvements has been that jQuery has lead the pack in terms of innovation and our efforts have motivated them to finally improve their frameworks. Prototype is probably the best example of this, having been forced to finally formalize the project after sitting in limbo for almost a year, add chaining and even improve its DOM querying. With that said, its definitely our turn to get things ramped up but we're kind of in a quandary. See, one of the benefits of jQuery is its very small file size. We're still the smallest library out there and our overall functionality is on par with any of the ones listed. In terms of overall ease of use, I still think we're the leader. But in keeping a small size we're limited in how much tweaking can be done. Neither PT, Ext or Moo have limitations on file size so they have the flexibility to add much more code to enhance their speed than we do. Our core team certainly has the talent to greatly enhance the selector speeds but we want to continue to provide a nice, small package. So at the end of the day, it comes down to this: - We can increase selector speeds at the expense of file size or - We can continue to focus on providing tight code in a small package and take what is arguably a small hit in speed The reason I say arguably is because unless you're manipulating a HUGE amount of selectors, I'm not sure how much of a visual difference you would see. I know this has been discussed before and that was pretty much the consensus (ie: small # of selectors, no big deal. Large # of selectors, possible concern). Considering that we are, IMO, the project thats most in tune with its community, your feedback is definitely most welcome. Rey... Bil Corry wrote: Bil Corry wrote on 6/12/2007 6:43 AM: - SlickSpeed is a CSS selector test suite provided by the MooTools folk. This tool comes at the same time as they release CSS3 support in Mootools, and it compares Prototype, jQuery, MooTools, Ext, and CSS Query. http://ajaxian.com/archives/slickspeed-css-selector-testsuite - Opps, meant to post the results I got: MooTools 1.2dev: 208 ms prototype 1.5.1: 231 ms ext 1.1b1:1385 ms jQuery 1.1.2dev: 5678 ms -- jQuery! cssQuery 2.02:6995 ms - Bil -- BrightLight Development, LLC. 954-775- (o) 954-600-2726 (c) [EMAIL PROTECTED] http://www.iambright.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Well here is my personal (and widely uneducated) opinion on this speed test. First what I think is good about it: * each framework get's it's own iframe - avoid conflicts between them * the test itself is written without using a framework What I think is bad about it: * There are 3 nth-child(x*n)-style tests that jQuery seems to choke on as those selectors are not implemented in 1.1.2 (correct me if I'm wrong). On my machine this equates in 617ms (20 %) of jQuery's total test time (2857ms) * The div ~ div selector seems to take jQuery really long to perform, 1125ms (43%) go into it * The div:only-child + div:contains selector seem to be slow in jQuery and 203ms total (12%) go into them What does this mean? It means that jQuery is nowhere as slow as the final test results make it appear (26x slower then mootools). It means that mootools got the performance lead in some specific selector (and does good in general) which is given way too much weight by the test itself. I'm also questioning how far one can even go in terms of benchmarking selector engines. I mean everybody has different needs. Most of the time I use very simple selectors which jQuery does very fast according to the test. So I'd actually be willing to loose performance on the more complicated selectors if that allows the more common ones to run faster. What's missing in my eyes is a survey or analysis of common selector usage that could be used to weigh in the different selector results. That being said I'm not trying to say jQuery is actually the fastest library and the evil test just made it look bad. I'm sure there is room for improvements and who knows what 1.1.3 will bring. But what I'm trying to communicate is that it's not an easy job to actually interpret the results coming from those speed tests and hence one should be very careful when using them to make a point for one lib being faster then another. -- Felix Geisendörfer aka the_undefined -- http://www.thinkingphp.org http://www.fg-webdesign.de Robert O'Rourke wrote: Michael Stuhr wrote: my results: FF 2.0.0.4 WinXP-SP2 http://onenterframe.de/temp/ micha Is Jquery slower because it's more compact then? ie. better for light usage? I much prefer the syntax and the community around jquery. I never got any helpful responses from anyone on the mootools forum when I was using that library. Rob
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Great post, Felix! Very well said. What does this mean? It means that jQuery is nowhere as slow as the final test results make it appear (26x slower then mootools). It means that mootools got the performance lead in some specific selector (and does good in general) which is given way too much weight by the test itself. I'm also questioning how far one can even go in terms of benchmarking selector engines. I mean everybody has different needs. Most of the time I use very simple selectors which jQuery does very fast according to the test. So I'd actually be willing to loose performance on the more complicated selectors if that allows the more common ones to run faster. What's missing in my eyes is a survey or analysis of common selector usage that could be used to weigh in the different selector results.
[jQuery] Re: SlickSpeed CSS Selector TestSuite
I agree. I don't want to see jQuery get bloated, but if it was between the two options of Keep it 20kb but slower or Go to 25-30kb and get major improvements I'd vote for number two. I'd only go for number one if there was really going to be little improvement to any of the changes. One of the great things for me about jQuery is the shear number of plugins that add functionality, rather than putting them in the core. I think more needs to be made of that fact, rather than Prototype's Lets put everything in one file philosophy. And the jQuery MVC - Jamal - interests me too. I'm a CakePHP developer, and I'd love to start applying the same principles that I use in that to my jQuery code. But I don't want the bloat of say Dojo or Freja. On 6/12/07, Su [EMAIL PROTECTED] wrote: On 6/12/07, Rey Bango [EMAIL PROTECTED] wrote: - We can increase selector speeds at the expense of file size How about looking at this specifically a little closer? It's already been pointed out that jQuery could get a lot bigger and /still/ remain the smallest library. So, the question is why 20k? I'm not saying damn the filesize, but let's just say that some test comes out which does illustrated a /significant/ deficiency which is being brought about by the filesize restriction. What would the argument then be for staying at 20k? Is the goal keep the library small or keep the library at 20k? And if the latter, what is the basis for that number? -- Tane Piper http://webrocket.wordpress.com This email is: [ ] blogable [ x ] ask first [ ] private
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Rey Bango wrote: Hi Robert, Thats precisely the reason that its slower. We continue to work on providing the most comprehensive functionality in the smallest package. This is one of the drawbacks of that approach. Rey... Robert O'Rourke wrote: Is Jquery slower because it's more compact then? ie. better for light usage? I much prefer the syntax and the community around jquery. I never got any helpful responses from anyone on the mootools forum when I was using that library. Righto, cheers Rey. I'm definitely sticking with jquery as a tool of choice but I wonder, seeing as how mootools is modular couldn't someone just take that selector code snippet and write a plugin to make it spit out the jquery object? Rob
[jQuery] Re: SlickSpeed CSS Selector TestSuite
This topic comes up every time a speed test emerges. To me, speed is totally irrelevant in most circumstances that I use jQuery. Speed of Development is most important. if I can finish my job faster then the user will be happier. If they have to wait 1/10 of a second longer, they will not be heart broken. These tests are geeky comparisons of technical detail that is irrelevant to human beings. It's like video card comparisons that talk about speed of polygonal shading textures per billionth of a second. Apple just redesigned their site. On the inside they use Scriptaculous/Prorotype. Check http://www.apple.com/mac. Notice the file size, 772k! That is humongous. Does it matter what the script is at that point? So with that said, although I do like jQuery small, I don't think it makes a difference whether its 20k or 50k. In the tradeoff's, I think you need to find out how much major improvements in speed will really cost? Is it really 10k more? Can it be a plugin? I have no idea. I am just saying, I am not concerned with file size up to 50k. My only concern is about ease of use and maintainability. As long as jQuery has that, then all these tests miss the point. Glen On 6/12/07, Robert O'Rourke [EMAIL PROTECTED] wrote: Rey Bango wrote: Hi Robert, Thats precisely the reason that its slower. We continue to work on providing the most comprehensive functionality in the smallest package. This is one of the drawbacks of that approach. Rey... Robert O'Rourke wrote: Is Jquery slower because it's more compact then? ie. better for light usage? I much prefer the syntax and the community around jquery. I never got any helpful responses from anyone on the mootools forum when I was using that library. Righto, cheers Rey. I'm definitely sticking with jquery as a tool of choice but I wonder, seeing as how mootools is modular couldn't someone just take that selector code snippet and write a plugin to make it spit out the jquery object? Rob
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Well said. That about sums it up for me. _ From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Glen Lipka Sent: Tuesday, June 12, 2007 11:08 AM To: jquery-en@googlegroups.com Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite This topic comes up every time a speed test emerges. To me, speed is totally irrelevant in most circumstances that I use jQuery. Speed of Development is most important. if I can finish my job faster then the user will be happier. If they have to wait 1/10 of a second longer, they will not be heart broken. These tests are geeky comparisons of technical detail that is irrelevant to human beings. It's like video card comparisons that talk about speed of polygonal shading textures per billionth of a second. Apple just redesigned their site. On the inside they use Scriptaculous/Prorotype. Check http://www.apple.com/mac. Notice the file size, 772k! That is humongous. Does it matter what the script is at that point? So with that said, although I do like jQuery small, I don't think it makes a difference whether its 20k or 50k. In the tradeoff's, I think you need to find out how much major improvements in speed will really cost? Is it really 10k more? Can it be a plugin? I have no idea. I am just saying, I am not concerned with file size up to 50k. My only concern is about ease of use and maintainability. As long as jQuery has that, then all these tests miss the point. Glen On 6/12/07, Robert O'Rourke [EMAIL PROTECTED] wrote: Rey Bango wrote: Hi Robert, Thats precisely the reason that its slower. We continue to work on providing the most comprehensive functionality in the smallest package. This is one of the drawbacks of that approach. Rey... Robert O'Rourke wrote: Is Jquery slower because it's more compact then? ie. better for light usage? I much prefer the syntax and the community around jquery. I never got any helpful responses from anyone on the mootools forum when I was using that library. Righto, cheers Rey. I'm definitely sticking with jquery as a tool of choice but I wonder, seeing as how mootools is modular couldn't someone just take that selector code snippet and write a plugin to make it spit out the jquery object? Rob
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Well said Glen. I would have to agree that these tests are for the most part totally irrelevant with regards to most usage. Anyways, I would still use jQuery even if it was 30k. That is still very small compared to a the image file sizes that are used in highly designed/styled web sites. I noticed the Apple site yesterday when downloading Safari for Windows. They finally dropped the tab navigation! It's about time. I was a little sad to see that they were using prototype when I looked under the hood. -Marshall Glen Lipka wrote: This topic comes up every time a speed test emerges. To me, speed is totally irrelevant in most circumstances that I use jQuery. Speed of Development is most important. if I can finish my job faster then the user will be happier. If they have to wait 1/10 of a second longer, they will not be heart broken. These tests are geeky comparisons of technical detail that is irrelevant to human beings. It's like video card comparisons that talk about speed of polygonal shading textures per billionth of a second. Apple just redesigned their site. On the inside they use Scriptaculous/Prorotype. Check http://www.apple.com/mac. Notice the file size, 772k! That is humongous. Does it matter what the script is at that point? So with that said, although I do like jQuery small, I don't think it makes a difference whether its 20k or 50k. In the tradeoff's, I think you need to find out how much "major improvements in speed" will really cost? Is it really 10k more? Can it be a plugin? I have no idea. I am just saying, I am not concerned with file size up to 50k. My only concern is about ease of use and maintainability. As long as jQuery has that, then all these tests miss the point. Glen On 6/12/07, Robert O'Rourke [EMAIL PROTECTED] wrote: Rey Bango wrote: Hi Robert, Thats precisely the reason that its slower. We continue to work on providing the most comprehensive functionality in the smallest package. This is one of the drawbacks of that approach. Rey... Robert O'Rourke wrote: Is Jquery slower because it's more compact then? ie. better for light usage? I much prefer the syntax and the community around jquery. I never got any helpful responses from anyone on the mootools forum when I was using that library. Righto, cheers Rey. I'm definitely sticking with jquery as a tool of choice but I wonder, seeing as how mootools is modular couldn't someone just take that selector code snippet and write a plugin to make it spit out the jquery object? Rob
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Glen Lipka wrote: This topic comes up every time a speed test emerges. To me, speed is totally irrelevant in most circumstances that I use jQuery. Speed of Development is most important. if I can finish my job faster then the user will be happier. If they have to wait 1/10 of a second longer, they will not be heart broken. These tests are geeky comparisons of technical detail that is irrelevant to human beings. It's like video card comparisons that talk about speed of polygonal shading textures per billionth of a second. Apple just redesigned their site. On the inside they use Scriptaculous/Prorotype. Check http://www.apple.com/mac. Notice the file size, 772k! That is humongous. Does it matter what the script is at that point? So with that said, although I do like jQuery small, I don't think it makes a difference whether its 20k or 50k. In the tradeoff's, I think you need to find out how much major improvements in speed will really cost? Is it really 10k more? Can it be a plugin? I have no idea. I am just saying, I am not concerned with file size up to 50k. My only concern is about ease of use and maintainability. As long as jQuery has that, then all these tests miss the point. Glen Agreed, I'm not that fussed because it's still plenty nippy and so much simpler for a newbite such as myself. Thats an obscene filesize for apples site! What percentage of people are actually on broadband these days? Or do they just not care anymore...
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Andy Matthews wrote: Well said. That about sums it up for me. Yes, I agree as well. The problem is that probably still people will draw the wrong conclusions from such tests. I have the feeling that library makers just use these tests to get draw attention. Thus its even more important to stress the philosophy behind jQuery. I'd really like to see a real life speed test... Certain selectors I have never ever used. -- Klaus
[jQuery] Re: SlickSpeed CSS Selector TestSuite
I would guess that most (at least a large percentage) of their target audience has broadband. -Original Message- From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Rourke Sent: Tuesday, June 12, 2007 11:56 AM To: jquery-en@googlegroups.com Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite Glen Lipka wrote: This topic comes up every time a speed test emerges. To me, speed is totally irrelevant in most circumstances that I use jQuery. Speed of Development is most important. if I can finish my job faster then the user will be happier. If they have to wait 1/10 of a second longer, they will not be heart broken. These tests are geeky comparisons of technical detail that is irrelevant to human beings. It's like video card comparisons that talk about speed of polygonal shading textures per billionth of a second. Apple just redesigned their site. On the inside they use Scriptaculous/Prorotype. Check http://www.apple.com/mac. Notice the file size, 772k! That is humongous. Does it matter what the script is at that point? So with that said, although I do like jQuery small, I don't think it makes a difference whether its 20k or 50k. In the tradeoff's, I think you need to find out how much major improvements in speed will really cost? Is it really 10k more? Can it be a plugin? I have no idea. I am just saying, I am not concerned with file size up to 50k. My only concern is about ease of use and maintainability. As long as jQuery has that, then all these tests miss the point. Glen Agreed, I'm not that fussed because it's still plenty nippy and so much simpler for a newbite such as myself. Thats an obscene filesize for apples site! What percentage of people are actually on broadband these days? Or do they just not care anymore...
[jQuery] Re: SlickSpeed CSS Selector TestSuite
A lot is being made of how small jQ is. From the quick check I did, jQ compressed is 5k smaller than Prototype, and MooTools with a quick selection of the functions that seem to be in jQ was 27k, only 10k more than jQ. Considering the library is typically downloaded once and then cached, 5-10k is negligible. File size is important, but not when we're already down in the single digits for differences. Even low double digit difference aren't that significant. At this range of difference the only reason file size makes a difference is perhaps in understanding/reading the library code -- I suspect that's not something that many people do anyway. What is important is the perception of things like speed tests. People will make a library decision by eliminating the slower running, larger sized, libraries, and will deifniately steer clear of libraries that seem to fail tests. If correcting and improving those things adds a few bytes, then jQ is foimproved. As others have said, 'soft-factors' like ease of use, maintainability, documentation (and ability to find and access the documentation), and community are the keys. However, being at the bottom of the pile in speed, file size, etc, will form a barrier of entry that may override the 'soft-factors'. ~ ~ Dave On Tue, 12 Jun 2007 09:08:25 -0700, 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. Speed of Development is most important. if I can finish my job faster then the user will be happier. If they have to wait 1/10 of a second longer, they will not be heart broken. These tests are geeky comparisons of technical detail that is irrelevant to human beings. It's like video card comparisons that talk about speed of polygonal shading textures per billionth of a second. Apple just redesigned their site. On the inside they use Scriptaculous/Prorotype. Check http://www.apple.com/mac. Notice the file size, 772k! That is humongous. Does it matter what the script is at that point? So with that said, although I do like jQuery small, I don't think it makes a difference whether its 20k or 50k. In the tradeoff's, I think you need to find out how much major improvements in speed will really cost? Is it really 10k more? Can it be a plugin? I have no idea. I am just saying, I am not concerned with file size up to 50k. My only concern is about ease of use and maintainability. As long as jQuery has that, then all these tests miss the point. Glen On 6/12/07, Robert O'Rourke [EMAIL PROTECTED] wrote: Rey Bango wrote: Hi Robert, Thats precisely the reason that its slower. We continue to work on providing the most comprehensive functionality in the smallest package. This is one of the drawbacks of that approach. Rey... Robert O'Rourke wrote: Is Jquery slower because it's more compact then? ie. better for light usage? I much prefer the syntax and the community around jquery. I never got any helpful responses from anyone on the mootools forum when I was using that library. Righto, cheers Rey. I'm definitely sticking with jquery as a tool of choice but I wonder, seeing as how mootools is modular couldn't someone just take that selector code snippet and write a plugin to make it spit out the jquery object? Rob
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Rey Bango wrote on 6/12/2007 7:25 AM: So at the end of the day, it comes down to this: - We can increase selector speeds at the expense of file size or - We can continue to focus on providing tight code in a small package and take what is arguably a small hit in speed Since most browsers cache the .js file on the first hit, wouldn't a small size only be most valuable on the first page? I'm wondering how much benefit is derived from a small file size beyond the first page hit. As for speed improvements, they provide value on every page, not just the first hit. So my vote would be for improving the speed at the expense of file size. - Bil
[jQuery] Re: SlickSpeed CSS Selector TestSuite
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.
[jQuery] Re: SlickSpeed CSS Selector TestSuite
-Original Message- From: Andy Matthews [mailto:[EMAIL PROTECTED] I would guess that most (at least a large percentage) of their target audience has broadband. Last weekend I was over a friends house with dial-up and I was amazed at how completely unusable the web was for me... Gmail, my local weather site, news - all took forever to load up... I no longer develop public facing sites - but if it's been awhile since you've tried surfing with a modem - I'd give it a try now and then just to remember what a majority of people are experiencing on the web... Sept 2006: http://www.consumeraffairs.com/news04/2006/09/jd_power_high_speed.html The study finds that 56 percent of residential ISP customers subscribe to high-speed Internet service -- an increase of 11 percentage points from 2005. So I'm guessing in 07 you are still looking at 40%+ using dialup. That said - I'd vote for smaller file sizes... Jim There is more to life than simply increasing its speed. ~Gandhi
[jQuery] Re: SlickSpeed CSS Selector TestSuite
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.
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Someone once said to me this will be a moot point by 2008 - but I totally disagreed with them. Yes countries like the UK, USA, Canada and Japan may have 80% coverage and 50% subscription rates, but in these countries as you say there are still a large proportion of users on dialup. Many people here in UK cannot get speeds of 2Mbps (now considered the minimum broadband level) - I'm lucky if I hit 4Mbps on my line, and my work is still on a 1Mbps ADSL line shared between the whole office of 15 people. And don't even get me started on the emerging markets in Africa and South America.. I've was taught that a start page should be no larger than 500kb in size, and for Apple to have 700k in just JS, that's just silly. And to top it off...Apple have released Safari on Windows - yet another browser to saturate an already crowded market where no one browser is standards complant and it just makes more work for us developers. Anyway, my point I'm making is that jQuery is almost perfect as it is, and I wouldn't want it to be bloated, but there is leaway to increase its size a little and still be able to provide highly optimised sites. If jQuery is one of the slowest libraries out there, then it SHOULD be optimised - newcomers are going to look at there figures and make a decision on it - good or bad. But by providing the middle ground of maybe being one of the faster ones but still being smaller than fastest lib, then maybe more people will consider using it. My 2p On 6/12/07, Priest, James (NIH/NIEHS) [C] [EMAIL PROTECTED] wrote: -Original Message- From: Andy Matthews [mailto:[EMAIL PROTECTED] I would guess that most (at least a large percentage) of their target audience has broadband. Last weekend I was over a friends house with dial-up and I was amazed at how completely unusable the web was for me... Gmail, my local weather site, news - all took forever to load up... I no longer develop public facing sites - but if it's been awhile since you've tried surfing with a modem - I'd give it a try now and then just to remember what a majority of people are experiencing on the web... Sept 2006: http://www.consumeraffairs.com/news04/2006/09/jd_power_high_speed.html The study finds that 56 percent of residential ISP customers subscribe to high-speed Internet service -- an increase of 11 percentage points from 2005. So I'm guessing in 07 you are still looking at 40%+ using dialup. That said - I'd vote for smaller file sizes... Jim There is more to life than simply increasing its speed. ~Gandhi -- Tane Piper http://webrocket.wordpress.com This email is: [ ] blogable [ x ] ask first [ ] private
[jQuery] Re: SlickSpeed CSS Selector TestSuite
I hear a lot of discussion about how jQuery isn't that slow, the test wasn't perfectly fair (what test is?), that keeping code small is important, and that development time is the most important thing. 1) Lots of people take speed tests seriously, even if they're not a good way to judge a libraries use. 2) Making jQuery faster doesn't mean it has to be bigger in size, only more clever. 3) Development time is important, but so are viewer's patience. Slow code is never good. 4) People's perception of a jQuery is what will ultimately decide it's fame. I've seen jQuery on the slow end of lots of speed tests. Even if there are good reasons for it being slow, we should strive to make it faster. ~Sean
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Sean Catchpole wrote: 2) Making jQuery faster doesn't mean it has to be bigger in size, only more clever. Well, at some point there are boundaries and it has to become bigger. For example if using native XPath support in certain browsers is the only way to speed it up. --Klaus
[jQuery] Re: SlickSpeed CSS Selector TestSuite
it totaly agree. And about the Dimensions plugin: a lot of other plugins use their own (not so good) implementation of the functionality the Dimensions plugin provide. On 12 jun, 20:22, Glen Lipka [EMAIL PROTECTED] wrote: 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?)
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Sean Catchpole wrote: I hear a lot of discussion about how jQuery isn't that slow, the test wasn't perfectly fair (what test is?), that keeping code small is important, and that development time is the most important thing. 1) Lots of people take speed tests seriously, even if they're not a good way to judge a libraries use. I agree 100% 2) Making jQuery faster doesn't mean it has to be bigger in size, only more clever. I can't really speak to this one. 3) Development time is important, but so are viewer's patience. Slow code is never good. *Absolutely!* I could not agree more. I had a page where I was using a bunch of selectors, and it was just plain slow. I switched to a different methodology and it sped up (some... I think there are still problems with my code on that page... but that's another topic :o) I would like to see jQuery's speed improve. I don't want a bloated core, but if the library stays relatively small (I know very subjective) say, under 100K that wouldn't be too bad. Would it? Chris -- http://www.cjordan.us
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Ok, Apple engineers are seriously a few kilobytes short of meg. Check out the file size of http://www.apple.com/itunes/ Compressed its 878k. But look why. They are using the uncompressed, unminified, totally commented versions of prototype and scriptaculous. Nothing is minified, much less packed. AND, they are not using GZIP on the scripts either. Now, most users never know this sort of thing. But, come on, is a little craftsmanship that difficult? One bad Apple spoils the bunch. Glen On 6/12/07, Christopher Jordan [EMAIL PROTECTED] wrote: Sean Catchpole wrote: I hear a lot of discussion about how jQuery isn't that slow, the test wasn't perfectly fair (what test is?), that keeping code small is important, and that development time is the most important thing. 1) Lots of people take speed tests seriously, even if they're not a good way to judge a libraries use. I agree 100% 2) Making jQuery faster doesn't mean it has to be bigger in size, only more clever. I can't really speak to this one. 3) Development time is important, but so are viewer's patience. Slow code is never good. *Absolutely!* I could not agree more. I had a page where I was using a bunch of selectors, and it was just plain slow. I switched to a different methodology and it sped up (some... I think there are still problems with my code on that page... but that's another topic :o) I would like to see jQuery's speed improve. I don't want a bloated core, but if the library stays relatively small (I know very subjective) say, under 100K that wouldn't be too bad. Would it? Chris -- http://www.cjordan.us
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Someone should let them know...that's just assinine. _ From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Glen Lipka Sent: Tuesday, June 12, 2007 4:26 PM To: jquery-en@googlegroups.com Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite Ok, Apple engineers are seriously a few kilobytes short of meg. Check out the file size of http://www.apple.com/itunes/ Compressed its 878k. But look why. They are using the uncompressed, unminified, totally commented versions of prototype and scriptaculous. Nothing is minified, much less packed. AND, they are not using GZIP on the scripts either. Now, most users never know this sort of thing. But, come on, is a little craftsmanship that difficult? One bad Apple spoils the bunch. Glen On 6/12/07, Christopher Jordan [EMAIL PROTECTED] wrote: Sean Catchpole wrote: I hear a lot of discussion about how jQuery isn't that slow, the test wasn't perfectly fair (what test is?), that keeping code small is important, and that development time is the most important thing. 1) Lots of people take speed tests seriously, even if they're not a good way to judge a libraries use. I agree 100% 2) Making jQuery faster doesn't mean it has to be bigger in size, only more clever. I can't really speak to this one. 3) Development time is important, but so are viewer's patience. Slow code is never good. *Absolutely!* I could not agree more. I had a page where I was using a bunch of selectors, and it was just plain slow. I switched to a different methodology and it sped up (some... I think there are still problems with my code on that page... but that's another topic :o) I would like to see jQuery's speed improve. I don't want a bloated core, but if the library stays relatively small (I know very subjective) say, under 100K that wouldn't be too bad. Would it? Chris -- http://www.cjordan.us
[jQuery] Re: SlickSpeed CSS Selector TestSuite
I switched to a different methodology and it sped up
Can you explain what you did? I try to give a full path to an item, ie:
div id=car
div class=part/div
/div
$('div#car div.part')
This may be off topic a bit, but I do believe we should educate people on
the fastest way to select an object.
--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
One bad Apple spoils the bunch. I think there's a Donnie Osmond joke in there somewhere...
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Benjamin,
I switched to a different methodology and it sped up
Can you explain what you did? I try to give a full path to an item, ie:
div id=car
div class=part/div
/div
$('div#car div.part')
This may be off topic a bit, but I do believe we should educate people on
the fastest way to select an object.
More information isn't always better. I'm just going to break down the first
part.
Saying div#car is literally saying find me all div tags, where the id
is car. To do that, we have to first get find all DIV tags and then figure
out which one has an id of car.
A much more efficient method is just using #car--which says go get me the
element who's ID is car. The browser has a native method for getting this
and this is very fast an efficient.
-Dan
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Really? hmmm... guess there a some code a need to change. A much more efficient method is just using #car--which says go get me the element who's ID is car. The browser has a native method for getting this and this is very fast an efficient. -- Benjamin Sterling http://www.KenzoMedia.com http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Hi Sean, 1) Lots of people take speed tests seriously, even if they're not a good way to judge a libraries use. Absolutely true Sean. 2) Making jQuery faster doesn't mean it has to be bigger in size, only more clever. Actually that's not 100% true. As Klaus mentioned, there are boundaries that you will hit where maintaining a small file size needs to be sacrificed in order to achieve greater performance. The core team has looked seriously into this, especially in light of all of the speed tests. For example, you take DomQuery from the Ext project, which at one point was the fastest selector engine out, and its 9K minimized by itself. Thats 9k without all of the extra EXT functionality. 3) Development time is important, but so are viewer's patience. Slow code is never good. The thing is that in reality, jQuery isn't slow. Unfortunately, these tests paint a picture that really doesn't match reality. I have yet to see anyone provide a real-world example where jQuery is so slow at DOM manipulation that the user experience is unbearable (or anywhere near that). 4) People's perception of a jQuery is what will ultimately decide it's fame. This describes the results better than point #3. The perception, based on these tests, could certainly sway someone from using jQuery even when there's not necessarily a problem. Rey...
[jQuery] Re: SlickSpeed CSS Selector TestSuite
That is what I thought, especially after reading (I thought it was on learningjquery.com, but could not find it) an article a couple months back. Maybe someone can put together a Best Practices article. That's the way it worked pre 1.1. Now, it's get #car and check if it's a div. -- Benjamin Sterling http://www.KenzoMedia.com http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
On 6/12/07, Benjamin Sterling [EMAIL PROTECTED] wrote: (I thought it was on learningjquery.com, but could not find it) an article a couple months back. Could you be thinking of http://aheimlich.freepgs.com/javascript/jquery-11-selector-speeds (server seems to be a bit funky today, so watch out). -- Aaron Heimlich Web Developer [EMAIL PROTECTED] http://aheimlich.freepgs.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
I think maybe he was referring to this one:
http://www.learningjquery.com/2006/12/quick-tip-optimizing-dom-traversal
As someone else already mentioned, the part about how it finds
something like $('div#foo') is no longer true (as of 1.1), but the
general principles are still relevant, I think.
It has a link to a speed test I threw together, and also to Aaron's
enhancement. There was a further enhancement somewhere -- I think a
subdomain of jquery.com -- at some point, but don't know if it's
still there, especially after the ddos attack.
I've enjoyed reading the discussion about selector speeds and file size.
--Karl
_
Karl Swedberg
www.englishrules.com
www.learningjquery.com
On Jun 12, 2007, at 6:40 PM, Aaron Heimlich wrote:
On 6/12/07, Benjamin Sterling [EMAIL PROTECTED]
wrote:
(I thought it was on learningjquery.com, but could not find it) an
article a couple months back.
Could you be thinking of http://aheimlich.freepgs.com/javascript/
jquery-11-selector-speeds (server seems to be a bit funky today, so
watch out).
--
Aaron Heimlich
Web Developer
[EMAIL PROTECTED]
http://aheimlich.freepgs.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
On 6/12/07, Karl Swedberg [EMAIL PROTECTED] wrote: It has a link to a speed test I threw together, and also to Aaron's enhancement. Just so nobody's confused, Karl's link[1] and my Firebug-enhanced speed test[2] both deal with jQuery 1.0, not 1.1. I have yet to upgrade my Firebug-enhanced test to jQuery 1.1. [1] http://www.learningjquery.com/2006/12/quick-tip-optimizing-dom-traversal [2] http://aheimlich.freepgs.com/tests/jquery/speed-test-firebug/ -- Aaron Heimlich Web Developer [EMAIL PROTECTED] http://aheimlich.freepgs.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Oh yeah. thanks a lot for pointing that out, Aaron. By the way, does anyone know which page the slickspeed test is run on (http://mootools.net/slickspeed/) ? I can't find any of the actual elements on the page itself. It's funny, though, that from the looks of the window.selectors array [1], they're using the same page I threw together back in December, which in retrospect was probably a dumb choice on my part, because it doesn't exactly represent a typical page on a corporate site or blog or anything else really. I just grabbed a portion of Shakespeare's As You Like It (an excerpt of Act I, Scene III, in case anyone else out there is a literature buff. :) ) and marked it up with HTML. Oh well, chalk it up to the folly of youth. I do think, however, that someone should come up with a better test page for these speed tests, especially if people are going to use them to compare the various libraries and take the results so seriously. [1] window.selectors = ['*','div:only-child','div:contains (CELIA)','div:nth-child(even)','div:nth-child(2n)','div:nth-child (odd)','div:nth-child(2n+1)','div:nth-child(n)','div:last- child','div:first-child','div div','div + div','div ~ div','body','body div','div','div div','div div div','div, div, div','div, a, span','.dialog','div.dialog','div .dialog','div.character, div.dialog','#speech5','div#speech5','div #speech5','div.scene div.dialog','div#scene1 div.dialog div','#scene1 #speech1','div[% class]','div[%class=dialog]','div[%class^=dia]','div[%class $=log]','div[%class*=sce]','div[%class|=dialog]','div[%class! =madeup]','div[%class~=dialog]'] --Karl _ Karl Swedberg www.englishrules.com www.learningjquery.com On Jun 12, 2007, at 7:09 PM, Aaron Heimlich wrote: On 6/12/07, Karl Swedberg [EMAIL PROTECTED] wrote: It has a link to a speed test I threw together, and also to Aaron's enhancement. Just so nobody's confused, Karl's link[1] and my Firebug-enhanced speed test[2] both deal with jQuery 1.0, not 1.1. I have yet to upgrade my Firebug-enhanced test to jQuery 1.1. [1] http://www.learningjquery.com/2006/12/quick-tip-optimizing-dom- traversal [2] http://aheimlich.freepgs.com/tests/jquery/speed-test-firebug/ -- Aaron Heimlich Web Developer [EMAIL PROTECTED] http://aheimlich.freepgs.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Karl, By the way, does anyone know which page the slickspeed test is run on ( http://mootools.net/slickspeed/) ? I can't find any of the actual elements on the page itself. Not sure if I understand your question correctly, but they are using iframes for each framework. ... I do think, however, that someone should come up with a better test page for these speed tests, especially if people are going to use them to compare the various libraries and take the results so seriously. I totally agree, I would suggest taking a top ranked site, maybe microsoft.com, and setting up a test geared for that site. -- Benjamin Sterling http://www.KenzoMedia.com http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Saying div#car is literally saying find me all div tags, where the id is car. To do that, we have to first get find all DIV tags and then figure out which one has an id of car. That's the way it worked pre 1.1. Now, it's get #car and check if it's a div. I actually thought that was the case now, but it's still faster not to perform additional checks if not needed. Plus, what happens if you have: div id=bam / span id=bam / What if you need to retrieve the span tag? If it's checking #bam first, won't it only find the div / element? (And yes, I know the HTML spec says that IDs should be unique, but occasionally you're dealing w/dynamically generated server content that's out of your control.) -Dan
[jQuery] Re: SlickSpeed CSS Selector TestSuite
div id=bam /
span id=bam /
What if you need to retrieve the span tag? If it's checking #bam first,
won't it only find the div / element?
But that is my thinking of why $('span#bam') would be faster then just
$('bam').
(And yes, I know the HTML spec says that IDs should be unique, but
occasionally you're dealing w/dynamically generated server content that's
out of your control.)
In that case, when I generate dynamically I append the id with the unique
id of the record.
--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
On 6/12/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote: Plus, what happens if you have: div id=bam / span id=bam / What if you need to retrieve the span tag? If it's checking #bam first, won't it only find the div / element? The DOM2 has this to say: getElementById introduced in DOM Level 2 Returns the Element whose ID is given by elementId. If no such element exists, returns null. Behavior is not defined if more than one element has this ID. Source: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId I would think that the first one the browser finds is selected, but I can't be certain of that as I've never actually tried to do this. -- Aaron Heimlich Web Developer [EMAIL PROTECTED] http://aheimlich.freepgs.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Yes, getElementById returns the first one found, i.e. the first one in the dom, if there are multiple nodes with the same id. On 6/12/07, Aaron Heimlich [EMAIL PROTECTED] wrote: On 6/12/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote: Plus, what happens if you have: div id=bam / span id=bam / What if you need to retrieve the span tag? If it's checking #bam first, won't it only find the div / element? The DOM2 has this to say: getElementById introduced in DOM Level 2 Returns the Element whose ID is given by elementId. If no such element exists, returns null. Behavior is not defined if more than one element has this ID. Source: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId I would think that the first one the browser finds is selected, but I can't be certain of that as I've never actually tried to do this. -- Aaron Heimlich Web Developer [EMAIL PROTECTED] http://aheimlich.freepgs.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
But that is my thinking of why $('span#bam') would be faster then just
$('bam').
But getting an element by ID is much faster--because there's a native method
of retrieval.
You're either selecting all span / tags and then looking to see which has
an ID of bam, or your finding the first instance of bam and then
checking to see if it's a span / tag.
If you use #bam it uses document.getElementById(bam)--which is native to
the browser and uses a predefined map to the objects and returns the object
with little processing expense.
The other two methods require additional processing on the behalf of jQuery.
That's when my ID is unique, I use the simplest selector: #bam.
-Dan
[jQuery] Re: SlickSpeed CSS Selector TestSuite
Yes, getElementById returns the first one found, i.e. the first one in the
dom, if there are multiple nodes with the same id.
The fact that jQuery looks for the id first, then the tag definitely
improves performance, but causes the following example to fail:
script type=text/javascript
$(document).ready(
function (){
$(div#bam).append( -- yellow);
$(p#bam).append( -- pink);
}
);
/script
style type=text/css
div#bam {
background-color: yellow;
}
p#bam {
background-color: pink;
}
/style
div
div id=bamI'm div#bam!/div
p id=bamI'm p#bam!/p
/div
If you run this example, the div / has a yellow background and the p /
has a pink background.
However, only the div / get it's text appended to it. You can work around
it by doing:
$([EMAIL PROTECTED]'bam']).append( -- pink);
This just isn't exactly intuitive and can be confusing to people who'd
expect a valid CSS selector rule to work in jQuery.
-Dan
[jQuery] Re: SlickSpeed CSS Selector TestSuite
On 6/12/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote: This just isn't exactly intuitive and can be confusing to people who'd expect a valid CSS selector rule to work in jQuery. Except that, while the selectors are syntactically valid, you can't have duplicate IDs on the same page, so you're basically at the mercy of how the browser decides to handle this situation. As has been said before, scripting on top of an invalid DOM is asking for trouble. If you cannot avoid doing this (i.e. the HTML is generated by a CMS that you have no control over), then $([EMAIL PROTECTED]'bam']).append( -- pink); is probably the best workaround. -- Aaron Heimlich Web Developer [EMAIL PROTECTED] http://aheimlich.freepgs.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
On Jun 12, 2007, at 8:14 PM, Benjamin Sterling wrote: By the way, does anyone know which page the slickspeed test is run on ( http://mootools.net/slickspeed/) ? I can't find any of the actual elements on the page itself. Not sure if I understand your question correctly, but they are using iframes for each framework. Yeah, you were understanding me correctly. I was being thick. Didn't see the iframes in the source first time around. And, regrettably, they are using the As You Like It page. --Karl _ Karl Swedberg www.englishrules.com www.learningjquery.com
[jQuery] Re: SlickSpeed CSS Selector TestSuite
On Jun 12, 2007, at 9:57 PM, Dan G. Switzer, II wrote: If you run this example, the div / has a yellow background and the p / has a pink background. However, only the div / get it's text appended to it. You can work around it by doing: $([EMAIL PROTECTED]'bam']).append( -- pink); yep. that's the workaround. This just isn't exactly intuitive and can be confusing to people who'd expect a valid CSS selector rule to work in jQuery. True, it can be confusing. But a lot of things are potentially confusing to people who are writing HTML that isn't valid. A few months ago I hung out on the CSS IRC channel, but I had to stop after a few days because it was too excruciating to hear person after person complaining about how CSS wasn't working right, only to discover that they're HTML wasn't valid. Others have said it here on the list before, and I agree, that it's a fool's errand to try to make jQuery anticipate the ways in which people are going to write bad markup. --Karl _ Karl Swedberg www.englishrules.com www.learningjquery.com
