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
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
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
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
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?
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
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
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
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
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,
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
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
*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
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
: 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?
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
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
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
.
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
] 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
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,
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
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
-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...
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
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
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
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
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
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
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
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
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
One bad Apple spoils the bunch.
I think there's a Donnie Osmond joke in there somewhere...
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
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
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
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.
--
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
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
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
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
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,
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
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
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
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
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
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
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
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
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);
66 matches
Mail list logo
