Javascript framework performance

Discussion in 'Javascript' started by RobG, May 14, 2009.

  1. RobG

    RobG Guest

    RobG, May 14, 2009
    #1
    1. Advertising

  2. RobG

    rf Guest

    rf, May 14, 2009
    #2
    1. Advertising

  3. 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


    --
    http://www.gregorkofler.com
    http://web.gregorkofler.com - vxJS, a JS lib in progress
    Gregor Kofler, May 14, 2009
    #3
  4. RobG

    David Mark Guest

    On May 14, 6:14 am, RobG <> wrote:
    > 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.
    David Mark, May 14, 2009
    #4
  5. RobG

    David Mark Guest

    On May 14, 6:14 am, RobG <> wrote:
    > 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.)
    David Mark, May 14, 2009
    #5
  6. RobG

    David Mark Guest

    On May 14, 12:29 pm, David Mark <> wrote:

    [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.
    David Mark, May 14, 2009
    #6
  7. RobG

    David Mark Guest

    On May 14, 2:39 pm, David Mark <> wrote:
    > On May 14, 12:29 pm, David Mark <> wrote:
    >
    > [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.
    David Mark, May 14, 2009
    #7
  8. RobG

    RobG Guest

    On May 15, 4:25 am, David Mark <> wrote:
    > On May 14, 6:14 am, RobG <> wrote:
    >
    > > 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.


    --
    Rob
    RobG, May 15, 2009
    #8
  9. RobG

    David Mark Guest

    On May 14, 11:06 pm, RobG <> wrote:
    > On May 15, 4:25 am, David Mark <> wrote:
    >
    > > On May 14, 6:14 am, RobG <> wrote:

    >
    > > > 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?


    querySelectorAll. Should be qSA, I suppose. Basically, all of those
    buggy query engines that work only on the latest browsers are
    worthless now.

    >
    > > 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!


    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.

    >
    > > 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.


    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?
    David Mark, May 15, 2009
    #9
  10. David Mark wrote:

    > 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
    Peter Michaux, May 16, 2009
    #10
  11. On May 14, 11:39 am, David Mark <> wrote:
    > On May 14, 12:29 pm, David Mark <> wrote:
    >
    > [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
    Peter Michaux, May 16, 2009
    #11
  12. Gregor Kofler, May 16, 2009
    #12
  13. RobG

    David Mark Guest

    On May 16, 12:48 am, Peter Michaux <> wrote:
    > David Mark wrote:
    > > 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.


    Yes, but XHR normalization doesn't add up to much. I do question
    whether most apps need yet another "addEvent."
    David Mark, May 16, 2009
    #13
  14. RobG

    David Mark Guest

    On May 16, 12:55 am, Peter Michaux <> wrote:
    > On May 14, 11:39 am, David Mark <> wrote:
    >
    >
    >
    > > On May 14, 12:29 pm, David Mark <> wrote:

    >
    > > [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.


    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?
    David Mark, May 16, 2009
    #14
  15. RobG

    David Mark Guest

    On May 16, 8:50 am, Gregor Kofler <> wrote:
    > David Mark meinte:
    >
    > >http://groups.google.com/group/jquery-en/browse_thread/thread/e97aafb...

    >
    > 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.
    David Mark, May 16, 2009
    #15
  16. 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


    --
    http://www.gregorkofler.com
    http://web.gregorkofler.com - vxJS, a JS lib in progress
    Gregor Kofler, May 16, 2009
    #16
  17. RobG

    David Mark Guest

    On May 16, 2:31 pm, Gregor Kofler <> wrote:
    > 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.
    David Mark, May 16, 2009
    #17
  18. David Mark meinte:

    >> 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!


    Five hundred more sliders! ;-)



    --
    http://www.gregorkofler.com
    http://web.gregorkofler.com - vxJS, a JS lib in progress
    Gregor Kofler, May 16, 2009
    #18
  19. RobG

    David Mark Guest

    On May 16, 3:33 pm, Gregor Kofler <> wrote:
    > David Mark meinte:
    >
    > >> 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!

    >
    > 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. :)
    David Mark, May 16, 2009
    #19
  20. On May 16, 12:11 pm, David Mark <> wrote:

    > Pisses me off to no end that some
    > moronic Web "designer" is introducing noise pollution in my lab.


    Your "lab"?

    Peter
    Peter Michaux, May 16, 2009
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anatoly Volodko
    Replies:
    1
    Views:
    2,097
    Mattias Sjögren
    Aug 14, 2003
  2. Charles A. Lackman
    Replies:
    1
    Views:
    1,342
    smith
    Dec 8, 2004
  3. Mark
    Replies:
    4
    Views:
    1,718
    Juan T. Llibre
    Nov 17, 2005
  4. moi
    Replies:
    3
    Views:
    4,052
    quaiser_ali
    Sep 26, 2008
  5. Replies:
    2
    Views:
    9,309
    Darryl L. Pierce
    Sep 11, 2005
Loading...

Share This Page