Extending JavaScript Natives

Most built-in JavaScript types are constructors whose prototypes contain the methods and other properties that define their default behavior:

//(results will vary by browser)

Object.getOwnPropertyNames(Function.prototype)
//["bind", "arguments", "toString", "length", "call", "name", "apply", "caller", "constructor"]

You can’t delete or replace a native prototype, but you can edit the values of its properties, or create new ones:

//create a new array method that removes a member
Array.prototype.remove = function(member) {
  var index = this.indexOf(member);
  if (index > -1) {
    this.splice(index, 1);
  }
  return this;
}

['poppy', 'sesame', 'plain'].remove('poppy'); //["sesame", "plain"]
['ant', 'bee', 'fly'].remove('spider'); //["ant", "bee", "fly"]

Et voila! Our code gets a useful array extension for free. However if you brag about doing this in production code, expect to get pummeled by a wave of fierce disapproval. Some of it carries weight. Let’s sift the danger from the dogma and try to reach an honest conclusion:

The Opposition

In recent years, multiple criticisms have been leveled against native prototype extension. Here’s an overview:

1. Future-proofing

If future browser versions implement Array.prototype.remove (either because of an upgrade to the EcmaScript standard, or through their own volition), their implementation will be overridden by our custom one, which will not only be less efficient (we can’t manipulate browser engine internals in the service of method optimization) but more importantly, they might have a different, non standard outcome.

A case in point: back in 2005 the Prototype.js framework implemented Function.prototype.bind. Four years later, the Ecma-262 committee (inspired by Prototype.js) included Function.prototype.bind in their ES 5 specification. Unfortunately for Prototype.js users, the new ES 5 standard required additional functionality, which was not supported by the elegantly simple Prototype.js version — for example ES 5 specifies that when a bound function is used as the first operand of instanceof, the internal [[HasInstance]] method should check the prototype chain of the original (or target) function.

var myObj = {};
var A = function() {};
var ABound = A.bind(myObj);

(new ABound()) instanceof A;
//true (in browsers which faithfully implement ES5 bind)
//false (in the same browsers but with prototype.js loaded)

Similarly, software that makes use of third-party libraries runs the risk that a native prototype augmentation (home-grown or third-party) could be clobbered (or clobber) an alternate implementation of the same property by another library.

These concerns can be partially mitigated by checking for the existence of a native property before implementing it:

Array.prototype.remove = Array.prototype.remove || function(member) {
  var index = this.indexOf(member);
  if (index > -1) {
    this.splice(index, 1);
  }
  return this;
}

This solution depends on simultaneous adoption of new functionality across browsers. If the Chrome browser implemented Array.prototype.remove first, then all other browsers would still fall back on the home-grown implementation which may do something entirely different. For the same reason Prototype.js would have a problem with this strategy: since Array.prototype.bind is not implemented in IE versions 8 and earlier, those browsers would fall back on Prototype.js’s more limited functionality.

NOTE: as of Prototype 1.7.1, all functions that are also defined by ES 5 should be compliant with that specification

2. The for in loop

A secondary grumble, commonly heard but harder to justify, is that extending natives messes with the object iteration cycle. The argument goes like this: since for in loops will visit all enumerable properties in the object’s prototype chain, custom native properties will unexpectedly be included in such iterations:

Object.prototype.values = function() {
  //etc..
};

//later..
var competitors = [];
var results = {'Mary':'23:16', 'Ana':'21:19', 'Evelyn':'22:47'};
for (var prop in results) {
  competitors[competitors.length] = prop;
}

competitors; //["Mary", "Ana", "Evelyn", "values"]!!

There are several reasons to suggest this fear is overblown. First off, the hasOwnProperty method can be used to filter out inherited properties.

var competitors = [];
var results = {'Mary':'23:16', 'Ana':'21:19', 'Evelyn':'22:47'};
for (var prop in results) {
  results.hasOwnProperty(prop) && competitors.push(prop);
}

competitors; //["Mary", "Ana", "Evelyn"]

Second, ES 5 allows properties to be designated as non-enumerable and therefore immune from for in iteration:

//supporting browsers only (not IE version 8 and earlier)
Object.defineProperty(
  Object.prototype, 'values', {enumerable: false});

var competitors = [];
var results = {'Mary':'23:16', 'Ana':'21:19', 'Evelyn':'22:47'};
for (var prop in results) {
  competitors[competitors.length] = prop;
}

competitors; //["Mary", "Ana", "Evelyn"]

By the way, there is no reason* to use a for in statement to iterate arrays — for and while loops offer more convenience, flexibility and certainty — so pollution of for in loops should be a practical concern only when extending Object.prototype.

(*OK, almost no reason – never say never in JavaScript – in the unlikely event that you are burdened by an array which is sparse enough to cause a significant performance overhead – we’re talking very sparse here – then iterating with a for in loop will probably help. But even then, using hasOwnProperty will shield you from inherited enumerables.)

3. Shadowing

When it comes to extending Object.prototype (as opposed to native objects in general) there’s another reason to be wary. Descendants of Object.prototype (i.e. every object whose prototype is not explicitly null) will lose access to the extended property if they happen to define a property with the same name:

Object.prototype.archive = function() {
  //etc..
}

var concerto = {
  composer: 'Mozart',
  archive: 'K. 488'
}

concerto.archive();
//TypeError: Property 'archive' of object #<Object> is not a function

Each time we define a property on Object.prototype we are, in effect, generating an ad hoc reserved term, which is especially perilous when working with objects that pre-date the extension, or libraries we don’t own.

Extending Object.prototype “is Verboten”¹

For some or all of these reasons, the JavaScript community has considered Object.prototype extensions taboo for several years, and you’re very unlikely to see such extensions in production code or respected frameworks. I won’t tell you never to augment Object.prototype but I will tell you that doing so will make you a social pariah.

¹Title borrowed from this namesake article from 2005

What about Host Objects?

Host objects are vendor specific objects that are not covered by the ES standard — principally DOM objects such as Document, Node, Element and Event. Such objects are not well defined by any standard (the W3C standards — including HTML5 — merely talk of interfaces for DOM objects but do not require the existence of specific DOM constructors) and trying to lay ordered extensions on top of officially sanctioned chaos is a recipe for serial headaches.

For more on the perils of extending DOM objects see this fine article by @kangax.

So is Extending Natives ever okay?

I’ve described some reasons for not augmenting native prototypes; you may know of others. You need to decide whether each of these concerns will be addressed by your planned extension, and whether the extension would add power and clarity to your codebase.

Code shims (also known as polyfills) present a good case for extending natives. A shim is a chunk of code designed to reconcile behavioral differences across environments, by supplying missing implementations. ES 5 support is patchy in older browsers, in particular IE version 8 (and earlier), which can be frustrating for developers who want to take advantage of the latest ES 5 features (such as Function.prototype.bind and the higher order array functions: forEach, map, filter etc.) but also need to support these older browsers. Here’s an extract from a popular ES 5 shim (with the comments removed):

//see https://github.com/kriskowal/es5-shim

if (!Array.prototype.forEach) {
  Array.prototype.forEach = function forEach(fun /*, thisp*/) {
    var self = toObject(this),
        thisp = arguments[1],
        i = -1,
        length = self.length >>> 0;

    if (_toString(fun) != '[object Function]') {
      throw new TypeError(); // TODO message
    }

    while (++i < length) {
      if (i in self) {
        fun.call(thisp, self[i], i, self);
      }
    }
  };
}

The first statement checks if Array.prototype.forEach is already implemented and bails if it is. Our other bases are covered too: all properties added to native prototypes are defined by the ES 5 standard so its safe to assume they will not collide with unrelated namesake properties in the future; no ES 5 property extends Object.prototype so pollution of for in enumerations should not occur; every ES 5 property is well documented so there is no reason for ambiguity as to how the shim should be implemented and it’s clear which names are effectively reserved by the ES 5 standard (“bind”, “forEach” etc.).

Shimming ES 5 extensions makes a lot of sense. Without them we’re hostage to the inadequacies of lesser browsers and unable to take advantage of the language’s standard utility set. Yes, we can make use of the equivalent functionality offered by well written libraries like underscore.js, but still we’re locked into non-standard, inverted signatures in which methods are static and objects are merely extra arguments – an ungainly arrangement for an instance-only language. At some point all supported browsers will be ES 5 compliant, at which point the shimmed codebase can simply remove it’s shim library and carry on, while the unshimmed one must choose between a major refactor or a perpetually non-standard and static utility library.

NOTE: It’s not all a bed of roses. Some ES 5 methods are impossible to implement correctly using JavaScript in older browsers and must either fail silently or throw an exception. Others (such as Function.prototype.bind) have a lot of edge cases that take many code iterations to get right. As Kris Kowal says of his own ES 5 shim library “As closely as possible to ES5 is not very close. Many of these shims are intended only to allow code to be written to ES5 without causing run-time errors in older engines. In many cases, this means that these shims cause many ES5 methods to silently fail. Decide carefully whether this is what you want.”

And then there’s one last thing to worry about…

4. What if everyone did it?

Should you decide its okay to augment a native prototype, another problem arises: other library providers might reach the same conclusion. Care must be taken not to include libraries whose prototype extensions collide with yours; the safest solution is to let only one framework (either your base codeline, or an included library) play the role of native extender. In the case of ES shims this should not be hard; you’re unlikely to write the shim yourself so just make sure that only one external shim library is included.

Sandboxing

What if we could have our own private Array, String or Function object that we could extend and use on demand, without messing up the global version? As @jdalton explains, there are various techniques for creating sandboxed natives, the most browser-neutral one uses an IFRAME:

//Rough and ready version to illustrate technique
//For production-ready version see http://msdn.microsoft.com/en-us/scriptjunkie/gg278167
var sb, iframe = document.createElement('IFRAME');
document.body.appendChild(iframe);
sb = window.frames[1];

//later...
sb.Array.prototype.remove = function(member) {
  var index = this.indexOf(member);
  if (index > -1) {
    this.splice(index, 1);
  }
  return this;
}

//much later...
var arr = new sb.Array('carrot', 'potato', 'leek');
arr.remove('potato');
arr; //['carrot', 'leek']

//global array is untouched
Array.prototype.remove; //undefined

Sandboxed natives, when written well, offer safe cross-browser replications of native extensions. They’re a decent compromise but a compromise just the same. After all, the power of prototoype extensions is in their ability to modify all instances of a given type and provide each of them with access to the same behaviour set. With sandboxing we are required to know which of our array instances are “super-arrays” and which are native. Bugs love such uncertainties. It’s also unfortunate that sandboxed objects cannot take advantage of literal notation, which can make for clunky parameter passing and variable declarations.

Wrap Up

JavaScript is a prototypical language — adding a definition to the prototype makes it immediately available to all instances — and the prototypes of its core objects are well documented and freely available for extension. Moreover everything in JavaScript is an instance and when we are forced (jQuery-like) to wrap our utilities in static wrappers it plays against the language, trapping our utilities within unintuitive, inverted signatures.

Not augmenting native prototypes can sometimes feel like looking a gift horse in the mouth, or as @andrewdupont lead developer of Prototype.js puts it “leaving the plastic on the couch”. Yes, there are compelling reasons to be wary and precautions to take, but there are also situations where its safe, and beneficial to rip away that plastic.

It’s quite possible that you are working in a small team, or on your own, with full control over the programming environment and the ability to change course at short notice. Or maybe your project does not require cross-browser support. Or perhaps (dare I say it) the average development team is just a little more diligent than the fearmongers would credit. String.prototype.trim was a trouble-free extension in many developer codebases long before it made its way into the ES 5 specification, at which point it was fairly easy to add a guard to delegate to native versions where available. And we have short memories. Prototype.js and Mootools did not break the web; far from it. Many great JavaScript projects were built on the shoulders of these frameworks and Prototype’s pioneering extensions created the cow paths which ES 5 subsequently paved to the benefit of the entire community.

A word about dogma. Far too many JavaScript how-tos and style guides proclaim (with miraculous certainty) that augmenting native prototypes is an unspeakable evil, while offering little or nothing in the way of substantive evidence (beyond alarmist warnings about breaking for in loops which in reality were only ever relevant to that relic of bygone age known as Object.prototype.myNuttyExtension). We shouldn’t ask people to follow rules that we can’t explain or propose actions that we can’t defend.

Native extensions are neither right or wrong; as with so much in the JavaScript realm, there’s more grey than black-and-white. The best we can do is get informed and weigh each case on its merits. Be thoroughly aware of the consequences, play well with others, but whenever it makes sense, make the language do the work for you.

Additional Resources

Andrew Dupont: Everything is Permitted (JSConf video presentation)
Juriy Zaytsev (Kangax): What’s wrong with extending the DOM
Juriy Zaytsev (Kangax): Extending Built-in Native Objects, Evil or Not
John David Dalton: Sandboxed Natives: Have Your Cake and Eat It, Too
Kris Kowal: ES 5 Shim
Eric Arvidsson: Object.prototype is verboten

• JavaScript