FACT: After my post of a few days ago, I’m going to try to avoid beginning blog posts with the word “FACT”. I think labeling something as an ALL-CAPS FACT is just taunting someone to come along and dispute whatever you say. But anyway, I’ve already done it again.

OK, in the aforementioned post, I said that there were other, possibly … “better” ways of reusing code in JavaScript than by emulating classes. Take that “better” with a grain of salt. There are other ways, and some consider them better.

Prototypes

JavaScript is a prototype-based language. This means (as you can read for yourself in the link) that it creates new objects by cloning existing objects. The object you are cloning serves as the prototype of the new object. For now, just use the English language definition of prototype: “the original or model on which something is based or formed.” You have an object and you make a copy of it. It has all the properties and methods as the old one, and you can add new properties and methods to it. That’s how you get code reuse.

Now, a poor way to implement this would be to actually clone the existing object, copying over all its properties and methods to some new empty object. In that case, you’d wind up duplicating many of these properties on every single object, which could wind up in excess memory usage. So what JavaScript does is let you create a new object and link to the old original with an internal prototype property. This is NOT the public prototype property that you see on functions. This is an internal property that is not publicly accessible and is referred to in the spec as [Prototype]. Thus, if you try to access a property on a copied object, it will first look on the object itself, and if it does not find the property there, it will look on the object’s [Prototype]. If it’s not there, it will look on that object’s [Prototype] and so on up the chain until it reaches the top of the line, Object. If nothing on the chain has that property, it’s undefined for that object.

If that were the whole story, there wouldn’t be too much controversy on the subject. We’d create objects and create new objects based on them, and everyone would be happy. In fact, the Io Language, another prototype-based language, implements this very cleanly, and is a really fun language to program in. In it, you create a new object by cloning the base object, Object:

person := Object clone

You assign properties to the new object:

person name := "keith"

And then you can clone that object:

evilTwin := person clone
evilTwin attitude := "bad"

The problem with JavaScript is twofold: It originally offered no simple, native way of cloning object like Io’s clone method, and it introduced the new operator and constructor functions. When I say “problem”, I mean problem in a sense that it detracted from and wound up confusing JavaScript’s prototype-based nature, in an attempt to make it look “kind of” like a class-based language.

No access to [Prototype]

Because JS’s internal [Prototype] property is not accessible, it was initially hard to create prototype-based clones. Some browsers have provided a __proto__ property which exposes [Prototype]. If this exists, you can achieve prototypical inheritance almost as simply as in Io, like so:

var person = { name: "keith" };
var evilTwin = { attitude: "bad" };
evilTwin.__proto__ = person;
console.log( evilTwin.name ); // keith

You could make a clone function like so:

function clone( parent ) {
    var obj = {};
    obj.__proto__ = parent;
    return obj;
}

var person = { name: "keith" };
var evilTwin = clone( person );
console.log( evilTwin.name ); // keith

This will actually work if your browser supports the __proto__ property. Unfortunately, __proto__ is not a standard property and is not implemented in every browser. So that’s out.

The new operator and constructor functions

Instead of giving us a way to clone objects, JavaScript instead gave us the new operator and constructor functions. You know this already. It’s like this:

function Person() {
    this.name = "keith";
}

var me = new Person();
console.log( me.name ); // keith

What actually happens when you use the new operator with a function? A few very interesting things.

First it creates a new object and runs the function using that object as “this”. Any assignments to this in the function get assigned to the newly created object.

Next, it looks at that function’s prototype property. This is the publicly accessible property that is called prototype, not the hidden [Prototype] or __proto__. All functions have this property. Whatever that property is, it is assigned as the new object’s [Prototype]. This allows us to put properties and methods on the function’s prototype that will become part of the objects’s [Prototype].

Finally, it returns that object. So now you can do something like this:

function Person() {
    this.name = "keith";
}
Person.prototype.sayHello = function() {
    console.log( "hello" );
}

var me = new Person();
me.sayHello(); // hello

None of this is new to you. The point is that there is no real magic going on here. We could duplicate this functionality as long as we have access to __proto__:

function Person() {
    this.name = "keith";
}
Person.prototype.sayHello = function() {
    console.log( "hello" );
};

var me = {};
Person.call( me );
me.__proto__ = Person.prototype;
me.sayHello(); // hello

Again, we’re creating an object, calling the constructor using that object as this, which we can accomplish with call (or apply). You could even pass arguments to that constructor:

function Person( message ) {
    this.name = "keith";
    this.message = message;
}
Person.prototype.sayHello = function() {
    console.log( this.message );
};

var me = {};
Person.call( me, "yo, sup?" );
me.__proto__ = Person.prototype;
me.sayHello();

You could even create a function to make objects based on a constructor:

function Person( message ) {
    this.name = "keith";
    this.message = message;
}
Person.prototype.sayHello = function() {
    console.log( this.message );
};

function create( constr ) {
    var obj = {};
    var args = Array.prototype.slice.call( arguments, 1 );
    constr.apply( obj, args );
    obj.__proto__ = constr.prototype;
    return obj;
}

var me = create( Person, "awww yeah" );
me.sayHello();

Now, I’m not saying you should do this. In fact, I’ll reiterate that you absolutely shouldn’t. But it’s a fun exercise to see exactly what’s going on under the hood of new, and to fully understand that new is just sugar coating on top of JavaScript’s underlying prototype-based nature.

new and inheritance

The problem with this class-lookalike new operator becomes apparent when you start having one “class” inherit from another. The generally accepted solution is to create a new instance of the super “class” and assign it to the prototype of the new “class”.

function Person( message ) {
    this.name = "keith";
    this.message = message;
}
Person.prototype.sayHello = function() {
    console.log( this.message );
};

function EvilTwin() {
}
EvilTwin.prototype = new Person( "muahahaha" );
EvilTwin.prototype.doBadStuff = function() {
    console.log( "bad stuff is done" );
};

var twin = new EvilTwin();
twin.sayHello();
twin.doBadStuff();

This works fine, seemingly. The new object has the properties and methods from both “classes”. But various problems start to creep in. For one, notice that in what I’ve set up, there is no way to pass a message that will be used in the sayHello method when you are creating a new EvilTwin. In other words, there’s no automatic way of calling the super constructor. Also, if I overwrite a method, there is no way to call the super method. Various other problems arise based on the fact that constructor functions are not really classes at all, but some sleight of hand used to create prototype-based objects, as we’ve seen. Sure, people have gone about creating long complicated fixes for these issues that make JS look more and more like a class based language, but at what cost? I recently looked at one pseudo class library that was something like 1200 lines of code. All this complexity added no end user functionality whatsoever, only a way to make the programmer feel like he or she is using classes.

Object.create to the rescue!

As I’ve said, JavaScript has wound up with a confused identity due to it being a prototype-based language that had no way to create clones of existing objects (the core concept of prototype-based languages) and instead gave us a new operator to use with constructor functions to make it look more like a class-based language.

Fortunately, that is changing. ECMAScript 5 defines something called Object.create. This is essentially the clone method we created earlier. You pass it an object and it passes you back a new object that has the original one as its [Prototype].

var person = { name: "keith" };
var me = Object.create( person );

var evilTwin = Object.create( me );
evilTwin.attitude = "bad";

console.log( me.name ); // keith
console.log( me.attitude ); // undefined
console.log( evilTwin.name ); // keith
console.log( evilTwin.attitude ); //  bad

This is pure prototypal inheritance. Just like Io. Objects inheriting from other objects.

The good news is that many browsers already implement Object.create, so chances are you should be able to run that example right now. The other good news is that it’s easy to shim for those browsers that don’t have it:

if( typeof Object.create !== "function" ) {
    Object.create = function( obj ) {
        function F() {}
        F.prototype = obj;
        return new F();
    }
};

Since we cannot assign anything to an object’s [Prototype] (without __proto__), the only way of getting something in there is to assign it to a function’s prototype and then creating an object using new with that function. A bit of kludge, but it works, and with the above solution, you’ll get the native implementation if it exists.

Extending objects

Actually, the native version of Object.create is supposed to take an optional second parameter that is another object. All the properties on that object are copied over onto the new object. In the native version, this will be done with some new ECMA5 methods that deal with property attributes. So this can’t be exactly faked with environments that don’t have that. But you can create a method that extends an object by looping through another object and copying it’s properties. In fact, plenty of frameworks already have just such a function. But here’s a bare bones version:

function extend( obj, props ) {
    for( var prop in props ) {
        obj[ prop ] = props[ prop ];
    }
}

We can now redo our last example like so:

var person = { name: "keith" };
var me = Object.create( person );
var evilTwin = Object.create( me );
extend( evilTwin, { attitude: "evil" } );

console.log( me.name ); // keith
console.log( me.attitude ); // undefined
console.log( evilTwin.name ); // keith
console.log( evilTwin.attitude ); //  evil

Of course, for such a simple example, the extend function seems a waste, but if you were extending an object by adding some significant functionality, it would make it worth it.

Summary

I believe that going back to Object.create and treating JavaScript as the prototype-based language that it is will be a good thing. That’s 100% opinion. Not FACT. At any rate, it’s something that you should know about. I highly suggest you download the Io language and take a spin with it. In addition to the online documentation, there’s a chapter on Io in Seven Languages in Seven Weeks, which gives you a great intro to the language. Learning prototyped-base programming on a language you have no other experience with, and that implements it purely like Io is a great way learn the prototype way of doing things.

As always, don’t get serious about it. Learn some new stuff and have fun.

Further reading and Acknowledgments

I’d like to say I thought all this up myself, but of course it’s the distillation of lots of other stuff I’ve read over the past year.

http://javascript.crockford.com/prototypal.html

http://yuiblog.com/crockford/

[ http://rcm.amazon.com/e/cm?lt1=_blank
(Chapters 7 & 8 in particular)

And last but not least…

If you disagree with anything I say here, in the words of The Dude…

As interesting as this problem was to solve, it seems I could have solved it easier by grabbing the latest version of underscore, which does indeed define _ on global even when loaded via Require.js. Anyway, I learned a lot in the process!

I’ve been enjoying working with Backbone.js in the past month or two, and now I’m getting into Require.js to better organize my projects. I ran into a killer problem that I know others have encountered, as there are plenty of fixes and workarounds for it around the web. But I’ll add mine to the mix, as I think it’s pretty simple and elegant, if I do say so myself.

The problem comes from the fact that Backbone relies on the Underscore library. In particular, in the current version (0.5.3) it expects that when Backbone is loaded, the _ identifier is defined in the global scope. If it is not, it calls require(‘underscore’) to load it and assigns _ to global. You can see this in the following snippet in the backbone.js file at http://documentcloud.github.com/backbone/backbone.js

  // Require Underscore, if we're on the server, and it's not already present.
  var _ = root._;
  if (!_ && (typeof require !== 'undefined')) _ = require('underscore')._;

There are two problems here.

First is that if you load Underscore with require.js, it does not automatically create a _ variable in the global scope. Furthermore, because Underscore is not coded to be a require.js module, it does not return a reference to itself in the require callback. I’ll explain more in a second.

The next problem is that this is written for require on the server side, with node.js is synchronous, and require(‘underscore’)._ returns a reference to the Underscore library immediately, so it can be assigned to root._. But on the client side, require is asynchronous, and this will result in root._ being undefined, and you’ll get a failure with an error message about not being able to call the extend method of undefined.

So, the first thing we need to do is to load the Underscore library with require, prior to loading the Backbone library. This might look something like this:

require(
        [
                "app",
                "order!underscore-min",
                "order!backbone-min"
        ], 

        function( app ){
                app.init();
        }
);

You might put this in a main.js file that is referenced in your data-main attribute where you load require.js. First we require our main app module which will contain our app logic, then underscore and backbone. Also note that I’ve added the order.js require plugin which forces underscore and backbone to load in the order they are called. For simplicity’s sake, I’m assuming that all the files are in the same folder so we don’t have to worry about paths. When all are loaded, the callback will fire and we can initialize our app. This is the first round try that I made, which gave me the error.

So again, the first problem is that when you load Underscore, it does not assign _ to global, which Backbone expects. The second problem is that it is not coded as a require.js module so if you were to do something like this:

require(
        [
                "order!underscore-min"
        ], 

        function( underscore ){
                window._ = underscore;
        }
);

it would still not work. A module meant for require.js would return a reference to itself in that callback and we could assign it to global like that.

We need one more step, and that is to require Underscore again, after it’s loaded. This time we do not call require with the file name, but the module name, simply “underscore”. Since it’s already loaded, the callback will give us a reference to the library this time and we can assign it to window._.

This much is already known by many, but some of the solutions I’ve seen tend toward the overcomplex. I’ve worked on a few solutions myself, which also got pretty crazy. But I finally settled on something that is quite simple, and IMHO, pretty elegant. We create a new js file called underscore_fix.js, which looks like this:

require(
        [
                "underscore"
        ],

        function( _ ) {
                window._ = _;
        }
);

This gets called after we require Underscore by its file name, “underscore-min”, so it is loaded. Again, now that it’s loaded, requiring it by its module name will return a reference to the module itself. This we can assign to window._ and THEN we can load Backbone, which will work fine. The final main.js file looks like so:

require(
        [
                "app",
                "order!underscore-min",
                "order!underscore_fix",
                "order!backbone-min"
        ], 

        function( app ){
                app.init();
        }
);

Simplest fix I’ve come across. Apparently, there is a version of Backbone in the works that addresses this problem internally. So hopefully, this post will become obsolete before too long. Any better solutions out there in the meantime? I’d love to hear them.

I’m very happy to announce the release of this book, and need to say a few things about it.

First, this is a direct JavaScript port of my previous books, Foundation ActionScript Animation: Making Things Move!, and Foundation ActionScript 3.0 Animation: Making Things Move!. Chapter by chapter, they cover the same material, but teach you how to do the same things in JavaScript, mostly with canvas.

Second, I cannot take full responsibility for this book. Beyond the fact that my books served as the foundation for this book, I did no work on the actual writing of this book and had very little if any input on the book. I didn’t actually see the final manuscript until it was complete. I say this not as a complaint, or in any attempt to cover my own butt, or any kind of warning about the book’s quality (see point #3), but merely as a statement of fact. I gave consent to the project and sat back and let it happen, hands-off.

Third, when I finally did see the manuscript, I was very much blown away by what Billy Lamberta had done. Major respect to work through all the chapters of that book, converting it all into another language, while still staying true to the original form and intent. I can’t say enough how impressed I am at the job he did. Thank you.

Fourth, I’m also stoked to see that Apress released a Kindle version of the book at the same time as the print edition. Also, if you don’t want the Kindle format, you can buy direct from Apress: http://www.apress.com/9781430236658 and get the PDF, mobi, and ePub versions all for one price. I’m really happy to see Apress, O’Reilly and PragProg all doing deals like that on ebooks, as I’m trying to steer clear of any and all hard copy books and go all digital these days.

File this under “really writing this for myself so I can refer back to it later.”

window.onload = function() {
    var foo,
        offsetX,
        offsetY;

    // so it exists
    foo = document.createElement("div");
    document.body.appendChild(foo);

    // so we can see it:
    foo.style.width = "100px";
    foo.style.height = "100px";
    foo.style.backgroundColor = "blue";

    // so we can move it where we want:
    foo.style.position = "absolute";

    // so it looks like something we should click on
    foo.style.cursor = "pointer";

    foo.onmousedown = function(event) {
        // where is the mouse in relation to the div?
        offsetX = event.clientX - parseInt(foo.style.left || 0);
        offsetY = event.clientY - parseInt(foo.style.top || 0);

        // add listeners
        document.onmousemove = onMouseMove;
        document.onmouseup = onMouseUp;

        // prevent event propagation
        event.preventDefault();
        return false;
    }

    function onMouseMove(event) {
        // move the div in relation to the mouse
        foo.style.left = event.clientX - offsetX;
        foo.style.top = event.clientY - offsetY;
    }

    function onMouseUp(event) {
        // remove listeners
        document.onmousemove = null;
        document.onmouseup = null;
    }
}

Yeah, I know there are ways to make it more reusable, and probably your favorite library has a better version. blah blah blah. I just wanted to lay out the bare bones functionality so it’s plain to see.