Flickr Javascript Gems



  • I was messing around in Flickr the other day, and a JS error popped up in my FireBug window. I usually check them out when i see them, so i click my little button, and up pops the console. There i see two errors with incredibly long variable names, so i decide to check out some of flickr's javascript. Heres a couple snippets:

     

    http://www.flickr.com/javascript/photo_notes.js.v1.17
    if (window.should_I_ignore_stuff_because_of_button_action || window.should_I_ignore_stuff_because_of_editable_div_action || global_comm_div.comming) return;
    Seriously, does a variable really need that long of a name?
     if (navigator.userAgent.indexOf("Mozilla/5.0") != -1 && navigator.userAgent.indexOf("KHTML")==-1) { // fix for stupid moz bug w/scrollbars and maxHeight
    //EXT.notes_text_area.style.overflow = '-moz-scrollbars-vertical';
    } else {

    }

    Ok, i understand why you would comment a line out, but whats with the empty else?

     Im sure theres more, but they have alot of code.



  • This "web 2.0" thing scares me sometimes.  With all of the javascript that gets spilled out for the world to look at, I foresee a lot of sites getting hacked because of this heavy use of JS, and programmers eventually relying on it to do their data validation.  Most of us know the #1 rule for web development is to not rely on the front end to do any validation.  I've seen web apps with 1200 lines of JS spit out right into the html source!



  • @seventoes said:

     if (navigator.userAgent.indexOf("Mozilla/5.0") != -1 && navigator.userAgent.indexOf("KHTML")==-1) { // fix for stupid moz bug w/scrollbars and maxHeight
    //EXT.notes_text_area.style.overflow = '-moz-scrollbars-vertical';
    } else {

    }

    Ok, i understand why you would comment a line out, but whats with the empty else?

    Scarily, the empty else statement is probably the result of the Javascript being generated on the fly with PHP, Perl, Ruby or somesuch. In my current job, just working on a poorly done web 1.0 application, I've come across 5 or 6 instances of PHP-generated Javascript that's different for each rendition of the page. Probably something of the sort:

    <xmp>

    echo "<script>if (condition) {";<br /> // do stuff<br /> echo "} else {";<br /> if (condition) {<br /> echo "do this;";<br /> }<br /> echo "}";</p> <p dir="auto"></xmp></p></p> </script>



  • [quote user="nuclear_eclipse"]

    Scarily, the empty else statement is probably the result of the Javascript being generated on the fly with PHP, Perl, Ruby or somesuch. In my current job, just working on a poorly done web 1.0 application, I've come across 5 or 6 instances of PHP-generated Javascript that's different for each rendition of the page.

    [/quote]

    I believe all of Google's javascript is written in java.

    http://code.google.com/webtoolkit/
     

    Javascript sucks in a lot of ways.  For one, it takes forever to develop in unless you abstract out all the browser incompatibility issues, and handle them all in a library like GWT (of course, said library can be in pure JS, so that in and of itself doesn't necessitate generated code).  So, why generated? From google themselves:

     

    Why Translate Java Code to JavaScript?

    Java technologies offer a productive development plaform, and with GWT, they can instantly become the basis of your AJAX development platform as well. Here are some of the benefits of developing with GWT:

    • You can use all of your favorite Java development tools (Eclipse, IntelliJ, JProfiler, JUnit) for AJAX development.
    • Static type checking in the Java language boosts productivity while reducing errors.
    • Common JavaScript errors (typos, type mismatches) are easily caught at compile time rather than by users at runtime.
    • Code prompting/completion is widely available.
    • Automated Java refactoring is pretty snazzy these days.
    • Java-based OO designs are easier to communicate and understand, thus making your AJAX code base more comprehensible with less documentation.

    Of course, this doesn't really excuse *bad* generated code...

    But there are some pretty decent arguments for doing it the right way.
     



  • So let me get this straight...

    In the beginning we wrote machine code.

    Then we wrote in a middle level language and compiled to machine code.

    Then we wrote in a high level language and compiled to bytecode that executed in an environment developped in a middle level language.

    Are we now writing code in a high level language and compiling to a super high level language? 

     

    Hmm... so in a few years... 

    Perfect! I'm going to revolutionize software development with a compiler that translates machine code to english!


Log in to reply