Ember.js Debugging 3 — JavaScript

Photo by Nathan Smith

I already covered the console object, which is built-in to the browser and is essential for debugging your Ember apps. Today I'll review features useful for debugging in JavaScript itself.

JavaScript

JavaScript is steaming pile of horrible, which is why Jeremy Ashkenas invented CoffeeScript to clean up the syntax (it's like Haml/Sass/Less for JavaScript), and why Google is trying to replace it with DART (check out this awesome Google I/O 2012 video). It has been covered extensively by others since the birth of the web, so there's no point trying to repeat that coverage here, even if I could.

Since we're noobs, I'll start your JavaScript debugging journey off with a few basic tips:

JavaScript: The Good Parts

A classic, must-have book by Douglas Crockford that explains the more confusing parts of JavaScript and suggests what to use, what to avoid, and why. Or you could watch the video. (I love tech videos — quick shout out to Confreaks.com, you guys rock!)

The typeof Operator

JavaScript doesn't have classes in the traditional sense, but it does have types. One of the most basic and useful techniques in debugging is to examine the type of a value.

typeof 2 // "number"
typeof "belladonna" // "string"

Be careful how you use it, though. The return values might not be what you expect, and are of limited use. I highly recommend reading this fantastic article by Angus Croll about the typeof operator, including ways of improving on it.

Truth and Equality

It's important to be aware of the various possible values in JavaScript, how they evaluate to true/false, and the subtle differences in how the numerous equality operators work. It's quite a mess.

Here are two great articles that cover the topic enjoyably:

• Truth, Equality and JavaScript by Angus Croll (again)
• Truthy and falsy in JavaScript by Caroline Schnapp

A terse summary of true/false values:

• False: undefined, null, false, 0, NaN, ""
• True: Everything else, including all objects — even empty arrays (which are objects) and the object returned by new Boolean(false).

A brief summary of equality operators:

• ==/!= (abstract): Use with caution, as these will coerce the operand types which can lead to suprising results (many people suggest avoiding them entirely).
• ===/!== (strict): If the operand types don't match, will always evaluate to false. Primitives (number, boolean, string) are compared by value, objects by id, and NaN/null/undefined don't equal each other (NaN doesn't even equal itself).

Or, if you prefer your knowledge delivered via A/V:



JSHint

You should be running JSHint on all of your JavaScript code. It checks for common errors that lead to hard-to-find bugs and enforces good coding habits, including those recommended by JavaScript: The Good Parts. JSHint is a more evolved fork of the original JSLint, which was created by the same Douglas Crockford who wrote JS:TGP.

You can run it from the command line by installing the node package (`sudo npm install -g jshint`) and running `jshint .` from a directory containing a tree of JavaScript files. However, I recommend using a text editor that continuously runs JSHint against your code as you type, giving you real-time feedback about your mistakes. It's efficient and invaluable, and happens to come built-in to Sublime Text 2, which is what I use.

The debugger Statement

This should have been included in my Firefox post since it's a browser-added feature (like console.log()) rather than a JavaScript language feature.

Instead of manually setting breakpoints within your in-browser debugger each time, you can add a debugger statement anywhere in your code that will cause your debugger to stop there. Simply:

debugger;

Next up: We finally get to Ember/Handlebars-specific debugging!