4

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?

2
  • 3
    The question may apply to everything Douglas Crockford says. For example, isn't it too extreme to forbid the usage of == and != operators, while there are actual cases where I do want type-agnostic [in]equality? Crockford's pieces of advice should be mandatory for any beginner and are highly recommended for intermediate programmers, and are good for 99.9% of situations you encounter. When you face the remaining 0.1% of the situations and you know the language enough, you're free to go against what is told in Crockford's books and talks. Commented Dec 20, 2014 at 18:43
  • Is the compiler able to use 'copy-on-write' to share the memory used by all the closures in the OP?
    – dcorking
    Commented Nov 2, 2015 at 20:39

1 Answer 1

5

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...

3
  • +1 But while the top answer on that question, with the metaphor of traveling a small distance, is very good, Crockford's saying never use delegation. So, allowing for extreme cases, which I assume he'd allow for too, can we generally ignore the inefficiencies? Is the extreme case hundreds of objects or millions? Commented Dec 20, 2014 at 17:27
  • Never say never. You learn the rules so that you know when it is appropriate to break them. That way, you can use your own judgment, and don't have to depend on some old codger to tell you how to think. Commented Dec 20, 2014 at 17:29
  • 2
    @CarlSmith one possible rule is "never ever delegate... until you find an actual performance/memory issue. Then delegate willy nilly." Commented Dec 20, 2014 at 18:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.