Point of No Return (key)



  • This might not really be a wtf because it is so common, but anyways. I was browsing merily along on the Internet, visiting, amongst other things, a page featuring certain dynamic and ajax driven "homepage" funktionality, hosted by a large web search company with an afinity for big numbers.

    I said to myself "this feature is cool, wonder how they did it", and decided to view the source code for the web page:

    [URL=http://img214.imageshack.us/my.php?image=googlehomepageah0.png][IMG]http://img214.imageshack.us/img214/9082/googlehomepageah0.th.png[/IMG][/URL]

    And that's when I stopped wondering "how they did it".



  • Google serves over a billion pages a day, (AFAIK).  Every byte they save saves them roughly a gigabyte a day in bandwidth.

    Their obfuscation measures (short var names, no CRLFs) probably save them over a terrabit a day, in the end.



  • The good news is that nobody actually had to write that crap by hand. It's output from a code generator: http://code.google.com/webtoolkit/overview.html



  • It's scary how many people just don't get it.

     



  • My markup looks about the same. Its mostly valid though. And its quite clean and simple when its formatted by "tidy" or similiar tools.

    My personal WTF is: The page is coded in PHP. Quick and dirty, but its not very complex and works fine. Its only features are creation of accounts for a c# game server, and some login features.

    Maybe this is my PHP code:
    print '<html>';
    print '<head>';
    print '<title>all your base</title>';
    print '<body>';
    print '<p>are belong to us</p>';
    print '</body>';
    print '</html>';

    The resulting markup is only one line and "hard to read". However, it's not too hard to apply changes in the PHP code, although some sort of template system is probably better, especially for larger projects.



  • If they were that bothered with bandwidth saving, why the "<option value=1>1</option>" style?

    Personally the majority of my ASP.classic pages ended up looking like that client-side. Not because of any obfuscation, bandwidth saving, or anything. Purely because the user doesn't see the code, the browser engine does, there's just no reason to write the extra code to put in pretty whitespace.

     Obviously the code behind it all was neat and laid out, but for something comouter generated, consumed, and not intended for human consumption, why go to the extra effort of prettifying it?



  • It's normal... And if you really want to understand the code - try venkman JS debugger (avaliable for mozilla suite and f.fox). It has option to "unobfuscate" code - changes code formating to a normal one, so you can really analyse it.



  • Reminds me of a project I once worked on. It was some sort of website with which employees could update their HR related info without having to write out paper forms and sending them to de HR dept. Page load times were very limited, so we decided to use an architecture where we would first send a fairly large JavaScript that basically took care of rendering the HTML, using the very terse data the server sent. To limit bandwidth the JavaScript was a oneliner wrapped in html tags, so it could be sent gzipped or deflated (this would not work for .js files...) .

    We tried writing an application to go through the code and replace variable and function names with shorter names. The net win of this excercise after zipping the resulting file was... absolutely nothing. So yes, no comments and no CRLFs saves badwidth, unintelligible variable names do not when sending zipped HTML. And I hope they do use zipped HTML.

    I think that even in generated code, variable names should mean something. If only to debug the generator.

    PS: page load time was limited to 6 secs on a 28k8 modem, the renderer.html was 12kB, other pages were 2.4kB max.
     



  • [quote user="RayS"]

    If they were that bothered with bandwidth saving, why the "<option value=1>1</option>" style?

    [/quote]
    Well, it's possible that the code generator (and the programmers, if they bother to go over the code manually) aren't perfect.



  • It's also possible that the web design software had an option to remove whitespace in the code before publishing.



  • [quote user="Jojosh_the_Pi"][quote user="RayS"]

    If they were that bothered with bandwidth saving, why the "<option value=1>1</option>" style?

    [/quote]
    Well, it's possible that the code generator (and the programmers, if they bother to go over the code manually) aren't perfect.
    [/quote]

    Or, it may be a compatibility measure.  There may be some POS 6 year old browser out there that requires option tags be closed.


     



  • [quote user="RayS"]

    If they were that bothered with bandwidth saving, why the "<option value=1>1</option>" style?

    Personally
    the majority of my ASP.classic pages ended up looking like that
    client-side. Not because of any obfuscation, bandwidth saving, or
    anything. Purely because the user doesn't see the code, the browser
    engine does, there's just no reason to write the extra code to put in
    pretty whitespace.

     Obviously the code behind it all was
    neat and laid out, but for something comouter generated, consumed, and
    not intended for human consumption, why go to the extra effort of
    prettifying it?

    [/quote]

    Because that is valid xhtml markup ? 



  • I think this is common when people want to obfuscate the code so that it will be harder for someone to adapt to their own circumstances. Development code looks regular, then variable (and function) names like 'siteKeyCode' becomes 's'. Of course, as someone else said, you could actually sort the spaghetti out fairly easily.



  • [quote user="merreborn"][quote user="Jojosh_the_Pi"][quote user="RayS"]

    If they were that bothered with bandwidth saving, why the "<option value=1>1</option>" style?

    [/quote]
    Well, it's possible that the code generator (and the programmers, if they bother to go over the code manually) aren't perfect.
    [/quote]

    Or, it may be a compatibility measure.  There may be some POS 6 year old browser out there that requires option tags be closed. 

    [/quote]

    I thought that RayS was referring to explicitly setting value=1 when the option is already 1.  It seems to be redundant, but perhaps someone knows if setting "value=1" is a requirement under some conditions?



  • Yes, it was the setting the value of 1 to be 1, and then the same for the other numbers, that I was commenting on. It just reminds me of all of those "int numberOne=1;" WTFs we see out there.

    Keeping good XHTML style by closing all your tags is never a WTF.

    Verbosely making sure that 1 REALLY DOES mean 1 in a bandwidth-contrained situation however, is (again, as per original post, assuming that that was the intent).
     



  • [quote user="Fabian"]

    Reminds me of a project I once worked on. It was some sort of website with which employees could update their HR related info without having to write out paper forms and sending them to de HR dept. Page load times were very limited, so we decided to use an architecture where we would first send a fairly large JavaScript that basically took care of rendering the HTML, using the very terse data the server sent. To limit bandwidth the JavaScript was a oneliner wrapped in html tags, so it could be sent gzipped or deflated (this would not work for .js files...) .

    [/quote]

     (emphasis mine).

     WTF?

     



  • @Fabian said:

    it could be sent gzipped or deflated (this would not work for .js files...) .

    That's a joke right?

    gzipping or deflating is handled at the HTTP layer, whatever you can send via HTTP you can gzip if the client understands it (and you don't have to worry about that, since content-negociation is automagically done by any HTTP server which can also gzip/deflate), and this includes HTML, JS and CSS.



  • IIRC, Netscape 4 didn't handle compressed .js files properly for some reason.



  • That's not a WTF, that's saving bandwidth.  It's not written like that, it's run through a filter before putting it on production servers.



  • @ender said:

    IIRC, Netscape 4 didn't handle compressed .js files properly for some reason.

    Yeah, but no one gives a fuck about that POS right?

    right?



  • [quote user="ender"]IIRC, Netscape 4 didn't handle compressed .js files properly for some reason.[/quote]

    Indeed, and guess what we had to support... 4.75 and 4.76

    I remember liking IE better than NN at the time. It was that bad. NN also did not have inactive check boxes, so to make certain pages look the same in IE and NN, I had to create GIFs of inactive check boxes (checked and unchecked of course). I also remember having to redraw one of the frames in NN for no apparent reason other than if I didn't it would just be gone.


Log in to reply