A Few Words on Callbacks and Asynchronous Mechanism In Javascript

It is said that the one of the most routine work a javascript programmer do is writing codes like "something.onclick= function(e){}". I myself have written thousands lines of codes like this. But one thing I was confused when first coming across with this type of code is: "something.onclick= function(e){}", wait...where does the e come from, who provided it? Somebody also write it as 'event' or 'evt', are there any differences between them?

Well, if you also think in this way, then you should take some time to learn something about Callbacks and Asynchronous Mechanism In Javascript. In fact, when you write something like "something.onclick= function(e){}". you think you were handling an event, but in fact, you are just delegate the event handler to the browser's javascript engine.

It's kind of Like you are saying: "Hey, javascript engine, to wait a user to click(or xhrs, or settimeouts) takes too long, i got a lot of other important stuff to do. so can you help me listen the user's click?"

the Javascript engine says :"no problem, but I don't know how should I do when the user clicks?"

you then write an function and give it to the Javascript engine. the function says: "if an event comes you should execute me with an 'event' argument, you should ckeck the event's type, then check event.pageX and blablabla..." Now I am clear: the event, evt or e we write is just a formal argument, so it doesn't matter how we write it, it is just a placeholder.

This story gives us a few insights about callbacks and asynchronous mechanism. That is, in Javascript, when you need to do some time-consuming operations, like xhr requests or settimeouts or user interactions, instead of just pending and wait while it is progressing, you can write a callback, which describes how the operation's result will be handled, and throw it to the javascript engine's async queue, and it will help you to monitor the event, and you just do anything else you want. Once the operations fulfilled,or the certain events happened, the engine will give the handler back to the bottom of main thread, if the main thread is not busy, the handler will be executed.

Notice here: When we say that "the engine will give the handler back to the bottom of main thread", we means that: as long as the main thread is busy, the handler will never be executed! That is to say: the handler executes only when:

1.asynchronous condition fulfilled.

2.main thread is free.

This leads us to a very interesting question, how will these codes outputs:

setTimeout(function(){
    console.log('end');
},0);
console.log('starts');

Ofcourse, as the two words itself implies: the result will be starts -> end.Because the setTimeout function,(together with xhrs, on+'event') has a built-in implementation of Async.when we set timeouts to a function, instead of execute this function instantly, it will throw it to the async queue, and continue to execute other codes, once the async condition fulfilled, it throwes the function back to main thread.
meet setTimeout -> throw func to queue -> continue with console.log('starts')-> 0ms later,condition fulfilled ->throw back func -> executes func -> console.log('end').

Now that we have been familiar with this mechanism, we can use it write owesome codes.

In jQuery, we often write codes like:

//Pyramids of Doom :(
$.ajax('a.html', function(reseponseData){
    $.ajax('b.html', responseData, function(yetAnotherData){
        $.ajax('c.html', yetAnotherData, function(finalData){
            handleTheData(finalData);
        });
    });
});

Is there any problem with these codes? nope, you say, it works well, I am using ajax callbacks to write interactive web pages! But there ARE problems.At least, Firstly, the codes expands horizontally faster than it expands vertically, our code become 'fat'. Secondly, every ajax call is dependent on previous call's response data, how could you elegantly catch errors between them?

This leads us to another hot topic in Javascript thesedays. It is the Promise.