JavaScript Practices – The Better Parts and Delegation: Is Crockford Too Extreme?

inheritancejavascriptprogramming practices

Douglas Crockford has recently been giving a talk called The Better Parts. The gist of the talk is that JavaScript developers should actually avoid a superset of the The Bad Parts, which now includes new, Object.create, any from of delegation or inheritence, including ES6 classes, and this.

Specifically, Crockford recommends defining new object types by using a constructor function that creates and returns a new object, and that uses closure to create private variables and so on. The obvious issue with this is that every instance has each of its methods bound directly to the instance; there's no delegation, and that's memory hungry. Crockford claims that this is a non-issue, because memory is so cheap. I found that pretty unconvincing.

In a case where some type needed a bunch of methods and a very large number of instances might exist at once, surely any decent JavaScript developer will put those methods in an object, and have every instance delegate to it. It then seems reasonable to just use that kind of one step delegation by default. This goes against the recommendations in The Better Parts, and as soon as somebody says "why not make that delegation recursive", we're back to where we began.

Obviously, if you are creating a very large number of instances of anything, you'd use delegation as an obvious optimisation, but we're normally talking about relatively small numbers, so for that case, can we just forget the costs?

What are the runtime costs of following Crockford's advice, specifically regarding avoiding delegation? On the kinds of consumer devices that typically run web browsers, are the costs generally minor?

Best Answer

This reminds me of a recent question on https://cs.stackexchange.com/questions/35385/for-small-values-of-n-on-can-be-treated-as-if-its-o1. And the answer is really the same -- yes, for small values.

What is small and will you be dealing with small? That sorta floats, based upon experience and your domain. But you go to experts for their expertise, absence either a definite performance problem or your own expertise saying that your domain is atypical, I'd trust them on a performance issue like this.

Remember, he is talking to the audience, not you individually. If you want to know if he is right in your case, then measure...

Related Solutions

Java – Why did memory-managed languages like Java, Javascript, and C# retain the `new` keyword

Your observations are correct. C++ is a complicated beast, and the new keyword was used to distinguish between something that needed delete later and something that would be automatically reclaimed. In Java and C#, they dropped the delete keyword because the garbage collector would take care of it for you.

The problem then is why did they keep the new keyword? Without talking to the people who wrote the language it's kind of difficult to answer. My best guesses are listed below:

It was semantically correct. If you were familiar with C++, you knew that the new keyword creates an object on the heap. So, why change expected behavior?
It calls attention to the fact that you are instantiating an object rather than calling a method. With Microsoft code style recommendations, method names start with capital letters so there can be confusion.

Ruby is somewhere in between Python and Java/C# in it's use of new. Basically you instantiate an object like this:

f = Foo.new()

It's not a keyword, it's a static method for the class. What that means is that if you want a singleton, you can override the default implementation of new() to return the same instance every time. It's not necessarily recommended, but it's possible.

JavaScript Inheritance – Are Super Methods Limited to Functional Inheritance?

var coolcat = function(spec) {
    var that = cat(spec),
        super_get_name = that.superior('get_name');

    that.get_name = function (n) {
        return 'like ' + super_get_name() + ' baby';
    };

    return that;
};

var cat = coolcat({ ... });

Can just as well be done with prototypes

var CoolCat = {
    constructor: function () {
        Cat.constructor.apply(this, arguments);
        return this;
    },
    getName: function () {
        return 'like ' + Cat.getName() + ' baby';
    }
};

var cat = Object.create(CoolCat).constructor({ ... });

Of course the main difference here is that your not creating two new functions every time you invoke coolcat. coolcat creates a new function for get_name and a new function for super_get_name and basically wastes memory left and right.

One may argue coolcat has privacy but it does not because anyone can call cat({}).superior('get_name'); and get your "private" method.

Of course if one wants privacy and prototypes that's perfectly possible, using the klass macro as shown in the article

var Cat = klass(function (privates) {
    return {
        constructor: function (name) {
            privates(this).name = name; 
        },
        getName: function () {
            return privates(this).name;
        }
    };
});

var CoolCat = klass(Cat, function (privates, $super) {
    return {
        constructor: function () {
            $super.constructor.apply(this, arguments);
        },
        getName: function () {
            return 'like ' + $super.getName.call(this) + ' baby';
        }
    };  
});

var cat = new CoolCat("someName");
console.log(cat.getName());

Live Example

Here we achieve both privacy and super class inheritance in an "elegant" manner.

In this elegant means not having the closure overhead of multiple functions per object (we still add a single closure per object for the privates function) and also allowing normal prototypical OO to just work.

Best Answer

Related Solutions

Java – Why did memory-managed languages like Java, Javascript, and C# retain the `new` keyword

JavaScript Inheritance – Are Super Methods Limited to Functional Inheritance?

Related Topic