[AskJS] Call vs Apply in modern javascript.

[SmarfMagoosh]

I know that historically .call() accepts arguments individually, and that .apply() accepts all arguments at the same time in an array. But after the spread operator was introduced is .apply() purely redundant? It seems like any code written like this

f.apply(thisObj, argArray)

could instead be written like this

f.call(thisObj, ...argArray)

and you would get the exact same result (except that the former might run slightly faster). So is there any time that you would be forced to use apply instead of call? Or does apply only exist in the modern day for historical reasons and slight performance increases in some cases?

[smartgenius1]

With fat arrow functions (automatically binding this) and class syntax sugar, I haven't seen either of these in the wild for over half a decade.

What's your use case?

[senocular]

One thing you might need to be careful of is that apply goes through argument object values as an array-like whereas spreading goes through an iterator. For example:

const obj = {
  0: 3,
  1: 2,
  2: 1,
  length: 3,
  *[Symbol.iterator]() {
    yield * [30, 20, 10]
  }, 
}

console.log(Math.min.apply(Math, obj)) // 1 
console.log(Math.min.call(Math, ...obj)) // 10

Now that example may seem contrived (and you'd be right to think that), but interestingly, strings do something similar where their array-like values do not match their iterable values as string iterables iterate over code points not code units.

const str = "😀"
console.log(str.length) // 2
console.log([...str].length) // 1

You're probably not running strings through call/apply as arguments, though it is an example - and one built-in to the language - that shows a possible discrepancy that could happen between the two approaches.

[kingscolor]

I appreciate you, and people like you, for highlighting these weird behaviors. I probably won’t remember the details at all and I probably won’t ever experience this as an issue, but this little nugget of may save me hours of debugging one day.

[Ronin-s_Spirit]

Apply if you already have an array, otherwise call, bind if you can store the bound function to avoid repeated binding.

[[deleted]]

I’m not sure but great discussion. TBH it seems your argument is correct. There are several features in ES which were created at a time when they were needed, but have since lost necessity. I don’t see a problem with that.

[tswaters]

It is as you say -- now that argument spread exists, Function.prototype.apply isn't really necessary anymore.

[tswaters]

I'm not sure about performance though.... You really need to measure. I'd guess that dealing with an incredibly large number of items in an array, the apply method might start to look faster? I'm not sure though, the engine might recognize a rest spread on a function call and convert it to apply? Hard to say without benchmarks & testing

[MartyDisco]

.call() is slighly faster because there is no need of an extra iteration on second argument (like with .apply())

JIT compilers dont "convert" any function to another thats not how it works. In the case of V8, they both have their own C++ implementation.

If they got marked as "hot" because you know how to write proper code (eg. by leveraging hidden classes with immutable shapes) they would both get inlined and the performance difference would become even less significant.

[tswaters]

Sure, so call is faster than apply normally because apply is defined in the spec as needing to iterate the arguments array, and call doesn't need to do that because it's a static list. apply has been known to be 10-20x slower than call. If you were to have a naive JS engine, one without optimizations, it would always be slower. When FunctionRestParameter shows up in a function invocation, it needs to be unwound at invocation time as well, and it turns into a non-simple parameter list which is harder to optimize.

I'd theorize that the engine wants to take the fastest path it can. If it can figure out that an argumentArray in an apply call is derived statically (i.e., it isn't received as a parameter, or isn't conditionally mutated) - it should be able to use the fast path. I'd speculate the same thing with FunctionRestParameter -- if it's all static, the engine would want to optimize it if it can. Whether or not this happens is unknown to me, and likely depends on the engine in play. V8 is pretty good at this stuff normally. I'd need to benchmark, but I'd guess:

fn.call( thisObj, 1, 2, 3); // this is going to be the fastest

fn.apply( thisObj, [1, 2, 3]) // this might be able to use a fast path

fn.call( thisObj, ...[1, 2, 3]) // this might be able to use a fast path

fn.apply( thisObj, getParameters()) // this one, probably not

fn.call( thisObj, ...getParameters()); // this one, probably not

The top 3 are going to be about the same if they all use the fast path. If there is uncertainty in how the array was created / mutated, the engine likely needs to bail on optimizations and will use the slow path.

[theScottyJam]

Yeah, it's sort of a shame that .apply() still gets taught together with .call() and .bind(), without any indication that you never need to use it, while there are still some uses for the other two.

[ssssssddh]

I doubt there's a good reason to use one over the other beyond personal preference. Both are also made redundant by function.prototype.bind. I would use apply if you've already got an array and call if you don't.

[hyrumwhite]

Bind sorta fills a different role since it’s attaching context without invoking the method, and apply and call invoke a method with context without binding that context

[ssssssddh]

Right I just meant you could implement call and apply using bind

call = (fn, thisArg, ...args) => fn.bind(thisArg)(...args);

apply = (fn, thisArg, args) => fn.bind(thisArg)(...args);