It is no wonder that this is the case. With such staggering financial incentives it is understandable and reasonable, from their perspective, to shape law and public opinion to better their margins. It’s not complex. It’s all money.

If you’re a proponent of intellectual property and copyright in principle or even practice then this is a time at which you should be reviewing the situation and figuring out what, given the status quo, is going to prevent the approaching inhibition of our freedoms. Of course, you needn’t do this, if you, like the MPAA and RIAA, aren’t fazed by the idea of having your internet traffic monitored, held on file and released to copyright holders at their whims, and without due-process. If, on the other hand, you think this is all wrong, for whatever reason, then maybe it is time to think about what copyright really means to you…

It has been said that without copyright there is no incentive to innovate. This runs contrary to works created for the public domain, open source software, and works licensed under copyright-waiving terms (e.g. unlicense.org). The claim falls apart. There is, evidently, some other motivations involved in innovating.

So what is intellectual property really worth? Is it worth inhibiting further innovation and creativity? Should I have to pay countless artists millions of dollars to mix a track and create something new? Is this fair? Is it okay to have no privacy or freedom of expression?

Is intellectual property, as a whole, really in the best interest of humanity? If it is, then it follows that it is in the best interest of humanity to create a contentious atmosphere, wherein people are pitted against each other to better not themselves necessarily, nor humanity as a whole, but simply to improve their financial standing in society. It is easy to discount one’s support of these circumstances by convincing oneself that it’s “what we need to survive”, “just how things are”, “not gonna change” etc.

I don’t know what the answer is, but I sure as damn prefer the idea of society where I can distribute my creations freely and have them built upon by other people to better society as a whole. Such a monumental shift in perspective is not going to happen overnight, but maybe something will materialise out of mass opposition, and no, that doesn’t mean changing a facebook profile pic, adopting a twibbon, or blocking your site for one day. Even this-here text you’re reading is probably an exercise in futility. This’ll take continued effort and awareness. Or, we can all stick our heads in the ground and entertain ourselves with the petty spoon-fed ideals we’ve been conditioned to uphold and never question anything other than what’s for dinner, or when is the next episode of Celebrity Bullshit Revisited?

The existential operator (the accessor kind), if it existed in JavaScript, would allow us attempted access of nested properties in JavaScript without ever getting a TypeError. Here’s what usually happens:

var obj = { foo: 123 };
 
obj.foo.bar.bob; // Throws TypeError (obj.foo.bar is undefined)

CoffeeScript implements an existential operator that allows you to attempt access at a property without throwing errors. It will fail quietly by returning a harmless undefined value. In CoffeeScript, it looks like this:

obj?.foo?.bar?.bob // returns undefined

We can’t emulate this entirely but we can make a decent alternative using the Proxies API. In this example we’re using the dollar sign to indicate a existential-property-accessor-operator:

obj = {};
obj.foo$bar$bob; // => undefined
obj = { foo: { bar: { bob: 321 } } };
obj = existentially(obj); // wrap it in magic
obj.foo$bar$bob; // => 321

No, it’s not as cool and no, you probably shouldn’t use it in production. Yes, it’ll fail if obj doesn’t exist. Anyway, I thought it was pretty neat. Here’s how it’s done:

function existentially(obj) {
 
  if (obj == null) return obj;
 
  var proxy = handlerMaker(obj);
 
  proxy.get = function(_, name) {
    name = name.split('$');
    var found = obj;
    while (
      name[0] &&
      null != (found = found[name.shift()])
    );
    return found;
  };
 
  proxy.set = function(_, name, val) {
    name = name.split('$');
    var found = obj;
    while (
      name[1] &&
      null != (found = found[name.shift()])
    );
    if (found) {
      found[name] = val;
    }
    return true;
  };
 
  return Proxy.create(proxy);
 
}
 
// fyi
//   a == null
// is the same as
//   a === undefined || a === null

The referenced handlerMaker simply defines all fundamental traps. You can grab it from the MDN Proxy API page.

You’ll notice that we’re also defining a get trap, which enables stuff like:

var foo = existentially(document.getElementById('foo'));
if (foo) { // yes, we still need the initial null check
  foo.firstChild$style$display = 'none';
    // won't throw an error, even if `firstChild` doesn't exist
}

Okay, granted, the dollar sign doesn’t suit well and we’re just pandering to what’s allowed in JS, but it’s still a good illustration of what’s possible with the Proxies API. You might want to use another fake operator — possibly something that isn’t likely to be found as part of a property name itself… something like _$_ would be okay, except that it’s ugly and, just like $, carries no semantic value whatsoever.

When I say naming, I mean something as simple as naming a variable, or more often: an API endpoint — the thing that the end-user-programmer-guy is going to use. It’s hard.

I think code should be readable, but I don’t think that means it should be readable to everyone, even non-programmers. So, if I show a non-programmer Java and then Perl and they say the former is much easier to understand, I don’t think that counts as a mark against Perl.

I also don’t think we should needlessly simplify things to cater to the amateur. In fact, I love the idea of writing code that I expect to only be read by programmers seasoned in that very language. When I write JS, I like to presume that the maintainer knows about hoisting, closures, prototypal inheritance, and truthy/falsyness. Pandering about trying to make your code avoid these inherent qualities is a waste of time.

Even with that opinion I still hugely value expression through language. I love method chains that flow like spoken sentences:

render('this').thenRun(function(){});

But at the same time I don’t like putting too much effort into making an API bend to this style.

It’s really tricky to pick a principle and stick to it. Some of us prefer hungarian notation. I say I hate it but I still use it quite often.

I think programming should have a barrier to understanding, and I think APIs should too. This sounds weird, even to me, but I think it makes sense nonetheless. Fundamentally, every API disguises complexity and, ideally, a very precise piece of functionality. Making the API dead-simple makes no sense if what it is disguising is actually quite complex and involved. An API or language should be crafted in such a way that by using it you’re not only learning how to use it but you’re learning how it works.

jQuery is a good example, because it neatly expresses the DOM. It doesn’t hide the DOM, believe it or not. You still need to append and prepend, bind event listeners and apply CSS classes. The great thing about jQuery is that it reduces the DOM down to it’s very essence, so that when you have gained an understanding of jQuery you have also gained an understanding of the core idea behind the DOM.

So, no, I guess APIs and languages shouldn’t be as simple as possible just for the sake of it. They should represent the functionality they seek to disguise.

I’m not happy with this conclusion though. I am sitting here thinking about that end-user-programmer-guy. I guess this holy API should seek to provide exactly what this guy wants. The trick is knowing what he wants. It would be lovely if we could create computers that just had one input device — a big green button, which, when pressed, made the computer do exactly the thing you want. We don’t have this (yet!), and our APIs can’t have this either. But maybe there’s a healthy compromise where we model the API based on how it’s going to be used, not how we want it to be used. We are meaningless in that our petty preferences make no difference. Our APIs must be predictive; modelled entirely on the potential use-cases presented by end-user-programmer-guy, not modelled on our preferences alone.

I still haven’t resolved this in my mind. It’s still hard to decide what to call some method that will only be used once in a blue moon. It’s not as easy as describing the method entirely in its name:

var namespaceContainingMethods = {
  methodThatTakesArgumentsAndJoinsWithSpecifiedString: function() {
    //...
  }
}

I’ve had to use stuff like this before and it sucks. It sucks so much. It was made for idiots. That’s another thing: APIs should not offend. Don’t patronise me with your “ur so stupid” naming. Make me feel good about using your API.

It’s not easy. It’s just not.

The first thing that took me by surprise upon my entry, three years ago, into the “Digital Agency” world was the fact that some people that work with the web don’t use it very much. There are quantities of web developers that don’t have websites, don’t maintain personal projects, and don’t partake in the vibrant community.

This was a massive shock to my system because I, being naive and passionate, thought that everyone else in this industry would have at least a spark of a passion for this stuff or at least an interest which materialises in more than doing it, begrudgingly, from 9 to 5.

This isn’t a universal truth, of course, but what I’ve discovered is that those lacking in passion tend to gravitate towards either agency or non-web corporate roles. These individuals tend to know their niche’s technologies but only as well as they absolutely have to. They’re fine copying and pasting as long as it makes the boss or client happy. There are no gurus in the passion voids.

The entire process is ugly to begin with. Getting hired. If you can, you must make every effort to avoid dealing with recruitment agencies. I won’t cast any judgement on the validity of the recruitment industry as a whole, but I will say this: their motive is to fill the role. They rarely give a damn about passion, fulfilment or your desire to have a positive effect on the world while leading a good life. They couldn’t give a shit. They want the commission. They want to sell you to the client. You’re their whore.

If you want to float between vacuous advertising projects, where the sole objective is to maximise market share and profit for the end-client regardless of ethical inclinations, then you’ll probably be fine. You should stop reading and ring a recruiter now! If, on the other hand, you care, then you will want to take the time to find a better role, where the employer’s passions are in-line with yours.

I am not trying to generalise here. There are some, no doubt, awesome digital agencies that care passionately about the technologies they work with. This is why this must all be judged on a case-by-case basis.

Just beware of the passion voids. If you’ve an ounce of interest in what you do, you’ll want to steer well clear of them, lest your soul be forsaken to the clutches of vapid monotony.

fs.readFile(path.join(base, 'config.json'), function(err, data){
    if (data) {
        data = JSON.parse(data);
        data.forEach(function(path){
            fs.readFile(path, function(err, data){
                if (err) {
                    log(err)
                } else {
                    data = JSON.parse(data);
                    if (data.url) {
                        http.get(url.parse(data.url), function(){
                            // ...absurdum ad infinitum
                        });
                    }
                }
            })
        })
    }
});

This isn't a trait unique to node.js though. Much of JavaScript, since it is a language heavily bound to the client-side and therefore DOM and user-initiated events, is very liable to "Rampant Callback Syndrome".

Rampant Callback Syndrome

Rampant Callback Syndrome is a serious issue in the JavaScript arena and if left unchecked will continue to spread like a disease, poisoning our dreams with its ominous creep.

In all seriousness, it is rather annoying, and is definitely something that can be avoided with nothing more than a light dose of decent application design and thought.

One pattern that I've become fairly attached to is the simple premise of providing an API to begin with, and letting it appear to be a (mostly) synchronous interface, but behind the scenes throw around events to make it work properly.

Let's say, for example, that we want to expose a Model API, for interfacing with our database.

When the model is instantiated we go about opening the connection to the database:

function Model() {
 
    // (not shown) ... configuration stuff ...
 
    this.server = new mongodb.Server(
        this.config.address,
        this.config.port,
        {}
    );
 
    // (not shown) ... error checking ...
 
    this.db = new mongodb.Db(this.config.dbName, this.server, {});
 
    this.db.open(function(error, client){
 
        if (error) {
            this.error('DB: ' + this.config.db + ' error: ', error);
            return;
        }
 
        this.collection = new mongodb.Collection(client, this.config.dbCollection);
 
        this._isOpen = true;
        this.emit('open');
 
    }.bind(this));
 
    // (not shown) ... other stuff ...
 
}

The problem is that our new Model call will return before the connection to the database is open. Fortunately, as you can see above, in the callback to the db.open method we are setting a flag, _isOpen, to true, and we're emitting the open event. This Model happens to implement the events.EventEmitter interface which means we can fire and trigger on our object.

So, let's look at our calling-code:

var myModel = new Model({ /* config */ });
 
myModel.find({ username: 'James' }, function(data) {
    // I can live with a single nested function. 
});

This is great! The code above shows none of the callback nonsense we saw earlier^[1] -- we've abstracted it away. One big problem though is the find method is going to be called before our database connection is open. But, thanks to the events interface, we can hold off until our open event fires:

Model.prototype.find = function(selector, cb){
 
    if (this._isOpen) {
 
        // If we're already open, let's go:
 
        this.collection.find(selector).toArray(cb);
 
    } else {
 
        // Otherwise, wait:
 
        var args = arguments;
        this.on('open', function(){
            this.find.apply(this, args);
            // (added stability would be remove the event listener here)
        });
 
    }
 
};

In the else block we register a new event listener, to listen for the open event, and when it fires, we're simply going to call the very same method (find) with the very same arguments. Obviously this is only possible if we're using callbacks (one of the arguments to find()). Obliterating all callbacks is not we're looking for; we're simply looking to minimise.

Abstraction is the key

We can cure 90% of Rampant Callback Syndrome by simply abstracting our code.

The great thing about the solution shown in this post is that you're able to provide the promised API immediately following instantiation -- you're not forcing the higher level of abstraction to fuss with what is a lower concern.

^[1]: Yes, I know they're doing completely different things. My point still stands.

I had been thinking about making a version 2 for sometime, and about two weeks ago I started work on JSAPI.info. It’s built using node.js, and is more flexible than version 1 in that it enables you to explore the source of whatever library you want (as long as it’s specified), not just jQuery.

Demos

• jQuery (e.g. /jquery/css)
• Mootools (e.g. /mootools/Array.prototype.flatten)
• Dojo (e.g. /dojo/1/Color)
• Underscore (e.g. /_/every)
• YUI (e.g. /yui/3/namespace)

As I said, the URLs are “hackable”, so you can specify the method and version you want. Each page has a link to the documentation for that method (if found), and a list of related links (methods under the same namespace) on the left hand side.

How does it work?

It works by loading the library you specify into an instance of jsdom, and then evaluating the method you specify (in fully qualified form, e.g. jQuery.fn.css) within that instance. It then matches the toString() representation of that function (thanks V8!) against the source of the library, thus determining its location. It’s all operating under node.js, running via a beautiful configuration of nginx (primed to microcache!) on a linode box somewhere in London.

Yet to add…

I’ve yet to add the following features, and plan on doing so in the near future. The source is up on Github if anyone wants to help!

• Links within source code leading to other parts of the API. (DONE) The jQuery source viewer already does this.
• Thinking about adding beautify-js — this’ll change the format of the code though, so it won’t be consistent with the source code, and thus the line numbers won’t match up.
• I was experimenting with full documentation support so the documentation for a specific method could appear alongside the source code, but I’m not sure if it would be a sensible addition, especially considering that it can just link to the documentation instead.
• Any other features you can think of?

Why?

Have you ever tried to find the source of the jQuery.fn.height method? Try it now. It’s tricky.

If you’re anything like me, you’ll hit CTRL-F and type the most popular function/method declaration patterns, including function height..., height = funct..., height: function.... None of these work for jQuery.fn.height because it’s defined differently. It’s not easy to find.

I very often need to find the source behind a method I’m using and there aren’t many easy ways to do so, and that’s why I originally created the jQuery source viewer. JSAPI.info is a move in the right direction since it supports multiple libraries and, finally, has it’s own domain!

Please test it out and let me know if you catch any bugs.

Some developers don’t like the idea of using a language’s more idiosyncratic features because it does, potentially, make your code less readable in the eyes of those who haven’t learned the language properly. I think it’s still up for debate. While you’re pondering that, part II awaits…

If you haven’t checked out the “Truthy & Falsey” introduction then please do so before continuing.

Looping

It’s something we barely think about but JavaScript’s expressive diversity allows us to invent new patterns for looping. First, there’s the standard:

for (var i = 0; i < array.length; i++) {}

This is conventional and will be known to developers coming from any language. There’s nothing inherently wrong with it. That said, for me, it’s not ideal.

The first improvement I usually make is to cache the length property of the array:

for (var i = 0, l = array.length; i < l; i++) {}

This doesn’t make it shorter, but it does make it more efficient, although marginally so…

Another change we can make is to combine the iteration expression (i++) and the conditional expression (i < l), like so:

for (var i = -1, l = array.length; ++i < l;) {}

Notice that we’re starting with an index of -1, but won’t worry because before the loop’s body runs, the conditional expression is run, and in the above code, the conditional expression is iterating the index and testing it against the length all in one.

It’s important to note that the prefix increment/decrement operators (++i/--i) return the changed value, while the postfix increment/decrement operators (i++/i--) return the old value. To make this clearer:

var x = 5;
alert(x++); // alerts 5 (old value)
alert(x); // alerts 6
 
var y = 5;
alert(++y); // alerts 6 (new value)
alert(y); // alerts 6

Another looping “pattern” in JavaScript is to assign and rely on what’s returned from that assignment for the conditional expression:

var elements = document.getElementsByTagName('a');
 
for (var i = -1, el; el = elements[++i];) {
  el; // => a single element
}

Yesterday’s post on truthy & falsey bears some relevance here. The expression el=elements[++i] will return the value of elements[++i]. If this value is falsey the loop will not continue. An element list is full of truthy values (objects). We don’t need to be worried about falsey values. Note that in this approach, you may be sacrificing performance for terseness.

In many situations, we do want to iterate over falsey values too, e.g.

var myArray = [1, 2, 3, null, 8, 54, null, 0, 32];

With something like this it would be best to use the traditional i<length conditional expression, but if you’re so inclined feel free to mix the conditional and iteration expressions together like shown further up (++i<l).

If we were feeling a bit crazy, we could combine everything — iteration, conditional test, and assignment of indexed value — in a single expression:

var array = ['a','b','c'];
 
for (var i = -1, l = array.length, item; item = array[++i], i < l;) {
  alert(item);
}
 
// alerts, a, b, c

Here we used the useful comma operator which always returns its right-hand operand. In this example we used it to make sure that i < l is what the condition expression returns. Before the comma we’re assigning the value at the iterated index within the array.

I don’t really suggest doing all of this in one line, and to be honest, there’s nothing wrong with conventional looping structures. What I am trying to put across is how much expressive diversity JavaScript provides.

Assignments

Assignments are expressions too, so you can slot them in wherever you want:

var a = 1;
alert(a = 2); // alerts 2
alert(a); // alerts 2

An assignment operator will always return whatever is on its right-hand side. Be careful with slotting in assignment expressions wherever you want though, because they can be misconstrued for equality operators. For example:

var match;
 
if (match = '1/2/3'.match(/\d/)) {
  //...
}

To some, upon initial inspection, it may appear that we’re testing match for equality against '1/2/3'.match(/\d/) when in fact the latter is being assigned to the former, and the if statement will run if the assignment expression returns a truthy value (i.e. if its right-hand side operand is truthy).

Casting to a number

Quick and easy:

var str = '222';
var num = Number(str); // => 222
 
typeof num; // => 'number'

A shortcut is the unary plus (+) operator, used like so:

var str = '222';
var num = +str; // => 222
 
typeof num; // => 'number'

It works in exactly the same way.

Casting to a string

Once again, quick and easy:

var arr = [1,2,3];
var str = String(arr); // => '1,2,3'
 
typeof str; // => 'string'

The shortcut, this time, is to simply concatenate an empty string to the value that you’re casting:

var arr = [1,2,3];
var str = '' + arr; // => '1,2,3'
 
typeof str; // => 'string'

Saving references

Property lookup can be verbose and inefficient. To save space and to benefit performance it’s common to save references and access those properties via the new reference instead of having to evaluate the entire expression every time you want the nested value:

// Original:
document.body.style.color;
 
// "Caching"
var style = document.body.style;
 
// Whenever I need to access the `color` value:
style.color;

It’s often referred to as caching. Essentially, all that’s happening is that a new reference is being created for an object and being assigned to an identifier that you specify. Let’s start with this:

var data = {
    config: {
        doSomething: function(item){
            alert(item);
        }
    }
};
 
for (var i = -1, l = someArray.length; ++i < l;) {
    data.config.doSomething(someArray[i]);
}

It would make sense to minimise the amount of property access that needs to occur within the loop, and thus, potentially, anywhere else in our application that references data.config too:

var config = data.config;

Now the loop can simply reference config instead of data.config:

for (var i = -1, l = someArray.length; ++i < l;) {
    config.doSomething(someArray[i]);
}

We could even “cache” the function itself:

var doSomething = data.config.doSomething;

And then call it directly within the loop:

for (var i = -1, l = someArray.length; ++i < l;) {
    doSomething(someArray[i]);
}

IMPORTANT: It’s important to note that, when you assign a member function (that is, a function that is a property of an object) you are de-binding its this value, i.e. the context in which it runs. Here’s an example:

var obj = {
    value: 234,
    fn: function(){ return this.value; }
};
 
obj.fn(); // => 234
 
var fn = obj.fn;
fn(); // => undefined

De-binding the fn method will make its context the global (window) object instead of the obj which we defined, so when our fn function looks for its `this.value` it won’t find it (because this is the window, which doesn’t have `value` defined).

End of part 2

Comment if you feel compelled.

These are fundamental topics which I should have covered in more detail yesterday. There is copious information on this elsewhere online, so don’t feel limited to this post in your study.

Truthy: Something which evaluates to TRUE.
Falsey: Something which evaluates to FALSE.

It’s mostly logical. One (1) is truthy, Zero (0) is falsey. An object of any kind (including functions, arrays, RegExp objects, etc.) is always truthy. The easiest way to determine if something is truthy is to determine that it’s not falsey. There are only five falsey values in JavaScript:

undefined, null, NaN, 0, "" (empty string), and false, of course.

Note: It is possible to explicitly wrap a primitive (string, number, null, undefined, boolean) in an object, which will make it truthy. For example, 0 (zero) is falsey, but new Number(0) is truthy. A scarier example is new Boolean(false) which is also truthy! Be careful. Only very rarely should you need to explicitly wrap primitives.

Why should you care what’s truthy and what’s falsey?

A value’s truthi’ness determines what it will evaluate to in logical expressions. For example:

if (0) {
    alert('ALERT');
}

We know that the alert() call will never run, because 0, being a falsey value, doesn’t satisfy the if statement’s condition — i.e. to run only if the passed expression is NOT falsey.

From the spec:

The production IfStatement : if ( Expression ) Statement is evaluated as follows:

1. Evaluate Expression.
2. Call GetValue(Result(1)).
 
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
 
3. Call ToBoolean(Result(2)).
 
↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
 
4. If Result(3) is false, return (normal, empty, empty).
5. Evaluate Statement.
6. Return Result(5).

If you’re wondering, the phrase return (normal, empty, empty) essentially, means: continue with the program in a normal fashion. See 8.9 for more.

As the subtle arrows point out, the bit we’re interested in is step 3, which calls ToBoolean with the result of step 2, which is essentially (*) the value you passed in. But what is ToBoolean??

ToBoolean is simple:

I hope this has made it clear enough.

Enough of the spec!

We now know what happens when we pass something as an if statement’s expression (if(..this bit..){}), but how much relevance does truthy and falsey have in other logical contexts? Well, a lot.

Let’s explore the basic if statement one last time though:

if (X) {
    // If this code runs, what have we proven about X?
    alert(123);
}

If 123 is alerted what can we say (for sure) about X? We can definitely say that it is NOT one of: undefined, null, NaN, 0, "" (empty string), or false. We can therefore say that X is truthy. It might be the literal value true, a number that’s not zero, an array, a function, etc.

Remember, everything in JavaScript that isn’t a primative value can be considered an object. Functions are objects. Arrays are objects. And all objects are truthy.

Since all objects are truthy, code like this is quite common:

var el = document.getElementById('foo');
 
if (el) {
    el.style.color = 'red';
}

el is not a boolean, it’s just an object (in this case, a DOM Element object). The if block only executes if its expression is truthy. We could be more explicit though. The getElementById function returns null if it doesn’t find the element, so we could do:

var el = document.getElementById('foo');
 
if (el !== null) {
    el.style.color = 'red';
}

There’s usually little advantage in explicitly stating the falsey value that you’re looking for. Sometimes, you might want to guard against a null or an undefined but allow false, for example. In such circumstances, obviously, use the explicit syntax (strict equality and strict inequality operators – ===/!==).

The ToBoolean thing that we referenced above happens in all logical contexts in JavaScript. For example, the && (logical AND) operator:

0 && alert(0);
1 && alert(1);

In this case, only 1 will be alerted, since zero is falsey and therefore does not satisfy the &&‘s desire for a left-hand truthy operand. The logical AND operator will only evaluate its right-hand operand if its left-hand operand is truthy.

Further up we checked that the return value of getElementById wasn’t null by simply checking if it was truthy. If el was truthy then we knew the element existed in the DOM and we could begin to interact with it programatically.

We use a similar concept with object access.

alert(foo.bar); // Alerting the value of the 'bar' property of 'foo'

The only values that will throw an error when you try to access a property are null and undefined. So, if foo is truthy then we can safely attempt to access it’s bar property without worrying about exceptions being thrown.

if (foo) {
    alert(foo.bar);
}

Assume carefully

With our if statement we have only proven that foo is truthy. It still might not be the object we expect. This is something to consider. Normally though, it’s safe enough to suppose that if some obscurely named value is not falsey, it’ll be the truthy value you desire and not something you don’t want.

element.addEventListener ?
    element.addEventListener('click', func, false) :
    element.attachEvent('onclick', func);

Here we make some assumptions:

1. If element has a property addEventListener and its value is something truthy, it must be a function, so we’ll call it.
2. If it doesn’t exist then attachEvent must exist and must be a function.

The code above happens to be working around old IE versions that don’t have the W3C DOM Event method, addEventListener. The assumptions I’m making are considered safe in the environments that I intend my web app to operate in, but they may not be safe assumptions in other environments, so it’s important to be wary of the fact that: just because something is truthy doesn’t mean it’s the truthy value you happen to be looking for (the same goes for falsi’ness).

It’s common to attempt deep object access using the following structure:

a && a.b && a.b.c && a.b.c();

1. Make sure a is truthy.
2. Make sure a.b is truthy (and thus exists).
3. Make sure a.b.c is truthy (and thus exists).
4. Call a.b.c.

Again, we’re making assumptions, but we already knew that. This structure is very useful, although too much of it can make your code bloated, so maybe consider other options. For one: consider what you CAN safely assume. In some instances, you may be able to do this:

a && a.b.c();

1. Make sure a is truthy.
2. Call a.b.c.

In this example, we’ve determined that it is safe to assume that if a is truthy, it is the very object that we’re looking for, and therefore must have a minimum structure of: a={b:{c:function(){...}}}. We’re aware of our own data structure so can make this assumption.

Explicit booleans

You might be left wondering why we even bother having proper boolean values in JavaScript if we can get around quite easily with our other truthy and falsey values. And it’s true, we could manage without these booleans, and we rarely check for them explicitly. We usually just do something like:

if (foo.isAFoo()) {
    // ...
}

foo.isAFoo() could return any truthy value (not necessarily the boolean of true) and it would make no difference to the code execution.

But, it is important, in many situations, to be explicit in our intentions. So we should insist on using real booleans when there is a binary decision to make (two possible values).

To cast a value to its boolean representation, we can just use ToBoolean. We can indirectly use this internal method by calling the Boolean constructor as a function:

Boolean(0); // => false

It will return a boolean value — either true or false, and is a really quick way of finding out whether a value is truthy of falsey:

Boolean(undefined); // => false
Boolean(null); // => false
Boolean(false); // => false
Boolean(0); // => false
Boolean(""); // => false
Boolean(NaN); // => false
 
Boolean(1); // => true
Boolean([1,2,3]); // => true
Boolean(function(){}); // => true

A well-known and widely used shortcut is to use the logical-NOT operator twice, like so:

!!null; // => false
!!0; // => false
!!123; // => true
!!'foo'; // => true

I’ll leave that up to you to figure out

[complete!]

That’s it for today. Hopefully this has served as, at least, a minimal introduction to truthy & falsey.

I hope this post is useful to someone. I wrote it not for beginners (although it will be helpful to them), but for all those people writing JavaScript on a daily basis yet haven’t been afforded the time/motivation to get to know the language properly.

new Object()

Nope, don’t do this:

var o = new Object();

Or any of this:

var a = new Array();
var b = new Object();
var c = new RegExp("1(.)3");

Do this instead:

var a = [];
var b = {};
var c = /1(.)3/;

Array literal, object literal, regular expression literal. They rock. There’s usually no need to use the constructor functions when literals are available (please see the note below though).

Note: There are situations when calling Array or RegExp directly can be useful. In such situations, you needn’t bother with the new operator. Array(1,2,3) will produce the same as new Array(1,2,3). Calling RegExp directly can be useful for dynamically building a regular expression from various strings.

Calling a constructor

If you’re not passing any arguments then the parenthesis are not required. E.g.

var a = new Animal();

… and this becomes:

var a = new Animal;

Petty, perhaps. Still worth knowing though.

var;var;var

Quick and easy. Less of this:

var fun = 123;
var tun = 456;
var run = 789;

And more of this:

var fun = 123,
    tun = 456,
    run = 789;

This is why you should use a tab width of FOUR (or 4 spaces).

Undefined & Null

The following is universally true in JavaScript (assuming undefined hasn’t been mutilated):

undefined == null

“So what?”, you say? Well, it means you can replace this:

if (foo === undefined || foo === null) {
    //...
}

… With this:

if (foo == null) {
    //...
}

If something is == to null then it is either null or undefined. Those are the only possible values.

Returning undefined

Not returning something from a function is the same as returning undefined, so you may as well not bother explicitly returning undefined:

function a() {}
function b() { return; }
function c() { return undefined; }
 
a() === b(); // true
b() === c(); // true

Note: you should be careful with the undefined value as it can be changed. E.g. You can do undefined = true beforehand. The universe would shatter if you did that though, so please don’t. Many libraries declare an empty (undefined) variable in an enclosed scope, which provides a real undefined:

(function(){
 
    // My private scope. They can't see me in here.
 
    var undef;
 
    undef; // => definitely undefined
 
}());

Or, more succinctly:

(function(undef){
 
    undef; // => definitely undefined
 
}()); // <- not passing anything in!

Empty array values

This is entirely legal in JavaScript:

var a = [,,,'foo'];
a[3]; // => "foo"

One potential use-case of this was discussed in my recent post, `match.()` trick.

Less blocks, more expressions

I’m sure we’ve all seen something like this before:

function validateFoo(foo) {
    var regexResult = /^foo+$/.test(foo);
    if (regexResult) {
        return true;
    }
    return false;
}

A cleaner and more sensible solution is this:

function validateFoo(foo) {
    return /^foo+$/.test(foo);
}

No fussing with if statements and multiple returns. You can do everything within a single return statement.

Another example. We want to create a function that logs a name, specified by the arguments forename and surname, but if these arguments aren’t passed then the function should use the default values, “Bob” and “Smith”, respectively:

function printName(forename, surname) {
 
    if (forename == null || forename == "") {
        forename = 'Bob';
    }
 
    if (surname == null || surname == "") {
        surname = 'Smith';
    }
 
    console.log(forename + ' ' + surname);
 
}

This can be condensed to:

function printName(forename, surname) {
 
    forename = forename || 'Bob';
    surname = surname || 'Smith';
 
    console.log(forename + ' ' + surname);
 
}

Here, we’re using the logical OR operator (||) to provide a default value (right hand side) if the left hand side evaluates to false. Values that evaluate to false (i.e. “falsey”) are: An empty string (""), null, undefined, 0 and false.

So, this:

forename = forename || 'Bob'

… is essentially saying: if forename is a truthy value, then assign forename to forename (in other words: don’t do anything), but if it is a falsey value (e.g. an empty string), then assign the string "Bob" to forename.

So, our new printName function will behave like so:

//                            -- Logged --
printName();                  // Bob Smith
printName(0, 0);              // Bob Smith
printName(false, null);       // Bob Smith
printName('James');           // James Smith
printName('', 'Jones');       // Bob Jones
printName('Bill', 'Jones');   // Bill Jones

Part 1 [OVER]

That’s it for today. There may be a part two soon enough, depending on how useful this is to readers. I know many of you have surpassed this stage of learning, so sorry for boring you.

Recommended viewing/reading

Seriously, if you’re writing JavaScript as part of your job then you definitely owe it to future maintainers of your code to learning JS properly.

EDIT: Crockford links don’t work. The entire video can be seen on youtube instead.

• Douglas Crockford: “The JavaScript Programming Language”/1 of 4
• Douglas Crockford: “The JavaScript Programming Language”/2 of 4
• Douglas Crockford: “The JavaScript Programming Language”/3 of 4
• Douglas Crockford: “The JavaScript Programming Language”/4 of 4
• Bonus: Intro to JS & the DOM

I hate to pester people in their happy bubbles of existence but sometimes it’s necessary to remind oneself how lucky one is to have access to the most rudimentary of things: shelter, food and water. There is no doubt that we take these things for granted.

It’s easy to find scary statistics to put a point across, but often they lack accuracy or are taken out of context. Well, these aren’t such statistics — they’re from the UN’s World Food Programme, and they’re both accurate and shocking:

• One out of four children – roughly 146 million – in developing countries is underweight
  (Source: The State of the World’s Children, UNICEF, 2007)
• Every day, 16,000 children die of starvation (most of them under five). This equates to 1 child every 5 seconds.
  (Source: Food Insecurity in the World, FAO, 2005)

These numbers are beyond comprehension, to a degree, because of their enormity. It’s difficult to fathom. But it’s happening, and you should take it in. This is the world you live in. Face it, accept it, and if, in these facts, you find the impetus to make a change, then great! Even a small change is a great change.

When one thinks of a child, in Western society, she has parents, and they love her, and they would die for her at an instant. They sacrifice years of freedom and financial security to bring her up in this world. This one child will receive so much love and devotion. To think of the absolute devastation this child’s death would bring an entire community is almost laughable in comparison to the absolute silence with which a child perishes in other parts of the world. It means nothing.

Don’t be a coward about it. It’s not too depressing to think about. If you can’t handle the reality of life and insist on living in a bubble of make-believe then fine, but know that the joy and pain that you’ll feel is probably nothing in comparison to both the suffering, ecstasy and bliss that can be felt if you leave the bubble.

Graham Nash said:

Life is not perfect, and it never will be, you just have to make the best of it and open your heart to what the world can show you. Sometimes it’s terrifying and sometimes it’s incredibly beautiful, and I’ll take both — thanks.

Don’t shy away from the world. It’s the real thing. Experience it. Love it. Improve it.