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.

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

At the risk of being such a bearer of negativity, I will admit to disagreeing with some of what was sold in his speech. I am not “trolling”. I am offering my opinion, which also couples as a neutral critique.

I don’t feel that negativity is the problem. I think the real problem is deriving self-worth from validating or invalidating remarks from our peers. But at the same time I recognise this as an unchanging quality of human interaction.

If you say my code is cool, then I feel great. And if you say it’s not, then I feel upset. Whose to say which one of these reactions is the right one? Are we to dispel negativity, full stop, or are we to dispel the deriving of self-worth from such remarks? Is the positive to go as well?

Isn’t feeling pride of one’s own work merely an intellectual dishonesty when at the same time one will condemn both the occurrence of negativity and the feelings it rouses?

And let’s not forget, negativity is undeniably subjective in definition. What’s negative to you isn’t universally negative.

Maybe we should care less about the subjective polarity of the remark (good, bad, nice, mean). We should instead care about the remark’s content, i.e. its intellectual validity in the scene or thread in which it occurs.

Chris references an internet community that craves self-worth and thus derives it from online interactions (commenting, feedback, critique, “trolling”). This is an occurrence across the web, and isn’t something that plagues any particular sub-culture or sub-community uniquely.

We are only human. We are socialised animals, who have, through this socialisation, acquired a supposed weakness that makes us rely on others for validation and equally, condemnation. I know it’s wrong to steal my coworker’s food because I have been socialised to form that empathetic response that tells my mind: “No, that’s wrong.” It is via public condemnation and equally, public praise, that we acquire our values, preferences, and behavioural characteristics. Why shy away from this reality?

Negativity for the sake of itself is probably pointless, and I’m sure a great deal of what Chris refers to is just that — negativity without substance. But negativity (remember — it’s subjectively defined!) for the sake of intellectual or technical critique should be no less welcome than positivity.

Either way, since JavaScript and the DOM are bunking together, we may as well make it safe — OOP safe.

For fun, let’s see how this might look:

/*
 * Word 
 * A class that encapsulates a word
 */
function Word(word) {
 
    this.setDOM('<li></li>');
 
    this.text(word).css('color', 'red'); // jQuery methods!!!
 
}
 
Word.prototype = new jQuery.Interface; // Magical

So, we’re sub-classing something called jQuery.Interface, and jQuery.Interface is sub-classed from jQuery itself, meaning that you get all of jQuery’s methods in your object.

This is nothing ground-breaking because we always knew we could do stuff like:

function Planet() {
    // Implement planet logic
}
 
Planet.prototype = jQuery([]);
 
// Planet now inherits jQuery's methods!!

But… inheriting straight from jQuery() won’t give you what you want. Firstly, you’ll need to mess around with populating the DOM references yourself (this[0] = jQuery('<div/>')[0] etc.), and you’d have to manage the length property too, and lastly you wouldn’t get all of the jQuery chainability that you’re used to. Not as you might expect it, at least:

var earth = new Planet;
earth.age = 4540000000;
 
earth.appendTo('body').age; // undefined

It’s undefined because jQuery’s DOM manipulation methods will return new jQuery objects, not simply a reference to this, which is what we’d really like!

So, to make it a little easier, I created a little thing called jQuery.Interface which does these things for you, enabling you to have beautiful jQuery sub classes.

Subclassing jQuery means that your class’ instances can be treated just like jQuery instances. Here’s a more realistic potential application of it:

/**
 * HexColorTooltip
 * Shows a colorised tooltip when hovering over HEX colors
 */
function HexColorTooltip() {
 
    this.offsetTop = 10;
    this.offsetLeft = 10;
 
    this.setDOM('<div/>', {
        css: {
            position: 'absolute',
            border: '1px solid black',
            height: 50,
            width: 50,
            zIndex: 100
        }
    });
 
    $('body').bind('mousemove', $.proxy(function(e){
        this.mouseX = e.pageX;
        this.mouseY = e.pageY;
    }, this));
 
    this.appendTo('body').hide();
 
 
}
 
HexColorTooltip.colorRegex = /^(?:#[A-F0-9]{3}|#[A-F0-9]{6})$/i;
 
HexColorTooltip.prototype = $.extend(new $.Interface, {
    bindTo: function(elem) {
 
        var tooltip = this;
 
        $(elem).each(function(){
 
            var t = $(this),
                text = t.text();
 
            if (HexColorTooltip.colorRegex.test(text)) {
 
                t.mousemove(function(){
                    tooltip.setColor(text).show();
                }).mouseout(function(){
                    tooltip.hide();
                });
 
            }
 
        });
 
    },
    setColor: function(color) {
        return this.color === color ? this : 
            this.css('background', this.color = color);
    },
    show: function() {
 
        /// Overriding jQuery.fn.show
        this.css({
            top: this.mouseY + this.offsetTop,
            left: this.mouseX + this.offsetLeft
        });
 
        // Call super
        return this.fn.show.call(this);
 
    }
});
 
// USAGE
var tooltip = new HexColorTooltip();
tooltip.bindTo('span');

See it working.

I don’t know if others will be interested in something like this. For many developers who use jQuery this might seem completely different to the jQuery you know and love, for others, maybe you’ll see it as a move in the right direction.

jQuery.Interface on Github.

Please note that it’s experimental.

Please also note that this isn’t the same as jQuery.sub:

A = jQuery.sub();
 
var a = new A;
a.foo = 'Foo';
a[0] = document.createElement('div');
a.length = 1;
 
// Chaining not reliable because some methods return a new jQ
a.prependTo('body').foo // => UNDEFINED

Also, jQuery.Interface provides a helpful setDOM method. Fundamentally, jQuery.sub and jQuery.Interface are trying to solve slightly different problems, as far as I can see.

What I’ve been seeing a lot of is the DOM becoming incredibly intertwined with the logic, i.e. the program becomes indifferentiable to the DOM. It all ends up being the same:

var counter = document.createElement('div');
counter.innerHTML = '0';
document.body.appendChild(counter);
 
function add() {
    counter.innerHTML++;
}

Where does the logic stop and the DOM representation of that logic begin?

This is a rudimentary example, and probably something that few of us would be caught doing, but I think similar things are done every day, and not just by beginners. This is normal code. It isn’t some beginner’s hack.

It wears a different mask wherever it rears its head. Here, for example, it’s under the guise of jQuery’s data API:

var alphabetList = {
    giveHigher: function(dom1, dom2) {
        return $(dom1).data('word') > $(dom2).data('word') ? dom1 : dom2;
    },
    //...
};

A shockingly high majority of jQuery.data uses seem to be making the mistake that I’ve demonstrated.

It’s subtle, not easily spotted. Right now, I’m wondering whether or not it’s acceptable.

For me, it goes against what I’ve picked up in programming thus far. I’m talking about best practices like separating your concerns and maintaining an OO approach, writing clean APIs to access your program’s logic (etc.). To me, the DOM is yet another representation of an object’s data. The data shouldn’t be in the DOM. This is how I would do it:

function Counter() {
    this.dom = document.createElement('div');
    this.n = 0;
}
 
Counter.prototype.add = function() {
    this.dom.innerHTML = ++this.n;
};

The thing is, the approach here is so ridiculously similar to foo.innerHTML++ that I really can’t tell what I’m making such a fuss over.

The feeling I get when I see foo.innerHTML++ is the same as when I see:

jQuery('div').click(function(){
 
    if ($(this).data('active')) {
        // do x
    } else {
        // do y
    }
 
    $(this).data('active', !$(this).data('active'));
 
});

… instead of:

jQuery('div').each(function(){
 
    var active = false;
 
    $(this).click(function(){
 
        if (active) {
            // do x
        } else {
            // do y
        }
 
        active = !active;
 
    });
 
});

Opinions welcome.

Sonic uses the HTML5 <canvas> element/API. It works by drawing a shape (by default a 6px square) at tiny intervals along a pre-defined path. You can define the path using the functions: arc, bezier and line.

A really basic example is a square (four lines):

var square = new Sonic({
 
    width: 100,
    height: 100,
 
    fillColor: '#000',
 
    path: [
        ['line', 10, 10, 90, 10],
        ['line', 90, 10, 90, 90],
        ['line', 90, 90, 10, 90],
        ['line', 10, 90, 10, 10]
    ]
 
});
 
square.play();
 
document.body.appendChild(square.canvas);

View this example

You don’t have to make up the path with a series of tiny squares though. You can do whatever you want. Another step function that comes with Sonic is fader, which draws interconnecting paths along the main path. This in combination with an arc works quite well:

var circle = new Sonic({
 
    width: 50,
    height: 50,
    padding: 50,
 
    strokeColor: '#000',
 
    pointDistance: .01,
    stepsPerFrame: 3,
    trailLength: .7,
 
    step: 'fader',
 
    setup: function() {
        this._.lineWidth = 5;
    },
 
    path: [
        ['arc', 25, 25, 25, 0, 360]
    ]
 
});
 
circle.play();
 
document.body.appendChild(circle.canvas);

View this example

You can also define your own step function. This is really what I would recommend since the default ones (fader and square) are somewhat limited.

You might be thinking that I should have called it Snake instead of Sonic, but really, there are so many possibilities that Snake wouldn’t have made sense.

To see what Sonic can really do, visit the demo. Sonic is on github too.