10

Similar to, but different from this question. The code below is from JavaScript: The Definitive Guide. He's basically defining an inherit method that defers to Object.create if it exists, otherwise doing plain old Javascript inheritance using constructors and swapping prototypes around.

My question is, since Object.create doesn't exist on plenty of common browsers IE, what's the point of even trying to use it? It certainly clutters up the code, and one of the commenters on the previous question mentioned that Object.create isn't too fast.

So what's the advantage in trying to add extra code in order to occasionally utilize this ECMA 5 function that may or may not be slower than the "old" way of doing this?

function inherit(p) {
   if (Object.create) // If Object.create() is defined...
      return Object.create(p); // then just use it.

   function f() {}; // Define a dummy constructor function.
   f.prototype = p; // Set its prototype property to p.
   return new f(); // Use f() to create an "heir" of p.
}
Community
  • 1
  • 1
Adam Rackis
  • 82,527
  • 56
  • 270
  • 393

1 Answers1

9

The speed difference is not very noticeable, since by nature you probably won't be creating too many objects (hundreds, even thousands isn't what I call a lot), and if you are and speed is a critical issue you probably won't be coding in JS, and if both of the above aren't true, then I'm sure within a few releases of all popular JS engines the difference will be negligible (this is already the case in some).

In answer to your question, the reasons aren't speed-related, but because the design pattern of Object.create is favoured to the old method (for the reasons outlined in that and other answers). They allow for proper utilisation of the ES5 property attributes (which make for more scalable objects, and thus more scalable apps), and can help with inheritance hierarchies.

It's forward engineering. If we took the line of "well it isn't implemented everywhere so let's not get our feet wet", things would move very slowly. On the contrary, early and ambitious adoption helps the industry move forward, helps business decision makers support new technologies, helps developers improve and perfect new ideas and the supporting frameworks. I'm an advocate for early (but precautionary and still backward-compatible) adoption, because experience shows that waiting for enough people to support a technology can leave you waiting far too long. May IE6 be a lesson to those who think otherwise.

davin
  • 44,863
  • 9
  • 78
  • 78
  • That's a really helpful answer; I can see why create would be preferable, since it gives you a lot of control over the properties in the object that's created. I can see why you'd want to say `var bob = Object.create(userB, { "id": { value: 12, enumerable: false` and so on, but won't this code crash violently in IE9 and below? Wouldn't code like that be limited to (wonderful) situations where you can control the browser your users are using? – Adam Rackis Sep 21 '11 at 22:38
  • In other words, in IE8 not only am I going to have to get my new inherited method by using the old JS method of swapping prototypes around, but I'm also going to have to change the object that's passed in to serve as the "child" object that inherits from userB. Instead of `{ "id": { value: 12, enumerable: false` won't I need `{ "id" : 12, "name": "bob"` and so on? – Adam Rackis Sep 21 '11 at 22:41
  • @AdamRackis, that's true, the code as-is is not backward compatible, but I'm sure there are projects that try and streamline these things. If not, it's a good idea. It wouldn't be that hard to automate those changes. – davin Sep 21 '11 at 22:46
  • Indeed - I'm sure it wouldn't take much to go through the object and map it onto an ECMA3 compat object. Thank you for taking the time to answer this. You really helped it click. I just with the Q was higher traffic so you could score some more $$ – Adam Rackis Sep 21 '11 at 23:52