Are all javascript callbacks asynchronous? If not, how do I know which are?

12,446

Solution 1

I'm curious as to whether all javascript callbacks are asynchronous

No. For instance, the callback used by Array#sort is not asynchronous, nor is the one used by String#replace.

The only way you know whether a callback is asynchronous is from its documentation. Typically, ones involving requests for external resources (ajax calls, for instance) are asynchronous, and others may or may not be.

However, for example, I know that jQuery's AJAX functions are truly asynchronous...

Not necessarily, as currently jQuery still has the async flag which you can set false to force a synchronous request. (It's not a good idea, and they're going to remove that, but you can. jQuery passes the flag to the underlying browser object which provides the synchronous/asynchronous behavior.)

What is it that make jQuery's AJAX asynchronous?

The browser. jQuery's ajax calls use the XMLHttpRequest object (or in certain situations, a script element), which defaults to asynchronous operation provided by the browser.

Or is there some way to make one's own function truly asynchronous without leveraging very specific functions of the environment...

Until recently, no. Up through the 5th edition specification, JavaScript the language was basically silent on the entire concept of threads and asynchronicity; it was only when you got into environments that it came up. The only way to make something asynchronous was to use a host-provided function, such as nextTick (or any of the various operations that completes asynchronously) on NodeJS or setTimeout on browsers.

In the ECMAScript 6th edition specification in June 2015, they introduced promises into the language. The callbacks hooked up to an ES6 promise via then and such are always invoked asynchronously (even if the promise is already settled when the callback is attached), and so JavaScript has asynchronicity at a language level now. So if you implement your function so that it returns a promise rather than accepting a callback, you'll know that the then callbacks hooked up to it will be triggered asynchronously.

Solution 2

Callbacks that you call yourself are regular function calls, which are always synchronous.

Certain native APIs (eg, AJAX, geolocation, Node.js disk or network APIs) are asynchronous and will execute their callbacks later in the event loop.

If you call a callback synchronously from within an async callback, it will end up being async too.

Solution 3

To create your own asynchronous functions you have to make use of other asynchronous functions which may be provided by the interpreter.

This code for example defines a function "addKeyHandler" which is asynchronous. But that only works because document.onKey is called asynchronously by the JS engine. The JavaScript engine is able to provide asynchronous functionality because the operating system provides such functionality which is then used by JS. The OS in turn can only provide async functionality because the hardware provides it (called hardware interrupts).

However if the OS and hardware didn't provide any async functions it would still be possible to write a JS interpreter. But it would have to use an infinite loop and check in each iteration if any events occured and then invoke the appropriate callbacks. That would mean the CPU would always be under full load.

var keyCallbacks = [];

var addKeyHandler = function(f) {
  keyCallbacks.push(f);
};

document.onkeypress = function(e) {
  keyCallbacks.forEach(function(f) {
      f(e);
  });
};

addKeyHandler(function(e) {
    console.log(String.fromCharCode(e.charCode));
});

Solution 4

Simply taking a callback doesn't make a function asynchronous. There are many examples of functions that take a function argument but are not asynchronous, for example, Array's forEach.

For a function to be asynchronous it needs to perform an asynchronous operation. Ways of introducing asynchronicity can be

  • timer functions setTimeout, setInterval
  • special functions nextTick, setImmediate
  • performing I/O (listening to network, querying a database, reading or writing from a resource)
  • subscribing to an event

According to article "Does taking a callback make a function asynchronous?"

Share:
12,446
jacheson
Author by

jacheson

Updated on June 06, 2022

Comments

  • jacheson
    jacheson almost 2 years

    I'm curious as to whether all javascript callbacks are asynchronous, or whether that is the case only in certain situations. Also, I'm sure what makes javascript code asynchronous (or ways to use asynchronous javascript) differ between the browser and nodejs, so I'd like to know in each situation what constitutes real asynchronous javascript.

    I'm under the impression that in the following scenarion, I'm not actually writing asynchronous code.

    function addOne(value){
      value = value + 1;
      return value;
    }
    
    function simpleMap(values, callback){
      for(i = 0; i < values.length; i++){
        val = values[i];
        val = callback(val);
        values[i] = val;
      }
      return values;
    }
    
    newValues = simpleMap([1,2,3], addOne);
    

    However, for example, I know that jQuery's AJAX functions are truly asynchronous (not taking in to account the promises which are now available). What is it that make jQuery's AJAX asynchronous? Is it as simple that it involves XHR requests, and in the browser, all XHR requests are asynchronous?

    I have the same question for the nodejs environment. Can something in node only be asynchronous if it involves something like file i/o, process.nextTick, setTimeout, or setInterval? Why when I do something like a database call with mongodb/mongoose, is that asynchronous? What's going on behind the scenes that's making it so?

    Are asynchronous "situations" predetermined by the environment? Or is there some way to make one's own function truly asynchronous without leveraging very specific functions of the environment (such as xhr, file io in node, process.nexttick, etc)?

  • Felix D.
    Felix D. almost 10 years
    Great answer! It's easier to understand with the parallels you did between the callbacks, OS and hardware.