On: How JavaScript Works: deep dive into call, apply, ...

[hajile]

There is literally NO substitute for either call or apply as they are low-level JS primitives. Arrow functions can go a long way toward handling .bind() scenarios, but I believe there are situations where you must still use .bind() to prevent constantly creating new functions (and the related garbage).

[wruza → hajile]

.bind() does create a new function, though it has far less “slots” than a regular one. It doesn’t modify the original function. The spec doesn’t specify anything beyond that, afair, and if binds aren’t cached in some way (easy to check with === or roll up your own cachedBind()), GC barely can make any benefit out of collecting slightly smaller objects (but the interpreted part of a runtime may still process bound functions a little faster than closures doing the same thing).

As of source code or p-code or by whatever structure {<code>} body is represented inside, it is always* static for all closures, so there is no overhead apart from a closure itself between:

  function foo() {<code>} // func
  for (;;) foo()

and

  let i = 0
  for (;;) {
    let j = 0
    function foo() {i++; j++; <code>} // closure
    foo()
  }

Because {…<code>} is a singleton in both snippets.

* of course jit may blur this distinction a lot, but that’s unrelated

[bluepnume → hajile]

Show me some code you can only write using either call, apply, or bind.

[wruza → bluepnume]

Anything that substitutes ‘this’ but doesn’t want to put a function into that object.

  const {filter} = []
  class Foo {
    less() {
      return filter.call(this, sometest)
    }
  }

There is no way to closure it somehow without (temporarily) modifying an instance of Foo. (The next obvious question is “why” and the answer is “metaprogramming”.)

[bluepnume → wruza]

I would rather re-implement `filter` in a way that is specific to `Foo`, than to attempt to use an array method on my class.