Oddly, I never saw this construct much until recently (late 2015). I suppose that's because the problem it solves wasn't common before promises arrived on the scene and people wanted to pass console.log around for debugging purposes. When it did start showing up, I was perplexed. I am 100% comfortable with the details of the bind() function and why to use it. I could not, for the life of me, understand why it was needed here.
The answer:
It's not needed. I tried to get the behavior discussed below in a few contexts and it appears that console.log has been revised so that this isn't needed. Or, maybe it is. I didn't do a comprehensive check of the entire world.
Well, then, wtf?
Turns out that, in some previous world (perhaps some browsers today that I don't have the patience to experiment with), console.log() contains a reference to it's own this which is lost in a simple function assignment. IE...
If you, for some reason, want to pass the function console.log around, eg,
var xxx=console.log
xxx('message');
It won't work. The console.s log() method refers to this.something that isn't a part of it's new, post assignment 'this' (ie, the global scope, which is 'this' when nothing else is applicable).
That is, if you could magically add console.dir(this) to console.log, you would get something in this spirit...
{
log:function,
somethingElse:godKnowsWhat
}
But, if you were magically able to get that same console.dir(this) after the assignment to xxx, it would produce something like this...
{
//global scope items that do not include anything name somethingElse
}
The construct in question specifies the value of this for the newly assigned xxx
var xxx=console.log.bind(console);
That is, it will be bound to its original 'this', (ie, this===console) and it will be able to find whatever somethingElse it needs.