The Perfect Lack of Understanding



  • Longtime lurker... but I thought this was a bit worthy of consideration:
     
    $(document.getElementById('mcRdata_lg_'+a)).fadeIn(400);



    Yea, that's for real, encountered it in medium-sized site we're rescuing, a site
    driven almost entirely with javascript. Consider the implications of
    that for a moment.

    Bonus points: The 'Ajax' implimentation:

    frameC = eval(window.frames[0].document.getElementById('content'));



  • @quantax said:

    $(document.getElementById('mcRdata_lg_'+a)).fadeIn(400);
     

    What in the fuck.

    But it is somewhat questionable how fucking ridiculously overloaded jQuery's $() function is.

    @quantax said:

    frameC = eval(window.frames[0].document.getElementById('content'));

    Shoot him. Shoot. Just pull the trigger.

     



  • @dhromed said:

    @quantax said:

    $(document.getElementById('mcRdata_lg_'+a)).fadeIn(400);
     

    What in the fuck.

    But it is somewhat questionable how fucking ridiculously overloaded jQuery's $() function is.

    Actually it makes sense. The $() function accepts both an ID and the element itself. The latter is convenient if you only have a reference
    You could always get the ID from the reference and use that, but that's a bit redundant.

    The function returns a special object which has extra methods like fadeIn, it's the whole purpose of jQuery (and prototype, and... etc..) so not that big of a WTF
    @dhromed said:

    @quantax said:

    frameC = eval(window.frames[0].document.getElementById('content'));

    Shoot him. Shoot. Just pull the trigger.

     


    This, however, is just an abomination.



  • @Shondoit said:

    Actually it makes sense. The $() function accepts both an ID and the element itself. The latter is convenient if you only have a reference
    You could always get the ID from the reference and use that, but that's a bit redundant.

    The function returns a special object which has extra methods like fadeIn, it's the whole purpose of jQuery (and prototype, and... etc..) so not that big of a WTF
    Writing $(document.getElementById('mcRdata_lg_'+a)) instead of $('#mcRdata_lg_'+a) makes sense—if you are getting paid per character. Otherwise it’s just fucking stupid.



  • @snover said:

    Writing $(document.getElementById('mcRdata_lg_'+a)) instead of $('#mcRdata_lg_'+a) makes sense—if you are getting paid per character. Otherwise it’s just fucking stupid.

    I assume he was referring to the overload being available, as per dhromed's comment. I think (and hope) nobody's stupid enough to defend that approach.



  • Find whoever wrote that code and force a JQuery reference book down their throat. Literally.



  • @Shondoit said:

    Actually it makes sense. The $() function accepts both an ID and the element itself. The latter is convenient if you only have a reference
    You could always get the ID from the reference and use that, but that's a bit redundant.

    The function returns a special object which has extra methods like fadeIn, it's the whole purpose of jQuery
     

    I'm well aware of jQuery's features 🙂

    The $() function accepts:

    1. CSS selector (which is fucking great, you know. No really. )
    2. a second argument as parent context
    3. a DOM node object (ie. element)
    4. a string of HTML which is converted to a DOM structure
    5. a function reference which is called onload. A "shorthand" for $(document).ready(fn) which was already pretty short.

    These things are wildly different, and it's a little messy. #5 doesn't need to exist, and #4 is better served with a separate method.

    Make no mistake, I love jQuery beause of the It Just Works factor and how it's not a clunky over-engineerd multi-lith such as prototype+scriptaculous, but it has its quirks, obviously.



  • @snover said:

    Writing $(document.getElementById('mcRdata_lg_'+a)) instead of $('#mcRdata_lg_'+a) makes sense—if you are getting paid per character. Otherwise it’s just fucking stupid.
    Wouldn't there be some significant performance improvement from doing it the way it is done in that code? If you know it's going to be an id, you can call the getElementById method, then get jQuery to give you its custom object. Using the second format requires jQuery to work out it is a string, invoke its selector parsing, and go searching for it with its custom methods. I seem to recall that jQuery is smart enough to recognise the ID fragment and internally use getElementById, but that's still going to involve some pointless regex matching and string splitting. If this code happens to be in a performance-critical location, it makes sense to use the DOM yourself, instead of forcing jQuery to waste time working out what you needed from it, before finally using the DOM in exactly the same way as you could have done.



  • @TarquinWJ said:

    @snover said:
    Writing $(document.getElementById('mcRdata_lg_'+a)) instead of $('#mcRdata_lg_'+a) makes sense—if you are getting paid per character. Otherwise it’s just fucking stupid.
    Wouldn't there be some significant performance improvement from doing it the way it is done in that code?

    No, this code is followed by .fadeIn(400). That is an animation that takes 400 ms to complete. The performance gains are incredibly miniscule in comparison.

    Stop trying to justify this.



  • @SlyEcho said:

    Stop trying to justify this.
    Indeed, I am not trying to justify its use on quantax's site, since in that case it is clearly due to a lack of understanding. But snover's comment was a little too sweeping, since there are legitimate reasons for using that approach in certain circumstances, even though it may look pointless. Hence my use of "if" in the text:@TarquinWJ said:
    If this code happens to be in a performance-critical location



  • @TarquinWJ said:

    Wouldn't there be some significant performance improvement from doing it the way it is done in that code?
    Yeah. Instead of 21.45µs per lookup, you’ll get it down to 4.84µs per lookup. WOO-HOO!

    Note: (Those numbers are for Firefox 3.5. In Chrome, the difference is 2.99µs vs 0.46µs.)



  • @SlyEcho said:

    No, this code is followed by .fadeIn(400). That is an animation that takes 400 ms to complete. The performance gains are incredibly miniscule in comparison.

    Stop trying to justify this.

     

    Especially when it is very unlikely that the person who wrote this horror did it for any reason but ignorance.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.