Function.prototype.bind performance problem solved in JS … (at least for 90% of common cases without partial args)

fast-bind.js

/*jslint indent: 2 */
(function (FunctionPrototype) {
  'use strict';
  var originalBind = FunctionPrototype.bind;
  if (!originalBind.patched) {
    Object.defineProperty(
      FunctionPrototype,
      'bind',
      {
        configurable: true,
        value: function bind(context) {
          var callback = this;
          return arguments.length === 1 ?
              function () { return callback.apply(context, arguments); } :
              originalBind.apply(callback, arguments);
        }
      }
    );
    FunctionPrototype.bind.patched = true;
  }
}(Function.prototype));

@ORESoftware: this checks to see if native bind has had patched set to true, and if not, it replaces native bind with a custom bind. The custom bind does what most people use it for — generating a function that calls an original function with a pre-set this value. If you use it for the lesser use case of partially applying a function with a subset of the formal arguments, however, it falls back to the native implementation.

The main reason is because native bind is relatively slow most of the time (like 1/50th the speed of this code), because of a little-known edge use case for bind. If you call a bound function with new, it acts like a normal constructor function and ignores the bound this keyword (but still includes partial application). Implementing this behavior requires a walk up the prototype chain which is slow when all you really want is to make a bound function.

What is little-known edge use case for bind? Could you please make an example?

function foo() {
   console.log(this.x);
}

var context = { x: 123 };
var boundFunction = foo.bind(context);

boundFunction();     // prints 123
new boundFunction(); // prints undefined

The edge case is the last statement. When boundFunction is called through the new operator, the receiver (this) is set to the object being created by new, not the original context object.

I'm not sure, but this behavior may've been designed to allow constructor functions to take advantage of bind's partial application without the undesired side effect of setting this. For example:

function Car(make, model, year) {
  this.make = make;
  this.model = model;
  this.year = year;
}

var festivaFactory = Car.bind(null /*doesn't matter*/, "Ford", "Festiva");
var oldCar = new festivaFactory(1989);    // {make: "Ford", model: "Festiva", year: 1989}
var newerCar = new festivaFactory(1993);  // {make: "Ford", model: "Festiva", year: 1993}

The code above would not work as intended if the bound function received this == null when invoked through new. Of course, there are other ways of achieving the same effect.