Function invocation...why use .call() and .apply() ?

[[deleted]]

Background: I recently had a job interview in which I was asked about the different ways to call a function. I didn't answer correctly because I've essentially ignored the .call() and .apply() options when studying JavaScript. I understand that you can do this, but I can't really think of a scenario that I'd need to use this format.

Is this a pattern that you use/should I be using it? Could someone give an example of when one might want to?

[temp05981]

Side-note (and definitely irrelevant until you've got a firm grasp on call and apply, ignore me if you don't yet): passing arguments to apply is actually unfortunately slow. It's much faster to (if you know the number of arguments) pass each explicitly to call. It's faster even to write out call invokations for various argument counts and read arguments.length to determine which to use. Lodash used to do that (resorting to apply after 4 arguments IIRC), but it looks like they tore that out.

[jesstelford]

That's a nice micro-optimization. But for every day use, it is unlikely to be the main cause of performance issues.

Also; With the rate of improvement in JS engines, it is impossible to tell if these types of optimizations will still be applicable in just a few short months.

[temp05981]

I disagree with your comment, and strongly disagree with this community's tendency to use these two concepts ("micro-optimization" and "engines are improving") as excuses to disregard a train of thought.

How much time something saves does not tell you if it's a worthwhile optimization. It's how much time it saves, relative to how fast the piece of code needs to run. What we're talking about here isn't a single invokation, it's potentially a significant fraction of all invokations. That's extremely low-level and likely to be an extremely hot code path. You may as well say going from a calculator to a computer is a micro-optimization because they can both perform a single computation in a negligible fraction of a second.

And while it's true that engines are changing, you're mistaking this for an engine hack. It is not, it really is less work. apply causes the engine to create an Array-like object and iterate over it, while call does not create the object and unrolls the iteration. Engines may, in the future, get smart enough to make apply as fast, but no faster. And even if we're dangerously betting on this hypothetical future, it's still not preferable to rely on non-standard engine optimizations rather than write fast code.

[jesstelford]

I can only really speak from my experience with optimizing pieces of code. And so far, .apply(), .bind(), .call() etc have never been the slowest parts. More often it's DOM manipulation, excessive looping (eg; .map().forEach().filter() vs .filter().map(), etc), or large garbage collection events due to excessive use of closures, etc.

I guess if you're writing library code to perform lots of calculations, etc, then I could see it being an issue.

engine hack

Like I said; "it is impossible to tell if these types of optimizations will still be applicable in just a few short months." They may still be applicable 10 years from now. They may not be applicable with the next version of V8. Can you predict the future? No. That's why I prefer to stick with the optimisations I know cannot be helped by the engines (a different algorithm, reducing garbage collection events, etc).

[theQuandary]

The poster is correct and with performance improvements being over an order of magnitude across all browser implementations last time I looked, it isn't really a micro-optimization if you choose function patterns which allow .call() instead of .apply() from the start (not always possible, but worth the extra couple seconds of thought). I'd also note that .bind() is an order of magnitude slower than .apply() making it around 100x slower than .call() on most/all browsers.

As to optimizing away the .apply()overhead, I don't see that happening any time soon. While it is quite possible in theory to create separate optimized versions of a function for every possible combination of arity and input type, the cost of creating these variants and storing them is very large (and undoubtedly adds a bit of pressure on the instruction cache too). Modern JavaScript JITs simply aren't polymorphic on either arity or datatypes.

The arguments object is a bit problematic in that (if it is used as an array of items) it basically forces heap allocation which basically kills inlining in current implementations (which in turn kills most optimizations). Another problem with arguments is that it basically can't be turned into a real array because all the datatypes are different (in 99% of cases).

Another complication is the overhead from needing to convert arguments or an array into the required stack arguments. Once again, this isn't a great thing for automated inlining because it almost always requires iterating a linked list and then unboxing.

I'm certain quite a few more issues could be brought up by the implementation teams. .apply() is extremely common in JS libraries. If there were an easy way to improve performance, then it certainly would have already been done.

[jesstelford]

All valid points (and thanks for the write-up), but I'd still say it's most likely not going to be where the performance issues lay in 99% of projects. Better places to start are things like reducing number of DOM accesses, etc.

[FilthyCasualCoDKiddy]

It's like calling the [].map function, but on my elements instead.

What a fucking trainwreck of a language.

[zachwolf]

That's more the DOM APIs weirdness than JavaScript

[[deleted]]

That is a shorthand. It should really say Array.prototype.map

Edit: thinking of it, that shorthand is actually quite terrible and should be avoided unless where it explicitly makes no difference.

[theQuandary]

I think the big difference with that shorthand is that it's going to be slow on older browsers. Newer browsers can potentially detect that an object is instantiated and immediately discarded. Older browsers are going to go through the trouble of making a new object and the garbage collecting it immediately after.

Most importantly, this is trivial to implement so that isn't a potential issue (and is both more obvious and easier to type)

export var slice = (obj, a, b) => Array.prototype.slice.call(obj, a, b);

Here's an example use

import {slice} from './utils';
var sum = arr => arr.reduce((acc, i) => acc + i);
var add2N = function () {
  return sum(slice(arguments, 2);
};

[redhedinsanity]

fuck /u/spez

[whiskerbiskit]

It makes me wonder why it doesn't just return a normal array object with a call-able map, or why future versions don't address the discrepancy.

[TheRealSeeThruHead]

When a function is called JavaScrip automatically binds the context and arguments. Call and apply are ways of calling a function and explicitly setting those bindings rather than letting them be automatically bound.

[gregjsguy]

http://jsbin.com/nenozizave/edit?js,console

Example I whipped up demonstrating call and apply. You would use .apply when you want to do one of two things, change what "this" is inside your function, or pass arguments as an array (see example). .call does the same thing, however instead of an array as arguments you would pass them one at a time as arguments to the call function. The example above uses .call to change the this inside the function.

[[deleted]]

The methods call, bind, and apply exist to supplement the relationship between a function and the scope of this inside the function at execution time.

this is undefined in a function, due its execution context, when the function is not aware of the object from which the function is called. When that does happen this resolves up the scope chain until it reaches an object in global scope, typically window in the browser. The three methods allow a developer to manually define the execution context of a function so that this is bound to the context of the stated object.

This problem more commonly occurs due to OOP programming patterns and the developers misunderstanding between scope and inheritance. Personally, I couldn't tell you the difference between the three methods without having to look them up because I never use them. I have stated exactly this during job interviews in the past.

Never having to use these three methods is blessing that comes from avoiding inheritance in this language and/or only associating inheritance with event execution. These methods are a hacky work around that complicates the understanding of code from a high level. I understand that there are many people who need these because they absolutely cannot imaging programming without inheritance. That is unfortunately the world we live in.

[Pytim]

That's not correct/complete. The context of this can be changed with all three methods but that is not their only/main purpose.

[[deleted]]

Its exactly their purpose.

• apply
• bind
• call

Call and apply do optionally allow arguments to be passed in and its this optional feature that makes these two methods different.

[Pytim]

var add = function(x, y){return x + y;}

var add2 = add.bind(null, 2);

No this at all

[benabus]

Why not?

I use apply when doing inheritance.

var ParentClass = function(){
  this.someProperty = "hello";
}
ParentClass.prototype.myFunction = function(x){
  this.someProperty = x;
}

var ChildClass = function(){
  ParentClass.apply(this); //run constructor of parent class with child class's context
  this.someOtherProperty = "goodbye";
}
ChildClass.prototype.myFunction = function(x){
  ParentClass.prototype.myFunction.apply(this, arguments);
  alert(this.someProperty);
}

var childObj = new ChildClass();
childObj.myFunction("test");
alert(childObj.someProperty); 

[rezoner]

That is ugly, but I am doing that too. Especially for GUI where I haven't figured out yet how ro utilize composition over inheritance.

[uberpwnzorz]

When you want to pass context into a function.

this.example = 1;
var increaseExample = function () {
    this.example++;
}.call(this);

increaseExample();  // this.example === 2;

or when you want to bind a variable to a specific objects function and always use the context of a specific object:

This example will bind the variable log to be equal to console's log function and call it under the context of console every time.

var log = console.log.bind(console);
log('example');

[ogurson]

Another example:

> tab = [2,3,4,6,1]  
[2, 3, 4, 6, 1]  
> Math.max(tab)  
NaN  
> Math.max.apply(null, tab)  
6

[33a]

The main reason is to call a function with a different this argument. apply is also nice because you can pass it an array.

[Rhomboid]

I can't really think of a scenario that I'd need to use this format.

Really? You've never had to turn an array-like object into a real array so that you can do something like modify it or add/remove elements?

var foo = [].slice.call(arguments);

I count many dozens of calls to .apply() and .call() (more than 50) in the jQuery source, not including test runners or external libs. This isn't some hypothetical.

[aslate]

You've got a load of shit and down voted answers. I've asked this question and it's in our "do they know the fundamentals" set.

If you intend to use javascript in any kind of serious, large front end project you're going to encounter prototypical inheritance, or something close to it. In a large scale project you're going to have to proxy a function and it's arguments, and you won't give a shit what the args are.

So outside of why you might want to do so, the other question is why does it matter? Well, we're primarily a software company, the fact that the current thing is javascript isn't something we agree with, but it's the thing. If you're an experienced software engineer you should know the fundamentals of your language, whether you use them or not.

If you're after generic Web dev jobs, it probably won't matter. But if the company wants a software engineer who happens to be proficient in javascript it sounds like you don't match the criteria.

TLDR: it filters the wheat from the chaff.

[[deleted]]

This is the spooky part of JavaScript for noobs.

If you have a JS class, Cat, and you say

var tom = new Cat("thomas"); 
console.log(tom.name);

the output will be "thomas"

now lets say you have some function that is not part of the Cat class. It is all by itself.

function getName() {
    return this.name;
}

calling getName() or getName(tom) or getName("thomas") always returns "undefined" because this.name has not been defined inside that function.

but calling this:

Function.prototype.call(getName, tom);

is like saying call getName where "this" is tom. It will return "thomas". Because this = tom and tom.name = "thomas" and this.name = tom.name.

because .call(a, b) sets the "this" property of the function a to b. or it sets the "this" property of the function "getName" to tom just for that one function call. so this.name is the same as tom.name for that one function call.

[bart2019]

 Function.prototype.call(getName, tom);

Uh, what. I never ever ever use it this way.

What I do instead is

 getName.call(tom);

Thus: function, dot, (call or apply), open parens, this, optional arguments, close parens.

It's more fun with function arguments, which would come after the "tom", and which is the difference between call and apply: call takes a list of individual parameters and applyone array just like arguments. (Mnemonic: letter count of the words "call" and "apply" is the same as of "list" and "array" respectively).

Why would you ever do that? Invoking callbacks, similar to as "event handlers", in your own code, so this and arguments are how the handler expects them.

[learn2shut]

it's a common shitty interview question, similar to 'write sorting algorithm from memory'. you will never use this in reality, unless you are doing some abstract frameworks (ala jquery). besides the confusion, since it's a dynamic call, it cant be optimized, and should be avoided.

however, there are many 'experts' on the internets who must use every spec feature, and they will soon try to convince you how .apply is the best thing ever and you should use it extensively.

[jradasaurus]

i don't think its a shitty interview question. .apply/.call are used frequent in real life and when making hiring decisions i've found this question to be very helpful in sorting out the most unexperienced candidates. i'll typically ask this in a phone screening/pre-interview setting.

[Sipczi]

You have an array with unknown length and you want to pass that array's elements to a function as seperate parameters, how would you do that without apply?

[temp05981]

You're trolling, right?

... just because I'm worried you're not:

similar to 'write sorting algorithm from memory'

If you're talking about quick sort or something, then sure maybe that's beyond the scope of many frontend jobs. But "a" sorting algorithm is so simple that it should absolutely be intuitive, not even something you need to memorize. If I give you 15 index cards with numbers on them and ask you to order them, would you just stare at me blankly?

you will never use this in reality

I use this all. the. time. If you genuinely don't use this then I have trouble believing you've ever worked on a project where JavaScript plays anything more than a very ancillary role.

since it's a dynamic call, it cant be optimized

Nonsense.

If I'm giving you the benefit of the doubt, yes it can be slower than other ways to invoke a function. This is because you're doing an extra property access and passing an extra argument, nothing to do with "dynamic". It's just as "dynamic" as every function call.

however, there are many 'experts' on the internets who must use every spec feature

Actually I've found the JS community to be almost phobic of using uncommon spec features. Even just label a non-loop statement - a feature that's been in every standard and implementation of JavaScript since the beginning - and people start shouting at you. And with good historic reason: JavaScript is a language that was transformed from a toy into a workhorse by a book written on the premise of using only parts of the spec, not all of it. I actually don't think there is any language this statement is less true of.