Skip to content
Advertisement

Why is extending native objects a bad practice?

Every JS opinion leader says that extending the native objects is a bad practice. But why? Do we get a perfomance hit? Do they fear that somebody does it “the wrong way”, and adds enumerable types to Object, practically destroying all loops on any object?

Take TJ Holowaychuk‘s should.js for example. He adds a simple getter to Object and everything works fine (source).

Object.defineProperty(Object.prototype, 'should', {
  set: function(){},
  get: function(){
    return new Assertion(Object(this).valueOf());
  },
  configurable: true
});

This really makes sense. For instance one could extend Array.

Array.defineProperty(Array.prototype, "remove", {
  set: function(){},
  get: function(){
    return removeArrayElement.bind(this);
  }
});
var arr = [0, 1, 2, 3, 4];
arr.remove(3);

Are there any arguments against extending native types?

Advertisement

Answer

When you extend an object, you change its behaviour.

Changing the behaviour of an object that will only be used by your own code is fine. But when you change the behaviour of something that is also used by other code there is a risk that you will break that other code.

When method are added to the object and array classes in javascript, the risk of breaking something is very high – due to how javascript works. Long years of experience have taught me that this kind of stuff causes all kinds of terrible bugs in javascript.

If you need custom behaviour, it is far better to define your own class (perhaps a subclass) instead of changing a native one. That way you will not break anything at all.

The ability to change how a class works without subclassing is an important feature of any good programming language, but it is one that must be used rarely and with caution.

Advertisement