Five Lessons From JavaScript: The Good Parts

I have just finished reading JavaScript: The Good Parts by Douglas Crockford. It is quite an illuminating book, from which I learnt a number of interesting and useful lessons about JavaScript. I have chosen five to share with you below. If you are interested in JavaScript, you might find something useful here and I would strongly encourage you to buy and read the book yourself.

undefined and null

If I had been asked what the simple types in JavaScript were before reading this book, I would have replied with number, string and boolean. In fact, there are two more simple types in JavaScript: null, and undefined. Having worked with JavaScript for many years, I have of course encountered null and undefined many times, but had never really considered their types, or that they are indeed simple types themselves.

So what is the difference between undefined and null?

When you try to retrieve the value of a property or variable which has either not been assigned a value, or which has not been declared, you will receive the undefined value.

The null value must be explicitly assigned to a property or variable before it is encountered.

However, matters are complicated by the fact that the expression (null == undefined) returns true, which means that in the following code, our alert is raised.

var notAssigned; // will return undefined

if(notAssigned == null){
  alert('it is null!');
}

…which brings us to the two sets of equality operators.

== and ===

For programmers like myself who come from an object-oriented language background, it is easy to fall into the trap of making a lot of assumptions about the JavaScript syntax without really taking the time to check those assumptions.

An easy mistake to make is to assume that the “double equals” equality operator == has the same basic meaning in JavaScript as it does in C#. However, there is an important difference.

In C#, the double equals will only return true if the two operands either point to the same reference (for reference types) or contain identical values (for value types). In JavaScript, the double equals can return true even if the two operands are of different types. The reason for this is that when the double equals is presented with operands of different types, it will attempt to convert one of the operands to the type of the other, and compare the result. Below are examples taken directly from the book, which demonstrate some of the strange consequences of this behaviour.

'' == '0' // false
0 == '' // true
0 == '0' // true
false == 'false' // false
false == '0' // true
false == undefined // false
false == null // false
null == undefined // true
' \t\r\n ' == 0 // true

The other equality operator offered by JavaScript is the triple equals, ===. This displays behaviour which is more like what we would expect. It does not attempt to do any conversions when presented with operands of different types, it just returns false. So in each of the examples listed above, false would be returned.

The double equals operator is identified by Crockford as one of the bad parts of JavaScript, and he advises against using it under any circumstances.

Objects are Containers of Properties

Having confirmed that all values in JavaScript are either simple types or objects, an “aha” moment for me was reading that all objects in JavaScript are simply containers of properties. It’s a satisfying feeling being able to abstract a seemingly complex or unclear concept into a simple model (isn’t this in fact the whole purpose of science?). From my experience with JSON and object literals, I was quite familiar with the concept of properties and values in JavaScript. However it had never dawned on me that objects are simply containers of properties, with each property consisting of a name and a value. That value can of course be another object, which contains its own properties, and so on. Objects in C# are more complicated . A C# object can have a variety of different types of members, including methods, events, delegates and properties. Furthermore, each of these members is associated with a visibility level, such as ‘public’ or ‘private’. Behaviour according to differing levels of visibility can be emulated in JavaScript, as I discussed in a previous post, however this feature is not built in to the language. I find the fact that objects are such simple constructs an almost beautiful feature of JavaScript.

Another important feature of objects is the prototype linkage feature, but that is probably a topic for a separate blog post.

Functions are Objects

Functions in JavaScript are themselves objects, which means, as we have seen, that they are simply containers of properties. How is a function simply a container of properties? In a nutshell, it has hidden properties for the function’s context and its enclosed statements. The important difference between a function and any other object is that a function can be invoked.

The fact that functions are objects means that they can be assigned to a variable, stored in an array, passed as an argument to a different function, or used in any other way that a ‘regular’ object might be used.

An interesting aspect of functions in JavaScript is the value of this inside of a function, which I discussed in a previous post.

Function Scope in JavaScript

This is something I feel I really should have known about JavaScript, but I must confess I didn’t.

Variables in JavaScript have function scope, unlike C# which has block scope. What this means is that when you declare a variable in JavaScript, it is accessible by any code within the same function, even if that code exists outside of your current block, as defined by your curly braces. This is probably best explained by an example:

var myFunction = function()
{
  if(10 > 5)
  {
    var message = 'hello there!';
  }
  alert(message); // alerts 'hello there!'
}

If JavaScript had block scope, like C# and Java do, then invoking myFunction would cause undefined to be alerted. In fact, our message ‘hello there!’ is alerted.

For reasons of clarity, Crockford advises us to always declare our variables at the top of the containing function. So our code would then look like this:

var myFunction = function()
{
  var message;

  if(10 > 5)
  {
    message = 'hello there!';
  }

  alert(message);
}

Having function scope rather than block scope is identified by Crockford as one of the ‘awful’ parts of JavaScript.

Final Words

In summary, this is a book that is well worth reading for anyone interested in the finer points of JavaScript. My next goal in developing knowledge and understanding in my chosen niche is to start looking at angular in more detail. I’m not yet sure how I will go about this, but the free tutorial over at codeschool.com looks like it could be a great place to start.

The post Five Lessons From JavaScript: The Good Parts appeared first on The Proactive Programmer.