Why do callbacks have to be a function?

Question

I keep on seeing:

() => execute code

instead of just

execute code 

in callbacks. I am not passing in any parameters, so why does () => execute code work but execute code doesn't? Aren't they the same thing since a function just represents some lines of code? I see similar things in other languages as well like java where lambda is used

Thank you.

Answer 1

The difference is that () => console.log('execute code') is a function definition, whereas console.log('execute code') is a function invocation.

The code within the body of a function definition does not run until the function is invoked.

var double = (num) => console.log(num + num) // function definition, does nothing

double(2) // function invocation, logs 4 to the console

When you pass a function definition in as an argument to a function invocation, you are making the passed in function definition available to be accessed or called within the body of the invoked function.

Conversely, if you pass a function invocation, say, double(2) in as an argument to another function invocation, you are making the return value of double(2) (in this case undefined since console.log has no return value) available in the body of the function it is being passed into.

Example:

var double = (num) => console.log(num + num)

var invokeCallbackAfterFiveSeconds = (callback) => {
  setTimeout(callback, 5000);
};

//Passing in a function definition below...

invokeCallbackAfterFiveSeconds(() => double(3));
// ^ Will log 6 to the console after a five second delay


//Passing in a function invocation below...

invokeCallbackAfterFiveSeconds(double(4));
// ^ Will log 8 to the console immediately, then do nothing else.

Answer 2

Callbacks are used because the function needs to be called -- the code needs to execute — at some indeterminate point in the future. Simply executing code in javascript will always execute it immediately. This is not helpful if you need to perform some asynchronous task and then do something.

For example, setTimeout() takes a callback because it needs to wait, and then do something:

//In  about 1500 ms setTimeout will call this ()=>{} function
setTimeout(() => {
  console.log("finished")
}, 1500)

Being able to pass a function like this is very flexible, because the function can also take arguments and return values which can be determined at the time the function is called. That would be much harder or not possible if the code was not organized in a function.

If I just pass in an expression directly, it executes immediately:

// console.log runs immediately, there's not way to defer it.
    setTimeout( console.log("finished")
    , 1000)

So the function doesn't just represent some code, it represents an action that can be called. It can be called by you, or by another function like setTimeout or a HTTP request at a specific time.

Answer 3

What you are seeing is a function in Javascript, called Arrow Function, and can be written as follows:

Single line if return one operation:

const f = (a,b) => return a+b;

Or block of lines for more operations:

const f = (a,b) => { c = a + b; return c};

Answer 4

The function is needed in order to know that the code should not be executed immediately.
If you would use

myFunction(myArg, window.location.href='https://www.stackoverflow.com');

Instead of

myFunction(myArg, () => {   
    window.location.href='https://www.stackoverflow.com';
});

the language is not able to know that the code should be executed at a later point as callback in the first case. As a consequence it is executed as soon as the method is called wich leads to a boolean beeing passed instead of a function to callback. And in this scenario instead of switching to stackoverflow.com after the execution as callback the page would be opened immediately even if the function called has not run completely.

In short passing a function allows to run the code it contains at a later point by calling it.

Often a parameter with results is passed to the callback in order to allow processing those.

Answer 5

Because if you do it the way you are suggesting, the code will be executed immediately; i.e. when you are making the call.

You need to understand that

() -> doSomething()

and

doSomething()

mean different things (do it later versus do it now) and evaluate to different values. They don't even have the same type. Assuming that doSomething() returns SomeType:

• lambda expression evaluates to an object that is compatible with Supplier<SomeType>, and
• the call evaluates to an object that is compatible with SomeType.

---

I suppose that you think it would be nice if you could use the same syntax for both cases, and have the compiler work out which is the correct meaning depending on the context. There are two problems with this:

1. This would make code much harder to understand. When you were reading someone's code you would need to know whether each parameter of each expression expected something with immediate evaluation semantics (like a method call) or deferred evaluation semantics (like a lambda).

   Back in the 1960's they actually designed and implemented a programming language that worked like this. (Look up Algol-60 and "call by name".) It was a mistake. Algol-60 programs that make use of call-by-name are hard to understand. AFAIK, the mistake has not been repeated in any mainstream programming languages since then.

2. You would still need to declare whether a parameter had immediate or lazy evaluation semantics. I think it would be impossible to infer which was required in a method declaration.