Javascript framework performance

G

Gregor Kofler

RobG meinte:
The people at Mootools have published TaskSpeed[1], which is a
different take on their SlickSpeed[2] tests. More grist for the DM
anti-jQuery crusade - although Prototype.js seems to have saved it
from the wooden spoon for performance[3].

1. <URL: http://dante.dojotoolkit.org/taskspeed/ >
2. <URL: http://mootools.net/slickspeed/ >
3. <URL: http://dante.dojotoolkit.org/taskspeed/report/charts.html >

Depends heavily on the browser - on Opera and Chromium jQuery is
abysmally slow. On Firefox 3 it's - relatively speaking - not /that/
slow. But since FF is the slowest of the bunch on my computer, it's even
more atrocious.

Gregor
 
D

David Mark

The people at Mootools have published TaskSpeed[1], which is a

I wouldn't bother reading anything they publish about browser
scripting. See the review of their script.

http://groups.google.com/group/comp...read/thread/2232c2e46e200cde/a22d160dff2ce872

None of this matters anyway. What if jQuery, Prototype, MooTools etc.
could demonstrate something other than outrageously bad performance
(don't really need to run the tests to predict this outcome), they
would still be ill-advised compilations of useless browser scripting
trivia (not to mention ridiculous designs for Javascript.)

Competent cross-browser scripts are based on ideas. Incompetent
scripts are collections of misinterpretations based upon haphazardly
collected empirical data. It should be obvious which approach rots
and which keeps. The proof is in the constant rewrites, which often
contradict previous misinterpretations, leading to "old" browsers like
Opera 9.0 dropping off the supported list.

Should also be obvious that modern browsers have converged over the
last few years (even IE at this point), so the idea of a magic
compatibility leveler is as outdated as the inferences made by these
scripts. In the case of jQuery, it has been proven beyond any doubt
that the scripts create more problems than they solve.
 
D

David Mark

The people at Mootools have published TaskSpeed[1], which is a
different take on their SlickSpeed[2] tests.

[snip]

Appears to be a Dojo product. Good idea as measuring QSA results is
not going to illuminate anything.

I noticed one apologist response for jQuery and the like that admitted
the results were proof of sluggishness, but referred to these
monoliths as "time-savers" (and fun) in the same breath. I guess the
idea is to pass the productivity losses on to the end-user. :(

I like the inclusion of "pure" DOM methods. And it was predictable
that the "major library" zealots would label this "cheating."
Backwards as usual. They've been caught cheating and are crying that
those who studied have an unfair advantage. If only they had been
listening the last few years (as opposed to reciting marketing babble.)
 
D

David Mark

[snip]

In the case of jQuery, it has been proven beyond any doubt
that the scripts create more problems than they solve.

In case anyone needs more proof:

http://groups.google.com/group/jquery-dev/browse_thread/thread/936d6d405fb788b7

This key method (attr) will obviously never be fixed. All they do is
exchange memorized magic spells, which appear to work fleetingly, then
break on the next half-assed patch or browser revision. The "old"
browsers are cut loose and the spell gathering starts anew.

These are the developers tasked with "solving" IE (among a few other
browsers) for everyone and every situation. It is unfortunate that
they are so unfamiliar with their targeted agents. I couldn't see
using them to build one script for one site with one supported browser
installation on one computer. A magic do-everything for everyone in
"all browsers" script is clearly beyond their reach. Seems most of
the rest of the development world is content to watch, wait and wonder.
 
D

David Mark

[snip]

In the case of jQuery, it has been proven beyond any doubt
that the scripts create more problems than they solve.

In case anyone needs more proof:

http://groups.google.com/group/jquery-dev/browse_thread/thread/936d6d...

And again.

http://groups.google.com/group/jquery-en/browse_thread/thread/63be58b7cd44f56c#

Yeah, they put rowspan in their attr "black list" (as of 1.3x), but
not colspan.

Ironic, considering CLJ and this other group can be read through the
same Website. Seems searching this group for "colspan" and "jQuery"
would produce the answer immediately.

Or, they could search their own group to see what other neophytes
think:

http://groups.google.com/group/jque...ead/e8ba024a46f05f4f/d4642e6998be8871?lnk=gst

"The JavaScript implementation of colSpan seems to work fine. Looks
like a problem with IE's implementation of the DOM rather than with
JQuery, but I couldn't find it documented anywhere, so I wanted to
post it here."

Lots more COLSPAN confusion where that came from:

http://groups.google.com/group/jque...read/a09acde5d6d299d/2fa6dd1670ebfadb?lnk=gst

Hopeless. All of this nonsense is due to an obvious jQuery bug in a
method that should never have been written. As usual, it is
attributed to IE (no pun intended.) I thought jQuery was supposed to
be the great leveler? They had over ten years to study IE5-7 and this
is what they came up with? Years later, people stumble over these
bottled misconceptions on a daily basis, yet some inexplicable
devotion keeps them coming back for more.
 
R

RobG

The people at Mootools have published TaskSpeed[1], which is a
different take on their SlickSpeed[2] tests.

[snip]

Appears to be a Dojo product.

It seems to be on the Dojo domain, I thought it was Mootools based on
the copyright statement at the bottom, perhaps that relates to the
SlickSpeed component.

Good idea as measuring QSA results is
not going to illuminate anything.
QSA?


I noticed one apologist response for jQuery and the like that admitted
the results were proof of sluggishness, but referred to these
monoliths as "time-savers" (and fun) in the same breath.  I guess the
idea is to pass the productivity losses on to the end-user. :(

Yes, most don't understand that writing POJS doesn't always take
longer, that the few extra minutes here and there are returned ten-
fold in performance over time and that code size is only very loosely
correlated to performance, development time and maintainability.

But gee whiz, check out that truely awsome accordion thingy that
annoys the crap out of users!

I like the inclusion of "pure" DOM methods.  And it was predictable
that the "major library" zealots would label this "cheating."

A clear admission of defeat.
Backwards as usual.

Yup, wherever possible in the test code plain js should be replaced
with the equivalent library functionality, it's supposed to be testing
the library, not POJS.
 
D

David Mark

The people at Mootools have published TaskSpeed[1], which is a
different take on their SlickSpeed[2] tests.

Appears to be a Dojo product.

It seems to be on the Dojo domain, I thought it was Mootools based on
the copyright statement at the bottom, perhaps that relates to the
SlickSpeed component.
Good idea as measuring QSA results is
not going to illuminate anything.

QSA?

querySelectorAll. Should be qSA, I suppose. Basically, all of those
buggy query engines that work only on the latest browsers are
worthless now.
Yes, most don't understand that writing POJS doesn't always take
longer, that the few extra minutes here and there are returned ten-
fold in performance over time and that code size is only very loosely
correlated to performance, development time and maintainability.

But gee whiz, check out that truely awsome accordion thingy that
annoys the crap out of users!

Speaking of worthless (no pun intended):

http://groups.google.com/group/jquery-en/browse_thread/thread/e97aafb9a4a354cd

Sortable too! Well, not really. The OP appears to be looking for
something to paste into an inherited widget. The UI guy can't help,
that's for sure.
A clear admission of defeat.


Yup, wherever possible in the test code plain js should be replaced
with the equivalent library functionality, it's supposed to be testing
the library, not POJS.

Ideally, in the "real world" where Javascript "won't work" without
lots of extraneous nonsense. I mean, be fair. How can bloated,
inefficient scripts hope to compete with... Oh, that was the
argument, wasn't it?
 
P

Peter Michaux

David said:
Should also be obvious that modern browsers have converged over the
last few years (even IE at this point), so the idea of a magic
compatibility leveler is as outdated as the inferences made by these
scripts.

I think this is an overstatement. At the very least, multi-browser
event and XHR normalization libraries are still a practical approach
when programming for the general web.

Peter
 
P

Peter Michaux

[snip]

In the case of jQuery, it has been proven beyond any doubt
that the scripts create more problems than they solve.

In case anyone needs more proof:

http://groups.google.com/group/jquery-dev/browse_thread/thread/936d6d...

This key method (attr) will obviously never be fixed.  All they do is
exchange memorized magic spells, which appear to work fleetingly, then
break on the next half-assed patch or browser revision.  The "old"
browsers are cut loose and the spell gathering starts anew.

I remember watching a video of John Resig speaking as an invited
expert at Google. Someone in the crowd questioned Resig's endorsement
of using navigator.userAgent. Resig's response was along the lines of
"first people learn to program JavaScript with navigator.userAgent.
Then they learn feature detection. Then they get frustrated with
feature detection because some things cannot be tested this way. Then
they go back to navigator.userAgent." I think he has changed his mind,
at least partly, as I've heard all about jQuery doesn't sniff anymore.
I haven't looked into this claim in detail as I don't use jQuery or
any of the popular libraries.

I can agree that feature detection is frustrating at times. I have to
sit down and do some serious Safari feature testing soon and I'm not
looking forward to playing detective.

Peter
 
D

David Mark

I think this is an overstatement. At the very least, multi-browser
event and XHR normalization libraries are still a practical approach
when programming for the general web.

Yes, but XHR normalization doesn't add up to much. I do question
whether most apps need yet another "addEvent."
 
D

David Mark


In the case of jQuery, it has been proven beyond any doubt
that the scripts create more problems than they solve.
In case anyone needs more proof:

This key method (attr) will obviously never be fixed.  All they do is
exchange memorized magic spells, which appear to work fleetingly, then
break on the next half-assed patch or browser revision.  The "old"
browsers are cut loose and the spell gathering starts anew.

I remember watching a video of John Resig speaking as an invited
expert at Google. Someone in the crowd questioned Resig's endorsement
of using navigator.userAgent. Resig's response was along the lines of
"first people learn to program JavaScript with navigator.userAgent.
Then they learn feature detection. Then they get frustrated with
feature detection because some things cannot be tested this way. Then
they go back to navigator.userAgent." I think he has changed his mind,
at least partly, as I've heard all about jQuery doesn't sniff anymore.

From them. Don't believe that hype. They've moved on to sniffing by
object inference. Yes, ten years later, jQuery has reinvented browser
sniffing.

There aren't enough years left in the browser scripting movement for
jQuery to reach proficiency. Whatever Web3.0 will be, it sure won't
be this.
I haven't looked into this claim in detail as I don't use jQuery or
any of the popular libraries.

It's the typical marketing babble. Nobody involved with jQuery seems
to know what feature testing is (let alone how to implement it.)
I can agree that feature detection is frustrating at times. I have to
sit down and do some serious Safari feature testing soon and I'm not
looking forward to playing detective.

Testing for what?
 
D

David Mark

David Mark meinte:


Ah, I love the clarity of the code supplied. Sheer beauty.

$(function() {

Boy, that $ is handy. Takes functions too!

$("#accordion1").addClass("ui-accordion ui-widget ui-helper-
reset")

CSS "resets" are backwards. And I don't see any feature detection at
all (God knows it ain't in jQuery or its UI trappings.)

.find("h3")

Looks like this is all one "chained" statement. And does the poster
sound like someone who owns a debugger? I've seen evidence that none
of them can debug IE, including Resig. No wonder they have so many
unexplained problems with that browser.

.addClass("ui-accordion-header ui-helper-reset ui-
state-default ui-
corner-top ui-corner-bottom")

Love to see these style sheets. How do I know they are as bad as the
JS?

.prepend('<span class="ui-icon ui-icon-triangle-1-e"/

Sure, just compile a little XHTML and "prepend" it right in. How do
people see this as a worthwhile memorization? And these class names
are atrocious.

.hover(function() {
$(this).addClass("ui-state-hover");
},

How about something like:

$.addClass(this, ...);

Not cool? Must create a new jQuery object in every line? See that
new TaskSpeed test. Very validating.

function() {
$(this).removeClass("ui-state-hover");
})

Again.

.click(function() {
$(this).toggleClass("ui-accordion-header-
active").toggleClass("ui-
state-active")
.toggleClass("ui-state-
default").toggleClass("ui-corner-bottom")
.find("> .ui-icon").toggleClass("ui-icon-
triangle-1-e").toggleClass
("ui-icon-triangle-1-s")

Again, again, again. He's up to 5000 function calls at least.

.end().next().toggleClass("ui-accordion-
content-active").toggle();

Gobbledygook. But then, I'm just griping because I haven't memorized
jQuery-speak and can't compete with the amateur accordion players.

return false;

So he can write a decent line of code.

})
.next().addClass("ui-accordion-content ui-helper-reset
ui-widget-
content ui-corner-bottom").hide();
})

Make that 10000 function calls, zero compatibility and only the jQuery
forum(s) to turn to when this thing springs a leak.

And speaking of leaks. All of the jQuery UI folly leaks like a sieve
in IE. Yes, the UI guy knows about this. The "milestone" to fix it
is... well, who cares if you are building a site *today*.

And I agree, it's clear as mud to all but the most devoted jQuery
fans. I doubt the poster understood it either and now he wants to
paste on another layer of gibberish to make it "sortable." This is
how development is done with jQuery. Small wonder the results are so
abysmal.
 
G

Gregor Kofler

David Mark meinte:

[jQuery code snipped]
Make that 10000 function calls, zero compatibility and only the jQuery
forum(s) to turn to when this thing springs a leak.

It's quite fascinating to run Firebugs profiler with something simple as
jQuery UI's slider widget. Dragging the handle from left to right once
calls F() approx. 5,200 times, add() 4,300 times, init() 5,300 times
etc. All in all 17,000 function calls.

Compared to my simple-and-lean slider, I get - for the similar task -
call counts of 300 to 400 for coordinate calculation an half of that
figure for the listener calls.

When comparing the overall time allocated for dragging the slider once
across: jQuery 600ms, home-brew 75ms.
The competing scriptaculous/prototype version shows equal behaviour:
16,000 calls and 480ms...

Gregor
 
D

David Mark

David Mark meinte:

[jQuery code snipped]
Make that 10000 function calls, zero compatibility and only the jQuery
forum(s) to turn to when this thing springs a leak.

It's quite fascinating to run Firebugs profiler with something simple as
jQuery UI's slider widget. Dragging the handle from left to right once
calls F() approx. 5,200 times, add() 4,300 times, init() 5,300 times
etc. All in all 17,000 function calls.

And the feeble-minded nitwit who wrote it tested it on a beefed up PC
and pronounced it "fast enough." Then the site developers mash ten of
these things together, ballooning the page weight to 500K+, test it
over broadband and deem it "small enough."

The question was always "who uses old PC's and/or dial-up." With the
popularity of iPhones and the like, the latter is a non-argument (who
could have seen that coming?) As for old PC's, my XP boxes aren't
*that* old (or pedestrian), but these jQuery wonders are still
excruciating to use. Loud too. Pisses me off to no end that some
moronic Web "designer" is introducing noise pollution in my lab.
Nothing can make me leave a site quicker.
Compared to my simple-and-lean slider, I get - for the similar task -
call counts of 300 to 400 for coordinate calculation an half of that
figure for the listener calls.

That's about par for the course. Imagine what you could do with the
"left over" 16,700 function calls!
When comparing the overall time allocated for dragging the slider once
across: jQuery 600ms, home-brew 75ms.
The competing scriptaculous/prototype version shows equal behaviour:
16,000 calls and 480ms...

They both need a timeout.
 
G

Gregor Kofler

David Mark meinte:
That's about par for the course. Imagine what you could do with the
"left over" 16,700 function calls!

Five hundred more sliders! ;-)
 
D

David Mark

David Mark meinte:



Five hundred more sliders! ;-)

Or in the case of page weights, ten more documents worth of content.
The Web is clearly poised to go topsy turvy. I think it's quite clear
who will be topsy and who will be turvy. :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top