The JavaScript Comma Operator

(на русском, 日本)
 
Let’s begin with a funny tweet:

The ‘c’ at the end is for the lowly comma operator. Last in the line of operator precedence and rarely documented, the comma operator hides its light under a bushel. It may not be a JavaScript heavy-hitter but I like it anyway. Its simple, elegant and you should make it your friend. So, here we go – more than you’ll ever need to know about JavaScript’s bashful hero:
Continue reading

Rethinking JavaScript Object Enumeration

In JavaScript, enumeration across regular (non-Array) Objects is often more painful than it should be. Arrays are merrily dispatched through for and while loops using all manner of crazy, fun techniques; Objects are forever at the mercy of the pedestrian, one directional for-in loop, without which we can’t even learn the names and length of its own property set. Arrays have access to a plethora of elegant higher order functions (forEach, map, filter etc.); Objects don’t. Until now, that is.
Continue reading

Truth, Equality and JavaScript

 
You don’t have to be a JavaScript novice to get confused by this…

if ([0]) {
    console.log([0] == true); //false
    console.log(!![0]); //true
}

 
or this…

if ("potato") {
    console.log("potato" == false); //false
    console.log("potato" == true); //false
}

 
The good news is that there is a standard and all browsers follow it. Some authors will tell you to fear coercion and and code against it. I hope to persuade you that coercion is a feature to be leveraged (or at the very least understood), not avoided…
Continue reading

The JavaScript arguments object…and beyond

Spare a thought for JavaScript’s arguments object. It wants so desperately to be an array. It walks like an array, quacks like an array but flies like a turkey. During the early years of the language Brendan Eich came close to rewriting arguments as an array until ECMA came along and clipped its wings forever.

In spite of all this (or maybe because of it) we love the arguments object. In this article I’ll explore its niftyness and its quirkiness and I’ll finish up by looking at the likely successors: rest and spread
Continue reading

Exploring JavaScript for-in loops

The for-in loop is the only cross-browser technique for iterating the properties of generic objects. There’s a bunch of literature about the dangers of using for-in to iterate arrays and when to apply the hasOwnProperty filter, but beyond that, documentation of this ubiquitous construct is surprisingly patchy. This article attempts to fill some gaps, I hope its useful.

Continue reading

Delegation vs Inheritance in JavaScript

When asked what he might do differently if he had to rewrite Java from scratch, James Gosling suggested that he might do away with class inheritance and write a delegation only language.

Using inheritance as a vehicle for code reuse is a bit like ordering a happy meal because you wanted the plastic toy. Sure a circle is a shape and a dog is a mammal – but once we get past those textbook examples most of our hierarchies get arbitrary and tenuous – built for manipulating behaviour even as we pretend we are representing reality. Successive descendants are saddled with an ever increasing number of unexpected or irrelevant behaviours for the sake of re-using a few.

Delegation is a technique that promotes code reuse by allowing runtime function invocation in the context of a specific instance – regardless of the hierarchical lineage of instance and function. JavaScript has excellent support for Delegation in the form of call and apply which lets us inject an object into the this value of any function. This permits unfeterred code sharing, free from the constraints of unwieldy, unnatural and overly complex hierarchies.

I’m going to demonstrate, by way of a use case, how call and apply can promote a clean, functional approach code to re-use. Then I’ll discuss how the ES 5 specification enables re-use of built-in functions by formalizing the concept of generic functions.

Continue reading

Namespacing in JavaScript

Global variables should be reserved for objects that have system-wide relevance and they should be named to avoid ambiguity and minimize the risk of naming collisions. In practice this means you should avoid creating global objects unless they are absolutely necessary.

But, hey, you already knew all that…..

So what do you do about it? Conventional wisdom tells us that the best global abatement strategy is to create a small number of global objects which will serve as de facto namespaces for underlying modules and subsystems. I’m going to explore several approaches to namespacing, culminating in an elegant, safe and flexible solution that I based on a recent article by James Edwards.

Continue reading