• St Mary's Hospital for the $certain_people (unregistered)

    I wonder when the next OMGWTF contest will take place.

    I keep hoarding some good ideas.

  • Adrian Pavone (unregistered) in reply to Jay
    Jay:
    SOFTWARE DEVELOPMENT is to JAVASCRIPT as MASS TRANSPORTATION is to ____________

    (a) Ford Pinto

    (b) tricycle

    (c) train wreck

    Well, since you can hardly call Javascript "Software Development", I'm going to have to go with (d) A bunny rabbit!

  • Anone (unregistered) in reply to Paul
    Paul:
    Sorry, I just realized some people mightn't know what JScript is ... it's the IE-only dialect of JavaScript

    JScript and JavaScript are both versions of ECMAScript, not one being a version of the other.

  • blah (unregistered)

    Amateurs! The right way to do it is to fire off an AJAX event. What are they stuck in, the 70s?

  • The Dark (unregistered) in reply to JuanCarlosII
    JuanCarlosII:
    <noscript> <script type="text/javascript"> location.href = 'no_js.htm'; </script> </noscript>

    ... obviously.

    I actually saw the opposite. It boiled down to:

    <script> document.write("<noscript>This page requires JavaScript.</noscript>"); <script> </script>
  • (cs) in reply to Mr.'; Drop Database --
    Mr.'; Drop Database --:
    Jay:
    SOFTWARE DEVELOPMENT is to JAVASCRIPT as MASS TRANSPORTATION is to ____________

    (a) Ford Pinto

    (b) tricycle

    (c) train wreck

    (d) unicycle
    (e) flying carpet

  • (cs)

    Reminds me of some Java code I had to maintain a while ago:

    if(str.equals(null) || str.equals("")) {
  // snip
}
  • (cs) in reply to dkf
    dkf:
    Mr.'; Drop Database --:
    Jay:
    SOFTWARE DEVELOPMENT is to JAVASCRIPT as MASS TRANSPORTATION is to ____________

    (a) Ford Pinto

    (b) tricycle

    (c) train wreck

    (d) unicycle
    (e) flying carpet
    (f) FILE_NOT_FOUND

  • Keybounce (unregistered) in reply to obediah
    obediah:
    Mark Draughn:
    Well, it sure would be nice if the browser and the server shared a language. It would be one less thing to learn about web programming. You could validate user fields with the same code on both ends, and with a little framework support you could marshall objects back and forth between the server and the browser without having to implement everything twice.
    In can understand the appeal of shared development on a theoretical level, but a real world implementation has some serious issues:
    1. This almost certainly means moving javascript to the backend rather than moving your backend language to the browser.
    Java can run on both the browser and the server. WebObjects supported a JavaClient mode for a while that did exactly that.

    Sadly, I don't think Apple supports any of WebObjects anymore.

    (Truth in proselytizing: Java Client / Direct to Java client worked well over an intranet, but badly over internet speeds. But it was fast to prototype.)

  • David (unregistered) in reply to Mark Draughn
    Mark Draughn:
    Edward Royce:
    Honestly I don't see the point of server-side Javascript.
    Well, it sure would be nice if the browser and the server shared a language. It would be one less thing to learn about web programming. You could validate user fields with the same code on both ends, and with a little framework support you could marshall objects back and forth between the server and the browser without having to implement everything twice. It's not a huge win---most apps don't need it---but there are cases where it would be nice.

    You can send JSON objects to the browser from any server side language using many third party libraries (on the server).

    Sending JSON objects to the server and havinging them executed directly (using the execute method) would be a thermonuclear WTF.

  • Oh Please (unregistered)

    I would like to take every person who ever made a page that "requires JavaScript", tie them to a telephone pole, and whip them mercilessly until they swear never again to go within 1000 feet of a computer as long as they live.

    Developers of Flash-only sites, along with those who post PDF documents, will not get off so easily.

  • David (unregistered)

    I'll stick with <noscript></noscript>. Thanks.

  • (cs)

    function canIPostAComment() { return true; }

    function validateComment() { if(!canIPostAComment()) { location.href = 'no_comment.html'; } }

  • Dirk Diggler (unregistered)

    There's a lot about this web development stuff I don't know. Anyone willing to recommend a definitive book on this stuff?

  • Don't get it (unregistered) in reply to immibis

    Sorta reminds me of the original Apple LaserWriter. When you got it it came in a big cardboard box. Inside the big box was a smaller box. Inside th smaller box was a sheet of paper, explaining how to open the outer box.

  • add some flush too for best effect (unregistered) in reply to DOA

    Well.. it's JAVASHIT. It's the pure essence of facepalm. It's the refined way of saying "Aint me a cool jock wid mah commpyuta".

  • IHazYourCheezburger (unregistered) in reply to Sashlik
    Sashlik:
    Leo:
    Brompot:
    Here we send and email, alert the receiver by SMS, ICQ them to check their phone and walk by to tell them they're wanted on ICQ. Just in case some medium fails.

    ICQ? Is it still 1999 where you work?

    We love ICQ here in Russia, and use it widely :)

    In Russia, ICQ uses you!

  • Teemu (unregistered) in reply to Edward Royce
    Edward Royce:
    Honestly I don't see the point of server-side Javascript. It's not like there isn't a dozen languages that do server-side coding already.

    For all you youngsters out there, I can tell you that the point of SSJS WAS that it was there when (almost) nothing else was.

    The Netscape Enterprise Server that came bundled with Informix Database was a very easy tool to use. ASP and JSP didn't exist yet, and PHP was just a toy for personal use.

    (Take this from someone who started his career as coding SSJS applications for a couple of years from 1997 onwards)

  • MrOli (unregistered)

    Nope, yet again you guys have totally lost me in all your attempts to be more correct than each other, or to be 'first'.

    As with the DB level validation the other day, the only WTF here is the implementation.

    The basic idea is sound and works well with server side scripting and modern styling:

    Sorry, you must have Javascript enabled

    blah...
    <script language='javascript'> <!-- var w=document.getElementById("jswarn"); var c=document.getElementById("content"); c.style.display = 'block'; w.style.display = 'none'; --> </script>

    Feel free to hold a competition to see how many typos you can spot in the above ;-)

  • (cs) in reply to sumoman
    sumoman:
    There is one idiot proof solution 
    <head>
<noscript>
<meta id="metaRefresh" http-equiv="refresh" content="0;url=/markup.html"/> 
</noscript>
</head>

    Not quite, because some idiot will turn off meta redirects in their browser "for security reasons". Yes, this still happens. Then they complain because they get a blank page.

    As for ASP not being around in 1997, umm, yes it was. It was about 2 months old but still out there for those who wanted to use it (and had the money, yay for military research!), along with Microsoft certified courses. And PHP is still a toy, even after all this time.

  • (cs) in reply to Oh Please
    Oh Please:
    I would like to take every person who ever made a page that "requires JavaScript", tie them to a telephone pole, and whip them mercilessly until they swear never again to go within 1000 feet of a computer as long as they live.

    Developers of Flash-only sites, along with those who post PDF documents, will not get off so easily.

    Why the naked hostility? Sure, I get frustrated with web pages that have annoying and/or unnecessary requirements. But, you can do things with javascript that you can't do without it. Should nobody ever be able to do those things? When you're competing with desktop apps rather than static html pages, requiring javascript is not out of line.

  • (cs) in reply to MrOli
    MrOli:
    Nope, yet again you guys have totally lost me in all your attempts to be more correct than each other, or to be 'first'.

    As with the DB level validation the other day, the only WTF here is the implementation.

    The basic idea is sound and works well with server side scripting and modern styling:

    Sorry, you must have Javascript enabled

    blah...
    <script language='javascript'> <!-- var w=document.getElementById("jswarn"); var c=document.getElementById("content"); c.style.display = 'block'; w.style.display = 'none'; --> </script>

    Feel free to hold a competition to see how many typos you can spot in the above ;-)

    Lost you enough that you didn't read the rest of the thread?

    This was mentioned several times, the major problem is that it tends to flash the "Sorry..." message before hiding it.

    Use <noscript>... really. This is exactly what it's designed for. There is no need to look for clever ways to solve this problem!

  • (cs) in reply to obediah
    obediah:
    FriedDan:

    I'm not sure what "circumvent" has to do with this. Usually this kind of checking is for sites that require JavaScript for some reason but need to fail gracefully in the event that it isn't there.

    What exactly is the case you're worrying about being circumvented here?

    In this case, circumvention would mean getting access to the page requiring javascript without executing the javascript embedded in the page.

    The title of the article is "Bulletproof JavaScript Detection". You don't make something bulletproff unless you're worried about someone shooting bullets at you.

    Sorry about the day long delay...

    It's bulletproof because it will always properly detect that JavaScript is not available and show the proper message. Unless you work at it, there is no chance that the message will appear when JavaScript is available, and no chance that it will not appear when JavaScript is not available (except for the NoScript extension or similar which will let you know there is JavsScript there and being blocked itself).

    Security and accessibility are entirely different issues, but we're only a) talking about sites which, for whatever reason, require JavaScript and b) not talking about actually securing information... just about detecting a particular state.

  • Fister (unregistered)

    In BeOS, is_computer_on() was a system call that returned a constant integer. It was used to measure system call performance in the "best case." is_computer_on_fire() was later added to return a floating point number, to measure best-case system call performance with floating point number return values.

  • toth (unregistered) in reply to sumoman
    sumoman:
    There is one idiot proof solution 
    <head>
<noscript>
<meta id="metaRefresh" http-equiv="refresh" content="0;url=/markup.html"/> 
</noscript>
</head>

    Well, except that that doesn't validate.

    If you really must redirect non-javascript users, you're going to have trouble because the only ways to redirect are server-side, via <meta> or with Javascript. You obviously can't do the last one, and the other two basically require server-side preparation (and since browsers don't tell you whether Javascript is enabled, you're screwed there).

    I think the best option is to put a notification message in <noscript> tags. If you don't want to give your users access to you content if they don't have Javascript enabled, then you can hide your content via CSS and show it with Javascript. Not pretty, but it works and it validates.

  • Iain Collins (unregistered)

    I can see we have people here who don't realize JavaScript is a fine scripting language (and some people who seem to think it's related to Java). Unfortunately most developers simply are not familiar with it but have a strong opinion about it anyway, it is (still) widely misunderstood.

    JavaScript is not just a copy+paste language to fudge form interactions in, it's a sophisticated object oriented programming language you can develop rich dynamic interfaces in (especially with Canvas support). It also makes for a perfectly good server side scripting language, especially if your requirements are modest.

    Implementations of both JavaScript (as seen in WebKit and SpiderMonkey) and JScript (as seen in MSIE) make working with multi-dimensional arrays are a joy, they have try/catch support, good XML support for DOM manipulation and they interoperate well with server side HTTP services (with third party library support for interfaces like Document/Literal SOAP services).

    Most implementations have a few significant limitations, but in a number of ways it is more elegant than many other scripting languages.

    I'm not sure why people are fretting about whether things should be 'server side' or 'client side' - if you build the underlying web service first (with consideration for things like bubbling up errors) that should be straightforward. As always trying to implement a client/server model without a solid interface design up front will get you in a horrible unmentionable mess though (that happens a lot on the server side of many websites as it is).

  • (cs) in reply to WhiskeyJack
    WhiskeyJack:
    wee:
    Reminds me of when I worked for the Eudora group at Qualcomm. We had a whole wall full of "I forgot my password and can't check my mail, can you please email it to me?" tech support emails.

    I never understood what it took for someone to send an email like that.

    Then you're clearly not very imaginative. If they were able to EMAIL YOU the request, then clearly they have an alternate EMAIL address that you can send a password to. Most of us have more than one e-mail address.

    And what exactly makes you think that the makers of email client software might have access to someone's ISP in order to get the password that they've asked to have mailed back to an email account they can't check?

    In these emails to our support group, they asked that we email their password to them at the address they emailing from. They want us to hit 'reply', in other words. We're supposed to get their password and send it someplace they can't access. Get it?

  • Jason Scott (unregistered)

    Hooray! My first time a dailywtf code snippet went by and I got the joke!!

  • sumoman (unregistered) in reply to toth

    If you really must redirect non-javascript users, you're going to have tremendous trouble because that web application is plain BS. And therefore its the least of your problems, wether that syntax does w3c validate or does not.

    JS needs always to be used ONLY as to enrich user experience ADDITIONALLY.

    Fuc# JS-fanboys: That noobs force me to headtable x times a day.

  • (cs)

    if (!computerIsOn()) { document.write("This should never happen!."); }

  • (cs) in reply to sumoman
    sumoman:
    Fuc#
    Is that Microsoft's proprietary version of "Fuck"?

    I thought Brainfuck.NET was already taking it too far.

  • Jon (unregistered) in reply to wee
    wee:
    WhiskeyJack:
    wee:
    Reminds me of when I worked for the Eudora group at Qualcomm. We had a whole wall full of "I forgot my password and can't check my mail, can you please email it to me?" tech support emails.

    I never understood what it took for someone to send an email like that.

    Then you're clearly not very imaginative. If they were able to EMAIL YOU the request, then clearly they have an alternate EMAIL address that you can send a password to. Most of us have more than one e-mail address.

    And what exactly makes you think that the makers of email client software might have access to someone's ISP in order to get the password that they've asked to have mailed back to an email account they can't check?

    In these emails to our support group, they asked that we email their password to them at the address they emailing from. They want us to hit 'reply', in other words. We're supposed to get their password and send it someplace they can't access. Get it?

    Think he was pointing out that if they managed to send you the e-mail from that address in the first place, obviously they actually do have access to the address they want you to "reply" to...

    Not that that means you can actually get the password. =)

  • Jimmy (unregistered) in reply to Leo
    Leo:
    Brompot:
    Here we send and email, alert the receiver by SMS, ICQ them to check their phone and walk by to tell them they're wanted on ICQ. Just in case some medium fails.

    ICQ? Is it still 1999 where you work?

    If i was still using MSN it would 2022 where i live. 46 minutes to transfer 972kb of photos.

  • Edward Royce (unregistered)

    Hmmm

    "headtable"

    If only that was a standard part of HTML, a regular element in the DOM that could then be manipulated by Javascript!

    :)

  • Anonymous (unregistered)

    Another non-coder discovering what they're not good at. Hope his next career path is slightly more appropriate for him.

  • Not THAT Alex (unregistered)

    This.

    The first one.

    CAPTCHA: plaga.

  • Da' Man (unregistered)

    Schrödinger to Cat: "Are you alive, cat?" Cat: "No!"

  • Andrew (unregistered)

    Translated to english, this would be:

    "I don't think, therefore I am not."

  • Sane Person (unregistered)

    A while back I asked my ISP to upgrade me to a JSP-enabled server. To tell when they had gotten it done, I wrote this little program:

    <html><title>Can We JSP?</title>

    Can We JSP?
    

<%
if (true)
{
  out.write("We can JSP :-)
    ");
}
else
{
%>
We can't JSP. :-(
    
<%
}
%>
</html>

    Note that on a non-JSP site, all the JSP is just invalid tags that are ignored, so it displays "We can't JSP." On a JSP-enabled site, the JSP is executed, etc.

    I was rather excessively proud of myself for coming up with this simple, cute solution.

  • Sane Person (unregistered) in reply to Code Dependent
    Code Dependent:
    Edward Royce:
    And in case anybody thought I was kidding:

    http://authors.aspalliance.com/aldotnet/examples/coboldotnet.aspx

    COBOL.NET!

    Ahhhh the joy of looking through thousands of lines of COBOL code trying to find where the missing "." is.

    There are some real freaks out there in computing community.

    It's a combination of comfort zone and resistance to change. I had a boss a while back who was a COBOL programmer from way back. I can remember, although we had VB.Net and the brand-new C# to work with, he sighed wistfully and said he couldn't wait until Cobol.Net came out.

    I once saw an add for a program that would automatically translate C code to COBOL. My second thought was to wonder how such a program would work. There are a lot of features in C that would be difficult to reproduce in COBOL. My first thought was to wonder why in the world anyone would want to migrate from C to COBOL. That's like ... like ... selling instructions on how to convert your electric lights to burn whale oil.

  • Abscissa (unregistered)

    "We have a public site that requires JavaScript be enabled"

    That's "the real WTF" right there. An appallingly common WTF, but a WTF nonetheless.

  • Bulletproof Geek (unregistered)

    Wow, that's cool.

    That's inspired me to write a universal cross-platform API that I'd like to implement into every IDE and code editing app/widget.

    /* NOOB Open Source Public License */
function isCompetentProgrammer()
{
  notCompetent = "Sorry, only competent programmers can use this IDE.";
  if ( isCompetentProgrammer() && notEndlessLoop() )
  {
     if ( language == "javascript" )
     {
       document.write(notCompetent);
     }
     elseif ( language == "vbscript" )
     {
        print notCompetent;
     }
     elseif ( language = "php" )
     {
        echo $notCompetent;
     }
     else
     {
        print "Press ALT+F4 to upgrade this API to support the language you're using.";
     }
    
     // block person from writing code
     return false;
  }
  elseif ( endlessLoop() )
  {
    print "Sorry, you have caused an endless loop. RTFM to learn how to fix this problem.";
    return false;
  }
  else
  {
     // wow they are competent, allow them full access
     return true;
  }
}

    So now with this only competent programmers can use IDE's, anyone else that tries to use it will get the error message depending on which language they use, or they'll get the endless loop message if they use it wrong.

    I could probably evolve it to support .NET and other languages, but I'd have to use some inline assembler code as per http://thedailywtf.com/Articles/Code-Ownership-Gone-Awry.aspx

  • KMag (unregistered) in reply to BeOS easter eggs
    BeOS easter eggs:
    http://www.eeggs.com/items/15121.html 
    
#include <stdio.h> 
#include <be/kernel/OS.h> 

int main() 
{ 
    printf("%f\n", is_computer_on()); 
    printf("%i\n", is_computer_on_fire()); 
}

    That code is actually wrong. I just submitted a comment to that Easter egg site. is_computer_on() returns int32 (bool) and is_computer_on_fire() returns double. The calls aren't as silly as most people seem to think. They're used for getting benchmarks of the syscall interface that are more accurate than using getpid (Linux's fastest syscall).

  • Sowmya (unregistered) in reply to FriedDan

    Thanks!!! This reference helped :)

Leave a comment on “Bulletproof JavaScript Detection”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article