4 ms·

Hyperbole much? Those aren't "very good reasons" to avoid an entire, useful language feature! I would like to know how exactly you find it's performance to be "

Hyperbole much? Those aren't "very good reasons" to avoid an entire, useful language feature! I would like to know how exactly you find it's performance to be "abysmal" as I have used it in very high volume streaming code with no problems. The second "problem" is perhaps surprising to a newbie but is not hard to debug.

jondubois 11y ago
I haven't witnessed 'abysmal' performance either. Based on some tests I just ran, calling a bound function is only about 25% slower than calling a non-bound one. That's pretty reasonable. Calling bind() on a function doesn't appear to take that much CPU time either. That said I don't see the applications for currying in JavaScript. It just makes code less readable. It looks like an anti-pattern to me.
- hajile 11y ago
  Are you sure about those numbers (can you show your code?) Every benchmark I've seen shows a much bigger difference. Here's a jsperf (courtesy of the WayBackMachine) that shows a difference of about 20x+ over normal function calls. https://web.archive.org/web/20141121220218/http://jsperf.com/function-calls-direct-vs-apply-vs-call-vs-bind/33 https://web.archive.org/web/20141121220218/http://jsperf.com...
hajile 11y ago
Read the source code for yourself http://v8.googlecode.com/svn/trunk/src/v8natives.js http://v8.googlecode.com/svn/trunk/src/v8natives.js Another interesting example is Babel. In a fat arrow function, they would rather replace every instance of 'this' with a generated variable than add a .bind() to the end strictly based on overall performance. The second problem is surprising for everyone. The only thing you will see is that just before you enter the function, the 'this' is correct and immediately after, the 'this' changes. I've only ever spoke with a handful of devs who know this behavior happens. The biggest issue here is that if I use a third-party library and an external interface ever calls .bind(), then the abstraction will absolutely fall apart in a variety of circumstances. Considering that a simple `var self = this;` works in 99% of cases, I see no reason to encourage programmers to use .bind() in their code.
- juliangregorian 11y ago
  > Read the source code for yourself Please tell me why you throwing reams of source code in my face is relevant. > In a fat arrow function, they would rather replace every instance of 'this' with a generated variable than add a .bind() to the end strictly based on overall performance. Source? Or could it be, shock, that a library that exists for compatibility is targeting environments without a native .bind()? > The second problem is surprising for everyone. It's only surprising for people who have never tried, never read the spec, and don't understand bind(). The spec clearly states that a bound function cannot be overridden. It's really not that difficult. It would be nice if you could provide clear examples of your problems because you're starting to not make sense.
  - hajile 11y ago
    > Please tell me why you throwing reams of source code in my face is relevant. Because the bind function implementation shows why it is so slow. If you read the spec like you imply, then reading one function shouldn't be difficult. You can write your own 'bind' function that skips a bunch of uncommon corner cases and get a huge boost in performance. Deal with the possible edge cases and performance tanks. > Source? Or could it be, shock, that a library that exists for compatibility is targeting environments without a native .bind()? It's not a matter of supporting older browsers. Babel target's IE9+ by default and has optional polyfills and transformers you must add if you want to support JS versions before ES5.1. There was a discussion on Reddit about this very topic a few months ago. The poster got served by the Babel guys and deleted all their posts. Their claim was basically that `(foo) => this.foo` should translate into `function (foo) { return this.foo; }.bind(this)` and that Babel got it wrong. The response from sebmck was "There's no point in using bind when you can just remap all references to this which is significantly faster." [source](https://www.reddit.com/r/webdev/comments/30wwgk/an_overview_of_javascript_in_2015_ecmascript_6/cpxer5w https://www.reddit.com/r/webdev/comments/30wwgk/an_overview_...). If you want to know more on the topic, I'd suggest making a github issue so one of their team members can clarify things for you. > It's only surprising for people who have never tried, never read the spec, and don't understand bind(). The spec clearly states that a bound function cannot be overridden. It's really not that difficult. It would be nice if you could provide clear examples of your problems because you're starting to not make sense. The spec is fairly obscure about thisArg vs [[BoundThis]] and a full understanding encompasses not only a half-dozen user and internal functions, but also requires the reading about environments. This gets even more opaque in the ES2015 spec. That said, 99.5% of JS programmers will never read the spec (the ES5.1 spec is ~300 pages of extremely technical reading while the ES6 spec is ~600 pages and even harder to understand). Here's a made-up example var obj1 = {foo: 3}; var obj2 = {foo: 4}; var add = function (n) { return n + this.foo; }.bind(obj1); add.call(obj2, 3); //=> 6 This may be easier to see in this little example, but if that definition is somewhere in a library and you use a .call() with a `this` that matters, your function will fail. When you step through with the debugger, you will see that your object that you're passing as the `this` is what you expect. When you step into the function, it will have suddenly changed to a different object. I assume the silent failure is because users may want to .apply() a function that is bound for the easy array destructuring, but I think that attempting to rebind the `this` too anything but null or undefined should yield an error of some kind.

jondubois 11y ago

I haven't witnessed 'abysmal' performance either. Based on some tests I just ran, calling a bound function is only about 25% slower than calling a non-bound one. That's pretty reasonable. Calling bind() on a function doesn't appear to take that much CPU time either. That said I don't see the applications for currying in JavaScript. It just makes code less readable. It looks like an anti-pattern to me.

hajile 11y ago
Are you sure about those numbers (can you show your code?) Every benchmark I've seen shows a much bigger difference. Here's a jsperf (courtesy of the WayBackMachine) that shows a difference of about 20x+ over normal function calls. https://web.archive.org/web/20141121220218/http://jsperf.com/function-calls-direct-vs-apply-vs-call-vs-bind/33 https://web.archive.org/web/20141121220218/http://jsperf.com...

hajile 11y ago

Read the source code for yourself http://v8.googlecode.com/svn/trunk/src/v8natives.js http://v8.googlecode.com/svn/trunk/src/v8natives.js Another interesting example is Babel. In a fat arrow function, they would rather replace every instance of 'this' with a generated variable than add a .bind() to the end strictly based on overall performance. The second problem is surprising for everyone. The only thing you will see is that just before you enter the function, the 'this' is correct and immediately after, the 'this' changes. I've only ever spoke with a handful of devs who know this behavior happens. The biggest issue here is that if I use a third-party library and an external interface ever calls .bind(), then the abstraction will absolutely fall apart in a variety of circumstances. Considering that a simple `var self = this;` works in 99% of cases, I see no reason to encourage programmers to use .bind() in their code.

juliangregorian 11y ago
> Read the source code for yourself Please tell me why you throwing reams of source code in my face is relevant. > In a fat arrow function, they would rather replace every instance of 'this' with a generated variable than add a .bind() to the end strictly based on overall performance. Source? Or could it be, shock, that a library that exists for compatibility is targeting environments without a native .bind()? > The second problem is surprising for everyone. It's only surprising for people who have never tried, never read the spec, and don't understand bind(). The spec clearly states that a bound function cannot be overridden. It's really not that difficult. It would be nice if you could provide clear examples of your problems because you're starting to not make sense.
- hajile 11y ago
  > Please tell me why you throwing reams of source code in my face is relevant. Because the bind function implementation shows why it is so slow. If you read the spec like you imply, then reading one function shouldn't be difficult. You can write your own 'bind' function that skips a bunch of uncommon corner cases and get a huge boost in performance. Deal with the possible edge cases and performance tanks. > Source? Or could it be, shock, that a library that exists for compatibility is targeting environments without a native .bind()? It's not a matter of supporting older browsers. Babel target's IE9+ by default and has optional polyfills and transformers you must add if you want to support JS versions before ES5.1. There was a discussion on Reddit about this very topic a few months ago. The poster got served by the Babel guys and deleted all their posts. Their claim was basically that `(foo) => this.foo` should translate into `function (foo) { return this.foo; }.bind(this)` and that Babel got it wrong. The response from sebmck was "There's no point in using bind when you can just remap all references to this which is significantly faster." [source](https://www.reddit.com/r/webdev/comments/30wwgk/an_overview_of_javascript_in_2015_ecmascript_6/cpxer5w https://www.reddit.com/r/webdev/comments/30wwgk/an_overview_...). If you want to know more on the topic, I'd suggest making a github issue so one of their team members can clarify things for you. > It's only surprising for people who have never tried, never read the spec, and don't understand bind(). The spec clearly states that a bound function cannot be overridden. It's really not that difficult. It would be nice if you could provide clear examples of your problems because you're starting to not make sense. The spec is fairly obscure about thisArg vs [[BoundThis]] and a full understanding encompasses not only a half-dozen user and internal functions, but also requires the reading about environments. This gets even more opaque in the ES2015 spec. That said, 99.5% of JS programmers will never read the spec (the ES5.1 spec is ~300 pages of extremely technical reading while the ES6 spec is ~600 pages and even harder to understand). Here's a made-up example var obj1 = {foo: 3}; var obj2 = {foo: 4}; var add = function (n) { return n + this.foo; }.bind(obj1); add.call(obj2, 3); //=> 6 This may be easier to see in this little example, but if that definition is somewhere in a library and you use a .call() with a `this` that matters, your function will fail. When you step through with the debugger, you will see that your object that you're passing as the `this` is what you expect. When you step into the function, it will have suddenly changed to a different object. I assume the silent failure is because users may want to .apply() a function that is bound for the easy array destructuring, but I think that attempting to rebind the `this` too anything but null or undefined should yield an error of some kind.