Julian on JavaScript part I: Types

On Monday I started my webinar series on learning JavaScript when you’re a C# developer. The topic for part I was types in JavaScript. You can see the video of the webinar here.

In this blog post, I just wanted to fill in a couple of points made during that webinar. The first one has to do with the Boolean constructor and why you shouldn’t use it. If you recall, in order to declare a boolean variable, you should just declare a variable and set it to true or false:

var b = true; // or false of course

If you use the constructor function you get this:

var o = new Boolean(false); // or true of course

The problem with this latter statement is that the variable o is an object and not a primitive boolean type. If you want to test the truthiness of that variable in an if statement, for example, you cannot just write

if (o) { …do something… }

The reason for this is that o, the object, is coerced to a boolean in the usual JavaScript manner. If the condition expression is undefined, null, 0, NaN, the empty string, or the primitive value false, the condition is false otherwise it is true (we’ll be discussing these truthy and falsy expressions in a later webinar). Since o is a valid object, the condition will evaluate as true despite the fact that the object encapsulates a false value.

Instead you must test the property that “carries” the value of the boolean, namely, valueOf. Well, actually, that’s a function so you must call it to get the value:

var o = new Boolean(false);
if (o.valueOf())
  console.log("o is true");
else 
  console.log("o is false"); 

This gotcha is enough for me to recommend that you never use the Boolean constructor, just as I stated in the webinar. There’s really no need. If you see it in some JavaScript library in the wild, just walk away shaking your head.

Secondly, there was one question asked in the webinar that I didn’t know the answer to, at least not definitely.

“Where can I get a good JavaScript compiler?”

My answer at the time is that JavaScript is essentially a scripting language for use in browsers. Hence every browser contains an interpreter/compiler for JavaScript and, indeed, the browser manufacturers are all in a race to provide the fastest such interpreter. I mentioned that I thought there was a Java implementation of a JavaScript interpreter out there but I couldn’t remember anything more.

Having done a bit more research, it seems there are moves afoot to move JavaScript into other environments. Of particular note is node.js, an environment that provides the capability to write extremely scalable web servers through eventing I/O (instead of using threads/processes). It is built for Google’s V8 JavaScript engine, the one that’s built into the Google Chrome browser. Apparently V8 can be embedded in your C++ applications. There is also a wrapper for V8 in .NET called JavaScript .NET on codeplex, although it doesn’t look to be that frequently updated.

(The JavaScript interpreter that’s written in Java I was faintly remembering during the webinar was Rhino. Rhino can be embedded in Java applications to provide a scripting engine for end-user functionality.)

My next webinar in the Julian on JavaScript series will be Monday February 28 at 10:00am Pacific Time, and will focus on objects. It’ll be time to throw away your understanding of class models and embrace duck typing instead. Until then…

Free DevExpress Products - Get Your Copy Today