How to return the response from an asynchronous call in JavaScript? [Solutions]

In this article, I’ll share the top 4 answers to the problem mentioned above.

The A in Ajax stands for asynchronous. That means sending the request (or rather receiving the response) is taken out of the normal execution flow. In your example, $.ajax returns immediately and the next statement, return result;, is executed before the function you passed as success callback was even called.

How to return the response from an asynchronous call? Solution #1:

Here is an analogy which hopefully makes the difference between synchronous and asynchronous flow clearer:


Imagine you make a phone call to a friend and ask him to look something up for you. Although it might take a while, you wait on the phone and stare into space, until your friend gives you the answer that you needed.

The same is happening when you make a function call containing “normal” code:

function findItem() {
    var item;
    while(item_not_found) {
        // search
    return item;

var item = findItem();

// Do something with item

Even though findItem might take a long time to execute, any code coming after var item = findItem(); has to wait until the function returns the result.


You call your friend again for the same reason. But this time you tell him that you are in a hurry and he should call you back on your mobile phone. You hang up, leave the house, and do whatever you planned to do. Once your friend calls you back, you are dealing with the information he gave to you.

That’s exactly what’s happening when you do an Ajax request.

findItem(function(item) {
    // Do something with the item

Instead of waiting for the response, the execution continues immediately and the statement after the Ajax call is executed. To get the response eventually, you provide a function to be called once the response was received, a callback (notice something? call back ?). Any statement coming after that call is executed before the callback is called.


Embrace the asynchronous nature of JavaScript! While certain asynchronous operations provide synchronous counterparts (so does “Ajax”), it’s generally discouraged to use them, especially in a browser context.

Why is it bad do you ask?

JavaScript runs in the UI thread of the browser and any long-running process will lock the UI, making it unresponsive. Additionally, there is an upper limit on the execution time for JavaScript and the browser will ask the user whether to continue the execution or not.

All of this results in a really bad user experience. The user won’t be able to tell whether everything is working fine or not. Furthermore, the effect will be worse for users with a slow connection.

In the following we will look at three different solutions that are all building on top of each other:

  • Promises with async/await (ES2017+, available in older browsers if you use a transpiler or regenerator)
  • Callbacks (popular in node)
  • Promises with then() (ES2015+, available in older browsers if you use one of the many promise libraries)

All three are available in current browsers, and node 7+.

ES2017+: Promises with async/await

The ECMAScript version released in 2017 introduced syntax-level support for asynchronous functions. With the help of async and await, you can write asynchronous in a “synchronous style”. The code is still asynchronous, but it’s easier to read/understand.

async/await builds on top of promises: an async function always returns a promise. await “unwraps” a promise and either result in the value the promise was resolved with or throws an error if the promise was rejected.

Important: You can only use await inside an async function. Right now, top-level await isn’t yet supported, so you might have to make an async IIFE (Immediately Invoked Function Expression) to start an async context.

You can read more about async and await on MDN.

Here is an example that elaborates the delay function findItem() above:

// Using 'superagent' which will return a promise.
var superagent = require('superagent')

// This is isn't declared as `async` because it already returns a promise
function delay() {
  // `delay` returns a promise
  return new Promise(function(resolve, reject) {
    // Only `delay` is able to resolve or reject the promise
    setTimeout(function() {
      resolve(42); // After 3 seconds, resolve the promise with value 42
    }, 3000);

async function getAllBooks() {
  try {
    // GET a list of book IDs of the current user
    var bookIDs = await superagent.get('/user/books');
    // wait for 3 seconds (just for the sake of this example)
    await delay();
    // GET information about each book
    return await superagent.get('/books/ids='+JSON.stringify(bookIDs));
  } catch(error) {
    // If any of the awaited promises was rejected, this catch block
    // would catch the rejection reason
    return null;

// Start an IIFE to use `await` at the top level
(async function(){
  let books = await getAllBooks();

Current browser and node versions support async/await. You can also support older environments by transforming your code to ES5 with the help of regenerator (or tools that use regenerator, such as Babel).

Let functions accept callbacks

A callback is when function 1 is passed to function 2. Function 2 can call function 1 whenever it is ready. In the context of an asynchronous process, the callback will be called whenever the asynchronous process is done. Usually, the result is passed to the callback.

In the example of the question, you can make foo accept a callback and use it as success callback. So this

var result = foo();
// Code that depends on 'result'


foo(function(result) {
    // Code that depends on 'result'

Here we defined the function “inline” but you can pass any function reference:

function myCallback(result) {
    // Code that depends on 'result'


foo itself is defined as follows:

function foo(callback) {
        // ...
        success: callback

callback will refer to the function we pass to foo when we call it and we pass it on to success. I.e. once the Ajax request is successful, $.ajax will call callback and pass the response to the callback (which can be referred to with result, since this is how we defined the callback).

You can also process the response before passing it to the callback:

function foo(callback) {
        // ...
        success: function(response) {
            // For example, filter the response

It’s easier to write code using callbacks than it may seem. After all, JavaScript in the browser is heavily event-driven (DOM events). Receiving the Ajax response is nothing else but an event. Difficulties could arise when you have to work with third-party code, but most problems can be solved by just thinking through the application flow.

ES2015+: Promises with then()

The Promise API is a new feature of ECMAScript 6 (ES2015), but it has good browser support already. There are also many libraries which implement the standard Promises API and provide additional methods to ease the use and composition of asynchronous functions (e.g., bluebird).

Promises are containers for future values. When the promise receives the value (it is resolved) or when it is canceled (rejected), it notifies all of its “listeners” who want to access this value.

The advantage over plain callbacks is that they allow you to decouple your code and they are easier to compose.

Here is an example of using a promise:

function delay() {
  // `delay` returns a promise
  return new Promise(function(resolve, reject) {
    // Only `delay` is able to resolve or reject the promise
    setTimeout(function() {
      resolve(42); // After 3 seconds, resolve the promise with value 42
    }, 3000);

  .then(function(v) { // `delay` returns a promise
    console.log(v); // Log the value once it is resolved
  .catch(function(v) {
    // Or do something else if it is rejected
    // (it would not happen in this example, since `reject` is not called).
.as-console-wrapper { max-height: 100% !important; top: 0; }

Applied to our Ajax call we could use promises like this:

function ajax(url) {
  return new Promise(function(resolve, reject) {
    var xhr = new XMLHttpRequest();
    xhr.onload = function() {
    xhr.onerror = reject;'GET', url);

  .then(function(result) {
    console.log(result); // Code depending on result
  .catch(function() {
    // An error occurred
.as-console-wrapper { max-height: 100% !important; top: 0; }

 Run code snippetExpand snippet

Describing all the advantages that promise offer is beyond the scope of this answer, but if you write new code, you should seriously consider them. They provide a great abstraction and separation of your code.

More information about promises: HTML5 rocks – JavaScript Promises.

Side note: jQuery’s deferred objects

Deferred objects are jQuery’s custom implementation of promises (before the Promise API was standardized). They behave almost like promises but expose a slightly different API.

Every Ajax method of jQuery already returns a “deferred object” (actually a promise of a deferred object) which you can just return from your function:

function ajax() {
    return $.ajax(...);

ajax().done(function(result) {
    // Code depending on result
}).fail(function() {
    // An error occurred

Side note: Promise gotchas

Keep in mind that promises and deferred objects are just containers for a future value, they are not the value itself. For example, suppose you had the following:

function checkPassword() {
    return $.ajax({
        url: '/password',
        data: {
            username: $('#username').val(),
            password: $('#password').val()
        type: 'POST',
        dataType: 'json'

if (checkPassword()) {
    // Tell the user they're logged in

This code misunderstands the above asynchronous issues. Specifically, $.ajax() doesn’t freeze the code while it checks the ‘/password’ page on your server – it sends a request to the server and while it waits, it immediately returns a jQuery Ajax Deferred object, not the response from the server. That means the if statement is going to always get this Deferred object, treat it as true, and proceed as though the user is logged in. Not good.

But the fix is easy:

.done(function(r) {
    if (r) {
        // Tell the user they're logged in
    } else {
        // Tell the user their password was bad
.fail(function(x) {
    // Tell the user something bad happened

Not recommended: Synchronous “Ajax” calls

As I mentioned, some(!) asynchronous operations have synchronous counterparts. I don’t advocate their use, but for completeness’ sake, here is how you would perform a synchronous call:

Without jQuery

If you directly use a XMLHttpRequest object, pass false as third argument to .open.


If you use jQuery, you can set the async option to false. Note that this option is deprecated since jQuery 1.8. You can then either still use a success callback or access the responseText property of the jqXHR object:

function foo() {
    var jqXHR = $.ajax({
        async: false
    return jqXHR.responseText;

If you use any other jQuery Ajax method, such as $.get$.getJSON, etc., you have to change it to $.ajax (since you can only pass configuration parameters to $.ajax).

Heads up! It is not possible to make a synchronous JSONP request. JSONP by its very nature is always asynchronous (one more reason to not even consider this option).

How to return the response from an asynchronous call? Solution #2:

If you’re not using jQuery in your code, this answer is for you

Your code should be something along the lines of this:

function foo() {
    var httpRequest = new XMLHttpRequest();'GET', "/echo/json");
    return httpRequest.responseText;

var result = foo(); // Always ends up being 'undefined'

What you’re facing

This is a short summary of “Explanation of the problem” from the other answer, if you’re not sure after reading this, read that.

The A in AJAX stands for asynchronous. That means sending the request (or rather receiving the response) is taken out of the normal execution flow. In your example, .send returns immediately and the next statement, return result;, is executed before the function you passed as success callback was even called.

This means when you’re returning, the listener you’ve defined did not execute yet, which means the value you’re returning has not been defined.

Here is a simple analogy:

function getFive(){
    var a;
    return a;

The value of a returned is undefined since the a=5 part has not executed yet. AJAX acts like this, you’re returning the value before the server got the chance to tell your browser what that value is.

One possible solution to this problem is to code re-actively , telling your program what to do when the calculation completed.

function onComplete(a){ // When the code completes, do this

function getFive(whenDone){
    var a;

This is called CPS. Basically, we’re passing getFive an action to perform when it completes, we’re telling our code how to react when an event completes (like our AJAX call, or in this case the timeout).

Usage would be:


Which should alert “5” to the screen. 

Possible solutions

There are basically two ways how to solve this:

  1. Make the AJAX call synchronous (let’s call it SJAX).
  2. Restructure your code to work properly with callbacks.

1. Synchronous AJAX – Don’t do it!!

As for synchronous AJAX, don’t do it! Felix’s answer raises some compelling arguments about why it’s a bad idea. To sum it up, it’ll freeze the user’s browser until the server returns the response and create a very bad user experience. Here is another short summary taken from MDN on why:

XMLHttpRequest supports both synchronous and asynchronous communications. In general, however, asynchronous requests should be preferred to synchronous requests for performance reasons.

In short, synchronous requests block the execution of code… …this can cause serious issues…

If you have to do it, you can pass a flag. Here is how:

var request = new XMLHttpRequest();'GET', 'yourURL', false);  // `false` makes the request synchronous

if (request.status === 200) {// That's HTTP for 'ok'

2. Restructure code

Let your function accept a callback. In the example code foo can be made to accept a callback. We’ll be telling our code how to react when foo completes.


var result = foo();
// Code that depends on `result` goes here


foo(function(result) {
    // Code that depends on `result`

Here we passed an anonymous function, but we could just as easily pass a reference to an existing function, making it look like:

function myHandler(result) {
    // Code that depends on `result`

For more details on how this sort of callback design is done, check Felix’s answer.

Now, let’s define foo itself to act accordingly

function foo(callback) {
    var httpRequest = new XMLHttpRequest();
    httpRequest.onload = function(){ // When the request is loaded
       callback(httpRequest.responseText);// We're calling our method
    };'GET', "/echo/json");

We have now made our foo function accept an action to run when the AJAX completes successfully. We can extend this further by checking if the response status is not 200 and acting accordingly (create a fail handler and such). Effectively it is solving our issue.

If you’re still having a hard time understanding this, read the AJAX getting started guide at MDN.

How to return the response from an asynchronous call? Solution #3:

If you don’t use jQuery and want a nice short XMLHttpRequest 2 which works in the modern browsers and also in the mobile browsers, I suggest to use it this way:

function ajax(a, b, c){ // URL, callback, just a placeholder
  c = new XMLHttpRequest;'GET', a);
  c.onload = b;

As you can see:

  1. It’s shorter than all other functions Listed.
  2. The callback is set directly (so no extra unnecessary closures).
  3. It uses the new onload (so you don’t have to check for readystate && status)
  4. There are some other situations, which I don’t remember, that make the XMLHttpRequest 1 annoying.

There are two ways to get the response of this Ajax call (three using the XMLHttpRequest var name):

The simplest:


Or if for some reason you bind() the callback to a class:


function callback(e){
ajax('URL', callback);

Or (the above one is better anonymous functions are always a problem):

ajax('URL', function(e){console.log(this.response)});

Nothing easier.

Now some people will probably say that it’s better to use onreadystatechange or the even the XMLHttpRequest variable name. That’s wrong.

Check out XMLHttpRequest advanced features.

It supported all *modern browsers. And I can confirm as I have been using this approach since XMLHttpRequest 2 was created. I never had any type of problem in any browsers I used.

onreadystatechange is only useful if you want to get the headers on state 2.

Using the XMLHttpRequest variable name is another big error as you need to execute the callback inside the onload/oreadystatechange closures, or else you lost it.

Now if you want something more complex using POST and FormData you can easily extend this function:

function x(a, b, e, d, c){ // URL, callback, method, formdata or {key:val},placeholder
  c = new XMLHttpRequest;||'get', a);
  c.onload = b;

Again … it’s a very short function, but it does GET and POST.

Examples of usage:

x(url, callback); // By default it's GET so no need to set
x(url, callback, 'post', {'key': 'val'}); // No need to set POST data

Or pass a full form element (document.getElementsByTagName('form')[0]):

var fd = new FormData(form);
x(url, callback, 'post', fd);

Or set some custom values:

var fd = new FormData();
fd.append('key', 'val')
x(url, callback, 'post', fd);

As you can see, I didn’t implement sync… it’s a bad thing.

Having said that … why don’t we do it the easy way?

As mentioned in the comment, the use of error && synchronous does completely break the point of the answer. Which is a nice short way to use Ajax in the proper way?

Error handler

function x(a, b, e, d, c){ // URL, callback, method, formdata or {key:val}, placeholder
  c = new XMLHttpRequest;||'get', a);
  c.onload = b;
  c.onerror = error;

function error(e){
  console.log('--Error--', this.type);
  console.log('this: ', this);
  console.log('Event: ', e)
function displayAjax(e){
  console.log(e, this);
x('WRONGURL', displayAjax);

In the above script, you have an error handler which is statically defined, so it does not compromise the function. The error handler can be used for other functions too.

But to really get out an error, the only way is to write a wrong URL in which case every browser throws an error.

Error handlers are maybe useful if you set custom headers, set the responseType to blob array buffer, or whatever…

Even if you pass ‘POSTAPAPAP’ as the method it won’t throw an error.

Even if you pass ‘fdggdgilfdghfldj’ as formdata it won’t throw an error.

In the first case the error is inside the displayAjax() under this.statusText as Method not Allowed.

In the second case, it simply works. You have to check at the server side if you passed the right post data.

Cross-domain not allowed throws an error automatically.

In the error response, there aren’t any error codes.

There is only the this.type which is set to error.

Why add an error handler if you totally don’t have any control over errors? Most of the errors are returned inside this in the callback function displayAjax().

So: There isn’t any need for error checks if you’re able to copy and paste the URL properly. 😉

PS: As the first test I wrote x(‘x’, displayAjax)…, and it totally got a response…??? So I checked the folder where the HTML is located, and there was a file called ‘x.xml’. So even if you forget the extension of your file XMLHttpRequest 2 WILL FIND IT. I LOL’d

Read a file synchronous

Don’t do that.

If you want to block the browser for a while load a nice big .txt file synchronous.

function omg(a, c){ // URL
  c = new XMLHttpRequest;'GET', a, true);
  return c; // Or c.response

Now you can do

 var res = omg('thisIsGonnaBlockThePage.txt');

There is no other way to do this in a non-asynchronous way. (Yeah, with setTimeout loop… but seriously?)

Another point is… if you work with APIs or just your own list’s files or whatever you always use different functions for each request…

Only if you have a page where you load always the same XML/JSON or whatever you need only one function. In that case, modify a little the Ajax function and replace b with your special function.

The functions above are for basic use.

If you want to extend the function…

Yes, you can.

I’m using a lot of APIs and one of the first functions I integrate into every HTML page is the first Ajax function in this answer, with GET only…

But you can do a lot of stuff with XMLHttpRequest 2:

I made a download manager (using ranges on both sides with resume, filereader, and filesystem), various image resizers converters using canvas, populate web SQL databases with base64images and much more…

But in these cases you should create a function only for that purpose… sometimes you need a blob, array buffers, you can set headers, override mimetype and there is a lot more…

How to return the response from an asynchronous call? Solution #4:

The simplest solution is to create a JavaScript function and call it for the Ajax success callback.

function callServerAsync(){
        url: '...',
        success: function(response) {


function successCallback(responseObj){
    // Do something like read the response and show data
    alert(JSON.stringify(responseObj)); // Only applicable to a JSON response

function foo(callback) {

        url: '...',
        success: function(response) {
           return callback(null, response);

var result = foo(function(err, result){
          if (!err)

Visit Programming Articles for more.

About ᴾᴿᴼᵍʳᵃᵐᵐᵉʳ

Linux and Python enthusiast, in love with open source since 2014, Writer at, India.

View all posts by ᴾᴿᴼᵍʳᵃᵐᵐᵉʳ →