Utilizing synchronous XHRs proves valuable in preserving user data. By managing the beforeunload event, data can be uploaded to the server as the user exits the page.

If this process were executed asynchronously, there is a risk of the page closing before the request finishes. Opting for synchronous execution guarantees that the request either completes successfully or fails in a predictable manner.

Update:

The previous discussion hinted at the diminishing necessity of using synchronous requests with the advancement of better asynchronous request handling. Using synchronous requests may intentionally block users from interacting until a request is complete, which can be seen as malicious.

While there are rare situations where it might be crucial for certain requests to occur before a user navigates away from a page or performs an action, purposely blocking code execution could potentially reduce errors in a poorly designed system. However, this practice is not commonly seen and should generally be avoided.

Libraries like promise simulate synchronicity by linking processes through callbacks, catering to most development needs requiring ordered, non-blocking events for improved user experience.

Mozilla documentation acknowledges specific scenarios where synchronous requests are necessary but also presents a workaround using beacon (not supported in IE/Safari) for such cases. If this experimental feature gains acceptance, it could potentially eliminate the need for synchronous requests altogether.

---

Synchronous calls are typically best suited for transaction-like processes or when strict order of operations is crucial. For example, if you want to log out after playing a song, ensuring that the logout operation happens after the song has finished requires synchronization.

Another valid use case would be when working with a WebService, particularly for server-side mathematical calculations.

Example: Assume the server variable initially holds a value of 1.

 Step (1) Perform Update: add 1 to the variable
 Step (2) Perform Update: set the variable to the power of 3
 End Value: variable equals 8

If Step (2) occurs before Step (1), the end value would be 2 instead of 8, emphasizing the importance of proper synchronization.

---

In common real-world scenarios, there are very few instances where a synchronous call may be warranted - perhaps when clicking on login and then immediately accessing a restricted portion of the site that requires authentication.

It's essential to note that synchronous calls can tie up the browser, making it advisable to avoid them whenever possible.

Instead of relying on synchronous calls, users often prefer stopping a currently loading event and then proceeding with another operation. This mimics synchronization, as the first event is terminated before the second one begins. The abort() method on the xml connection object can facilitate this process.

In my opinion, if you are okay with potentially blocking the user's browser until the request finishes, then go ahead and use a synchronous request.

However, if your goal is to serialize requests, it can be achieved by utilizing asynchronous requests. You can have the onComplete callback of one request trigger the next one in line.

There are numerous scenarios in the real world where it is necessary to block the UI intentionally.

Consider an application with multiple fields requiring validation through an xmlhttp call to a remote server, utilizing input from these fields as well as others.

In a synchronous mode, the process is straightforward, user experience is minimally affected, and there are no issues.

However, in asynchronous mode, users have the ability to alter values in other fields while one is undergoing validation. This can result in additional xmlhttp calls being made using unvalidated data if the initial validation fails, leading to chaos. If synchronous mode is phased out and prohibited, managing application logic becomes extremely challenging. Essentially, the application must be rewritten to incorporate locking mechanisms (such as disabling other elements during validation). This significantly increases code complexity. Failure to do so could result in logical errors and ultimately data corruption.

The fundamental question arises: which is more crucial, ensuring a non-blocked UI experience or mitigating the risk of data corruption? The responsibility lies with the application developer, not the W3C.

Utilizing synchronous XHR requests can be beneficial when a resource located in a variable position needs to be loaded before other static resources on the page that rely on it. For example, I am currently incorporating an XHR request into one of my projects where JavaScript files are stored in various locations on the server based on specific parameters. It is crucial for these variable resources to load first before any dependent files, ensuring the smooth operation of the application.

This concept builds upon vol7ron's response, emphasizing that synchronous requests are best suited for transaction-based processes. In most scenarios, asynchronous calls are preferred as they allow for updating the DOM after the call is made. For instance, certain features in user-based systems may be restricted until users log in, and these features can be unlocked through a DOM update following an asynchronous request.

In general, it is widely agreed that minimizing the use of synchronous XHR requests is advisable due to the browser being locked up during their execution. If synchronous requests are necessary, they should be strategically placed, such as in the HEAD section before the actual page loading begins, to minimize disruptions to the user experience.

Within jQuery, there are situations where synchronous AJAX is utilized. In cases where HTML with embedded scripts is being inserted, the browser will not automatically run those scripts. It becomes necessary to manually trigger their execution. These scripts often contain event handlers like click events. If a user interacts with an element before the handler is attached, it may lead to undesired behavior on the page. To avoid such race conditions, synchronous AJAX is employed to retrieve and execute these scripts in the correct sequence. Despite blocking other operations, synchronous AJAX ensures that scripts and events are processed in the intended order.

In recent years, there has been a rise in the popularity of desktop javascript apps. When these apps load local files (often done using XHR), the speed is usually so fast that adding asynchronous code can be unnecessary complexity. While there are situations where async is necessary (such as fetching content from the internet or loading large batches of files), synchronous loading generally works well and is simpler to implement.

Explanation:

Imagine you have an ajax-powered application that needs to make multiple http requests to load necessary data from the server before allowing user interaction.

Naturally, you would want these requests to be triggered upon page load.

Synchronous calls can efficiently handle this without complicating the code. It's a simple and direct approach.

Limitation:

The main drawback is that your browser freezes until all data is retrieved or a timeout occurs. For the specific ajax application in question, this freezing isn't a major issue because the application is unusable until the initial data is loaded anyway.

Alternatives?

However, some browsers freeze all windows/tabs while one tab is busy with javascript, which is not ideal as it prevents users from accessing other tabs during the loading process.

Moreover, recent browsers seem to have removed or restricted synchronous requests. The reason behind this change remains unclear, whether due to their perceived inefficiency or misinterpretation of standards.

http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/#the-open-method indicates (refer to section 4.7.3) that setting a timeout is disallowed in blocking mode. This seems counterintuitive, as timeouts are essential for managing blocking IO operations effectively.

In my view, blocking IO serves a purpose in certain scenarios but must be implemented appropriately. While it's unacceptable for one tab to disrupt others, such behavior is ultimately a flaw in browser design. However, brief non-responsiveness in an individual tab may be acceptable at times, especially during initial data retrieval on page load. Properly executed blocking logic can sometimes offer the cleanest solution.

Although asynchronous http calls can achieve similar results, they often require convoluted routines. A suggested approach could involve:

Upon document load: 1: Establish 6 global "Done" flags initialized to 0. 2: Initiate all 6 background requests simultaneously (assuming order is unimportant).

Subsequently, each completion callback for every request updates its respective "Done" flag and checks if all 6 requests have been completed. The final callback to finish, after verifying the status of the others, triggers the actual initialization function to prepare everything based on the acquired data.

If request order matters or the server cannot handle concurrent requests, an alternative strategy may look like this:

During onload(), launch the first request. In its callback, trigger the second request. Continue this pattern with subsequent callbacks launching the next request in line. Upon completion of the last request, call the real init() routine.

Have you ever wondered about the repercussions of making a synchronous call in live code?

It's like the world coming crashing down.

Jokes aside, users definitely don't appreciate a frozen browser.

One way I utilize this tool is to confirm the availability of a username before finalizing its selection.

Although asynchronous validation may be more efficient, it would require a separate code structure specifically for this task. To elaborate further, my validation process involves several functions that return either true or false based on the validity of the input data.

Due to the necessity of returning the function, I opt for synchronous validation and rely on the server's timely response to minimize any noticeable delays. Implementing an AJAX callback, on the other hand, would necessitate a different approach to managing subsequent validation steps compared to my current methods.

At times, certain actions rely on the completion of others. For instance, action B may only commence after A has been completed. The synchronous method is typically employed to prevent potential race conditions. Opting for a synchronous call can sometimes result in a more straightforward implementation compared to developing intricate logic to monitor the states of interdependent asynchronous calls.

However, a drawback of this approach is that it effectively stalls the user's browser until the action is fully completed (until the request returns, finishes loading, etc). Therefore, exercise caution when utilizing this method.

During my coding process, I initially implement synchronous calls to prevent any potential errors from being obscured by actions taking place while the request is traveling to and from the server.

Once everything seems to be functioning correctly, I switch over to asynchronous calls. However, I always include an abort timer and failure callbacks just in case anything unexpected happens.

Understanding the distinction between SYNC and ASYNC

The essential difference can be illustrated with the following code snippet:

console.info('Hello, World!');
doSomething(function handleResult(result) {
    console.info('Got result!');
});
console.info('Goodbye cruel world!');

If doSomething operates synchronously, the output would appear as follows:

Hello, World!
Got result!
Goodbye cruel world!

Conversely, if doSomething works asynchronously, the output would be:

Hello, World!
Goodbye cruel world!
Got result!

In the asynchronous scenario, the function doSomething returns before completing its task. Thus, we only receive the result after printing Goodbye cruel world!.

When relying on the result of an asynchronous call, it is crucial to include the dependent code in the callback:

console.info('Hello, World!');
doSomething(function handleResult(result) {
    console.info('Got result!');
    if (result === 'good') {
        console.info('I feel great!');
    }
    else {
        console.info('Goodbye cruel world!');
    }
});

The necessity for multiple sequential actions does not justify synchronous execution; however, synchronous code tends to be more user-friendly for most individuals.

Justification for Utilizing Synchronous XMLHttpRequest

Certain situations demand obtaining results before the executed function concludes. Take this example into consideration:

function lives(name) {
    return (name !== 'Elvis');
}
console.info('Elvis ' + (lives('Elvis') ? 'lives!' : 'has left the building...');

If external control over the calling code (console.info) restricts changes and lives needs to query the server for information, executing an asynchronous request within lives without awaiting a response poses a challenge. In such cases, performing a synchronous request becomes imperative to obtain a timely result before lives finishes processing.

As highlighted by Sami Samhuri, scenarios like the onbeforeunload event emphasize the critical need for synchronous response handling, as it marks the final app operation before window closure.

Avoiding Unnecessary Synchronous Calls – Embracing Asynchronous Operations

It is unwise to resort to synchronous calls owing to their browser-locking nature and detrimental impact on app responsiveness. Despite the inherent complexity, managing asynchronous code is feasible using innovative solutions like Promises.

Consider the demanding scenario where two asynchronous calls must conclude before initiating a subsequent segment of code:

var carRented = rentCar().then(function(car){
  gasStation.refuel(car);
});

var hotelBooked = bookHotel().then(function(reservation) {
  reservation.confirm();
});

Promise.all([carRented, hotelBooked]).then(function(){
  // Ensuring both car rental and hotel booking are accomplished.
  goOnHoliday();
});

Below is an implementation illustration for bookHotel:

function bookHotel() {
  return new Promise(function(resolve, reject){
    if (roomsAvailable()) {
      var reservation = reserveRoom();
      resolve(reservation);
    }
    else {
      reject(new Error('Could not book a reservation. No rooms available.'));
    }
  });
}

For further insights, refer to: Write Better JavaScript with Promises.

XMLHttpRequest is commonly utilized for making asynchronous requests. In certain situations (such as debugging or specific business requirements), there may be a need to convert multiple asynchronous calls on a single page to synchronous.

If you wish to achieve this without modifying all of your JavaScript code, utilizing the async/sync flag can provide you with that option. With proper design, you may only need to alter one line in your code or change the value of a single var during runtime execution.

Non-IE browsers, including Firefox, do not have native support for async XHR timeOut.

1. Discussion on handling timeouts in different browsers
2. Mozilla Firefox XMLHttpRequest documentation

While HTML5 WebWorkers do offer timeout support, you can achieve a similar behavior by wrapping synchronous XHR requests in WebWorkers with a timeout implementation for an asynchronous-like XHR experience.

Recently, I encountered a scenario in which making asynchronous requests for a series of URLs using forEach (and a for loop) led to the cancellation of subsequent requests. However, when I switched to synchronous requests, they executed as expected.

Using Synchronous XHR can prove to be quite beneficial for internal tool and framework development that is not intended for production use. Consider a scenario where you need to load a code library synchronously upon first access, like the following:

get draw() 
{
    if (!_draw)
    {
       let file;
       switch(config.option)
       {
           case 'svg':
              file = 'svgdraw.js';
              break;
           case 'canvas':
              file = 'canvasdraw.js';
              break;
           default:
              file = 'webgldraw.js';
       }

       var request = new XMLHttpRequest();
       request.open('GET', file, false);
       request.send(null);
       _draw = eval(request.responseText);
    }

    return _draw;
}

Before jumping to conclusions and dismissing the use of eval without understanding the context, remember that this example is specifically for testing purposes only. In a production environment, _draw would already be set.

Therefore, your code may appear as follows:

foo.drawLib.draw.something(); //loaded on demand

This is just one instance where synchronous XHR is essential. While you could load the library upfront or use a promise/callback approach, achieving synchronous loading without sync XHR would not be possible. Consider the enhanced organization that this technique can bring to your code...

The potential applications for using synchronous XHR in tooling and locally-run frameworks are virtually limitless, constrained only by creativity. However, it seems that creativity tends to be somewhat limited in the realm of JavaScript.

In the world of mobile advertising, using synchronous HTTP requests is a common strategy employed by companies.

These companies, also known as "Publishers," integrate advertising SDKs into their applications to generate revenue. There are various SDK options available such as MoPub, Ogury, TapJob, AppNext, and Google Ads AdMob.

These SDKs function by displaying ads within a webview, aiming for a seamless user experience, particularly when showcasing videos without any buffering or loading interruptions.

To achieve this smooth ad serving process, precaching comes into play. This involves synchronously loading media elements like images and videos in the background of the webview.

But why opt for synchronous loading instead of asynchronous?

1. It aligns with an established global standard.
2. The SDK relies on the onload event to ensure the ad is ready to display to the user.

As technologies evolve and synchronous XMLHttpRequests are phased out, the advertising industry will likely need to adapt its practices unless alternative solutions are implemented.

One compelling reason is the necessity to execute an http request and subsequently trigger a click event on an input type=file based on the response. This task proves challenging with asynchronous xhr or fetch as the callback function loses the crucial context of "user action", causing the call to click() to be disregarded. Fortunately, synchronous xhr came to the rescue in this scenario.

onButtonClick(event){
    //Although I am able to do this here, it's not what I want.
    //document.getElementById("myFileInput").click();
    fetch("Validate.aspx", { method : "POST", body: formData, credentials: "include" })
    .then((response)=>response.json())
    .then(function (validResult) {
        if (validResult.success) {
            //In this case, I am unable to execute the desired action.
            document.getElementById("myFileInput").click();
        }
    });
}

The reason is that the method chrome.webRequest.*.addListener does not allow for asynchronous handlers.