We Keep Coding

Understanding callback function purpose

I realise this is more of a general question, but I've read through similar answers on here but I can't find more of an overview. I'm new to callbacks and I'm trying to understand when they should be used.
The MDN web docs has this example;
function greeting(name) {
alert('Hello ' + name);
}
function processUserInput(callback) {
var name = prompt('Please enter your name.');
callback(name);
}
processUserInput(greeting);
However I'm struggling to see how this is more beneficial than the following, where I'm not passing the greeting function as a parameter?
function greeting(name) {
alert('Hello ' + name);
}
function processUserInput() {
var name = prompt('Please enter your name.');
greeting(name);
}
processUserInput();

As Javascript is async, sometimes it is difficult to handle response from non-blocking functions, for ex. if you are making an ajax call then it'll be executed asynchronously and results will be returned sometime later, by that time the main execution flow will pass the ajax code and starts executing following statements, in that case, its very difficult to catch the response to process further.
To handle those cases, callbacks comes into picture where you pass a function as the parameter to the ajax function and once the response is returned then call the callback by passing response data as a parameter to process further.
more info here http://callbackhell.com/

In simple terms you can say a callback is a way of asking a question (or requesting a task) in advance, i.e. when you're done with this do this (usually with the result). The whole point is to set aside functions that are to be done later, usually because you don't have the required inputs to do them now.
The 2 main differences between your implementation and the MDN one is that yours is harder to maintain and harder to reason about hence test.
1. Maintanance / Reusability
Imagine you're a few thousand lines of code into a code base then you're required to change what processUserInput() does. Its much easier to change or write a new callback function instead of changing the function processUserInput(). This would be evident if processUserInput was a bit more complicated. This also means the MDN one is much more useful in various scenarios unlike your implementation. You can reuse it in different situations like saying good bye, capitalizing names etc simply by writing different callbacks to plug into processUserInput().
2. Testing / Easier to reason about
The MDN implementation is much more easier to understand. Its easier to assume that the function processUserInput(greeting) will probably return a greeting than it is to assume what processUserInput() does. This makes it easier to test because you can always be sure the MDN implementation will always return the same output given an input.

Callbacks can be extremely useful depending on the circumstances; for example, when working with JavaScript for Google Chrome browser extension development, a callback can be used for intercepring web requests once it has been setup.
The purpose of a callback in general is to have the callback routine executed upon a trigger - the trigger being an event of some kind. Usually, functionality follows an interface of chained APIs. By implementing callback support, you can redirect execution flow during a stage of an operation. Callbacks are especially useful to third-party developers when dealing with someone elses library depending on what they are trying to do. Think of them like a notification system.
Functions in general taking in parameters is useful for flexibility and maintenance. If you use different functions for different things, the functions can be simply re-used over and over again to provide different functionality - whilst still preventing bloating the source code with more-or-less the same code over and over again. At the same time, if you use functions to your own library and a bug shows up, you can simply patch it for the one function and then it will be solved.
In your example, your passing a callback routine to the function you're calling - the function you're calling will call the callback function and pass the correct parameters. This is flexible because it allows you to have a callback routine called for printing the contents of the variable, and another for calculating the length of the string passed in, or another for logging it somewhere, etc. It allows you to re-use the function you setup, and have a different function called with the correct parameters without re-making the original function.

This example is not appropriate for understanding callbacks
In simple Language callbacks functions are used when we have to do some stuff after or in response of some other event or function or expression.
i.e when the parent function completes its execution then callback gets executed.
simple Example
function hungerStatus(status,cb){
return cb(status)
}
function whatToDo(status){
return status ? "order Pizza" : "lets play"
}
hungerStatus(false,whatToDo)
Another example
// global variable​
​var allUserData = [];
​
​// generic logStuff function that prints to console​
​function logStuff (userData) {
if ( typeof userData === "string")
{
console.log(userData);
}
else if ( typeof userData === "object")
{
for (var item in userData) {
console.log(item + ": " + userData[item]);
}
​
}
​
}
​
​// A function that takes two parameters, the last one a callback function​
​function getInput (options, callback) {
allUserData.push (options);
callback (options);
​
}
​
​// When we call the getInput function, we pass logStuff as a parameter.​
​// So logStuff will be the function that will called back (or executed) inside the getInput function​
getInput ({name:"Rich", speciality:"JavaScript"}, logStuff);
refer callback exaplanation

Method deleting itself - it works but why, and should I use it?

Ok, this is out of "academic interest" (although I'm thinking of using it somewhere). Suppose I have the following:
function f2 ()
{
delete Widget.f1;
Widget.f3 = function ()
{
console.log("This works.");
}
}
let Widget =
{
f1: function ()
{
f2();
}
}
console.log(Widget);
Widget.f1();
console.log(Widget);
Widget.f3();
So basically I call upon a method to remove itself from the object and be replaced with another method. It seems to work fine. So here are my two questions:
Is there a good (technical) reason why I should not do this?
From an "in the bowels of JavaScript" point of view, how does this work? Intuition would say that f1 remains "open" until it has been completed, which would mean that we delete a function that is still "open". Is the f2() call somehow "hoisted" out of it?
Cheers

Is there a good (technical) reason why I should not do this?
The main reason i would not use this is that it is confusing and likely to cause bugs when other developers (including future-BVDev) either don't notice that you're doing it, or don't understand why you're doing it.
From an "in the bowels of JavaScript" point of view, how does this work?
Widget.f1 is a reference to a function, it's not the function itself. So when you delete Widget.f1, that reference is now gone, but the function continues to exist in memory. It also continues to exist on the current execution stack. If there are other references to the function, then it will continue to exist after the call stack has finished. On the other hand if this was the only reference to the function, then some time later, the garbage collector will run and free the memory that the function was taking up.

Callback() Node Js

I'm very confused about this program. I bought a book called "Node JS, MongoDB, and AngularJS Web Development" by Brad Dayley. I found a program to demonstrate something called closure, and it shows this program as an example. This is only the first part of the program.
function logCar(logMsg, callback){
process.nextTick(function(){
callback(logMsg);
});
}
var cars = ["Ferrari", "Porsche", "Bugatti"];
for(var idx in cars){
var message = "Saw a " + cars[idx];
logCar(message, function(){
console.log("Normal Callback: " + message);
})
}
I've been trying to figure out how this program functions for an entire hour, but I can't figure out what the function of callback(logMsg).
I know this is probably a very basic question, but I just can't wrap my head around it.

callback is any function that you pass to logCar(). When logCar completes doing whatever it is supposed to do, then it will call the callback function. Inside your for loop, you call logCar() like this..
logCar(message, function(){
console.log("Normal Callback: " + message);
})
Here, function() {..} is the callback function and it will be called once logCar is done executing. In this case, the callback function you've provided will console.log the message you've passed as the first parameter. You could have passed another function that would perform something different as a callback too.

I find these easier to wrap my head around by following the execution path more closely, especially the path that logMsg takes. A good debugger is great for this.
Nothing really happens until that for loop, where a variable named message is defined. At the start it will be "Saw a Ferrari".
There's also an anonymous function right next to "message" that's unfortunately difficult to separate out and define. Because it looks outside of its scope for a variable named "message" that's trapped inside that for loop, we couldn't do on line 6:
var someFunction = function(){
console.log("Normal Callback: " + message);
}
...because what's "message"? Nothing outside of that for-loop has access to "message" directly (except as closure, but don't worry about that yet). Note that this function won't execute yet. It's just been created at this point.
So next executes LogCar("Saw a Ferrari", someFunction...). Where's LogCar? Oh, the top. Let's jump there, but for simplicity let's skip process.nextTick. Essentially someFunction("Saw a Ferrari") happens here. Where's SomeFunction? Oh, that's that anonymous function that hasn't executed yet. Now its time to execute has arrived. So the process jumps back there to see what's inside it and execute it, which is console.log("Saw a Ferrari");
That's done, and the process repeats for "Saw a Porsche" .

What is difference between calling a function and callback function?

What is the difference between following snippets
// calling a function
function execute(){
}
function fn(){
asynchronousFunction(function(){
execute();
})
}
fn();
How the below snippet is different from above
// callback a function
function execute(){
}
function fn(done){
asynchronousFunction(function(){
done();
})
}
fn(execute);
In which way callback is different from calling a function directly? What are pros and cons of each approach?

If you call a function, it will execute immediately.
If you pass the function as an argument to another function, then some other code will call it later (at which point it will execute).
They aren't different approaches for doing the same thing. You use a callback when you are writing a function that needs to do something at some point, but when what that something is depends on something outside the function.
The classic example is addEventListener. For the sake of discussion, let's limit ourselves to click events. You have a standard function for making something happen when something is clicked. Lots of programs want something to happen when something is clicked, but that something can be almost anything.

In first case, your function fn() can see execute() and the parameter is optional, because anytime you call fn() will be called execute().
in second case, you made your function more "general" and you may customize your callback function

The first option presents fn as a simple function that starts some kind of asynchronous action and doesn't present any other information to the outside. If fn is something like uploadData, then you'd have a simple function that tries to upload it (and maybe display an error message if it fails, or a success message when it's done), but the caller can only start it and do nothing else.
The second option additionally allows the caller of fn to decide what should happen when fn completes. So if fn is uploadData, then the caller is able to also specify what should happen once the data has been uploaded (or if there has been an error).

Callbacks like these gives you a lot of flexibility. In your second example, you are able to say: "Do fn(), and do the asynchronous function, and if you have finished, then call done()." And the point is, you can decide what done() does, although you have no insight in the method that calls it.
Delivering functions as an argument, that are to be executed e.g. at the begin, at the end or at other events, is a fundamental principle. It is the basis for hooks, callbacks, promises, configuring of complex objects etc.

Unattached anonymous functions and doubly named methods in javascript?

I'm debugging an app that uses .NET's scriptmanager.
It may be a glitch in firebug, but when I read through the code there are a lot of lines like the following:
// anonymous functions not attached as handlers and not called immediately
function () {
//code
}
// named functions added as methods
myObj = {
myMethod: function myFunctionName() {
//code
}
}
Are these lines valid and, if so, what do they do and what possible reason would there be for coding like this (and I won't accept "It's microsoft - what d'you expect" as an answer)?

This might be worth a read: How does an anonymous function in JavaScript work?

They are there because some busy programmer was intending to do something and ran out of time, but left the stub as a reminder of work to be done. They do nothing as of yet.
or to watermark the code for checks that are done elsewhere in the logic
or simply put there to obfuscate...