Den Odell

Den Odell http://denodell.com Thu, 01 Dec 2011 23:42:08 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Postpone script loading to the end of page rendering http://denodell.com/postpone-script-loading-to-the-end-of-page-rendering/ http://denodell.com/postpone-script-loading-to-the-end-of-page-rendering/#comments Thu, 01 Dec 2011 22:00:13 +0000 Den Odell http://denodell.com/?p=539 HTML <script> tags can be placed anywhere within the <head> or <body> tags of a page. Those with a src attribute pointing to a JavaScript file should be placed as close to the end </body> tag as possible.

The problem

When a web browser loads in an HTML page, it processes the markup line by line. Before anything is rendered to the window, the tags within the <head> section of the page are parsed and any external files, such as stylesheets and JavaScript files, are loaded and parsed before the contents of the <body> section of the page are rendered to the screen. Clearly then,

We call this behaviour script blocking.

The solution

Move scripts to the end of the page.

Use the <script src=”…” async></script> method.

Things to remember

Move <script> tags towards the end of the </body> tag
Specify the HTML5 async attribute on <script> tags to ensure they do not block the rendering of the page

]]> http://denodell.com/postpone-script-loading-to-the-end-of-page-rendering/feed/ 0 Prefer identity operators over equality operators http://denodell.com/prefer-identity-operators-over-equality-operators/ http://denodell.com/prefer-identity-operators-over-equality-operators/#comments Thu, 24 Nov 2011 19:16:04 +0000 Den Odell http://denodell.com/?p=548 The JavaScript language provides two distinct sets of operators for comparing whether two values are equal to each other, the identity operators (=== and its negative counterpart !==) and the equality operators (== and its negative counterpart !=). Prefer the use of the identity operators when comparing values over the more commonly used equality operators.

The problem

Consider the following code example:

var myArr = ["1", "2", "3"],
    myVar = myArr[Math.floor(Math.random() * 3)];

if (myVar == 3) {
    myVar += 10;
    // myVar = "310", not 13!
}

The value of myVar is set to a random value from the myArr array. If it’s value is 3, then 10 is added to that number to make 13. Unfortunately, in reality when this code is executed and the value in myVar happens to be 3, the resulting value is not the number 13, but the string value "310" instead! A string concatenation took place instead of a mathematical addition because one of the values in the equation was a string, in this case the value stored in myVar. The equality comparison let through a string representation of the number 3 despite the fact that the code asked for a comparison with a number value. Herein lies the problem with equality operators.

The equality operators do more than just a simple comparison if both operands are not of the same type, they actually perform a type conversion first, in that case. This behaviour is often called type coercion. The operands are coerced into becoming the same type before the actual comparison is made.

When comparing a number with a string representation of a number using one of the equality operators, as in the previous example, the string value will first be converted to a number before the comparison is made – an empty string will be converted to the number 0. When comparing a Boolean value to another operand of a different type, it will first be converted to a number (the number 0 representing false, and 1 representing true) before the comparison takes place. When comparing an object to data of another type, the primitive number of string value of that object will attempt to be obtained and then compared. If no coercion is possible without altering the operand values, the comparison expression will return false.

Of course, this automatic type coercion is a feature of JavaScript and, together with its ability to handle loosely-type variables, is part of what makes it such a powerful language. The problem here is one of control, and of wanting to be absolutely sure that comparing two values will give an expected result. With type coercion, unless the values being compared are definitely of the same type, there can be no absolute certainty of what result the comparison will give using the equality operator.

Examples of type coercion

Let’s look at a couple of examples of comparisons using the equality operators and see the values they return:

0 == false      // true

Here, the Boolean value false is converted to the number 0 before the comparison takes place, so the expression returns true.

"0" == false    // true

Both the Boolean value and the string are converted to numbers before the comparison takes place, and the expression returns true.

"" == 0         // true

The empty string is converted to represent the number 0 which matches the value of the other operand, hence the expression returns true.

1 == false      // false

The Boolean value is converted to the number 0 which is not the same as the number 1, so the expression fails.

"a" == false    // false
"true" == false // false
"false" == false // false
"false" == true  // false

None of the values can be coerced into the same type without altering their value, so each expression returns false.

The solution

To avoid this conversion of types before making a comparison, use the identity operator === (and it’s counterpart operator, !==) to compare both the value AND the type of both operands. Since this operator performs no conversion before making its comparison, the exact values are being compared to each other.

Returning to an earlier code snippet, and substituting the identity operator for the equality operator:

var myArr = ["1", "2", "3"],
    myVar = myArr[Math.floor(Math.random() * 3)];

if (myVar === 3) {
    myVar += 10;
    // myVar = 13
}

Now the comparison in this example will only return true if the value of myVar is the number 3, and that means that when the mathematical operation takes place, the result will always be an addition of two numbers, rather than a concatenation of strings. Of course, in this example the comparison will never return true since a string value is always being compared to a number. The conversion of values to a common type should take place before the comparison takes place, in a way dictated by the developer rather than by automatic type coercion.

That conversion could be performed in one of two ways. Either by converting the string value stored in myVar to a number value:

if (parseInt(myVar) === 3) {

or by converting the number value being compared to a string:

if (myVar === 3.toString()) {

In this way, the developer remains in control of their own code and can ensure that no unwitting behaviour will occur as a result of automatic type coercion within a comparison operation.

Things to remember

Always use the identity operators === and !== when comparing values.
Manual type conversion gives more control than relying on automatic type coercion.

]]> http://denodell.com/prefer-identity-operators-over-equality-operators/feed/ 0