AJAX asynchronous and synchronous

Synchronization needs to wait for the return result before continuing. Asynchronous does not need to wait. Generally, it is necessary to monitor the asynchronous result.
Synchronization is a queue in a straight line, asynchronous is not in a queue, each goes its own way.

1. What is the difference between synchronous and asynchronous?

Synchronous: Submit the request -> Wait for server processing -> Return after processing. During this period, the client browser cannot do anything

Asynchronous: The request is triggered by an event ->Server processing (this means the browser can still do other things) ->Processing completed

2. Under what circumstances is it used?

1. Single-mindedness: You can only do one thing at the moment, and other things must wait for the current thing to be completed before you can continue with the next thing.

2. Half-hearted: You can do multiple things at the same time: your left hand presses the space bar, your right hand can keep hitting the mouse, and your eyes have to look at the screen at the same time, which is very hard.

When Ajax sends a request, it is divided into synchronous and asynchronous:

The asynchronous transmission method is the most commonly used and the default method. It avoids The time delay brought to the user by server retrieval. During asynchronous transmission, it just proceeds quietly behind the scenes, and the user can still do what he is doing without giving the user any feeling of waiting. When the amount of data transmitted is large, the server retrieval time will be longer, but the user does not know it. The user is still focused on the operations on the page and does not know what the server has done, so it gives the user a good experience.

The asynchronous transmission method is the opposite. It is just like the moment the page is loaded. After the synchronous request is issued, the browser is waiting for the server to complete the retrieval and return the result. At this time, the mouse will turn into a waiting shape, reminding our user that the request has not yet been responded to. You can't do anything, and our users can't do anything. The one thing they can do is - wait... Although the user has already You are used to waiting for the rectification page to load. Although the time for synchronizing requests in Ajax is generally not longer than the time for loading the entire page, you have to know how painful it is to do nothing and just wait passively. Therefore, this synchronous request should be used with caution...

At this point, we have to ask the question, since asynchronous requests are so good, why not use asynchronous requests? Just don't make synchronous requests. Haha, don’t be too hasty. If there is such a situation, the result of our request in this step is the premise of the next request. Only knowing the result of this step of request will what the user does in the future make sense. So do you think you should use synchronous requests or asynchronous requests? Obviously, synchronize the request. In order to make the next step more meaningful, why not wait a moment for our dear users?

Synchronous requests and asynchronous requests have their own uses. There is no good or bad distinction. It is just a question of whether they are appropriate or not.

# Ajax advantages and disadvantages

# AJAX advantages and disadvantages:

advantage:

## Traditional web applications allow users to fill in forms, and when the form is submitted, a request is sent to the web server. The server receives and processes the incoming form, and then returns a new web page. This approach wastes a lot of bandwidth because most of the HTML code in the two pages is often the same. Since each application interaction requires sending a request to the server, the application's response time depends on the server's response time. This results in a user interface that is much less responsive than native apps.

Unlike this, an AJAX application can only send and retrieve the necessary data to the server. It uses SOAP or some other XML-based web service interface, and uses JavaScript on the client to process the response from the server. Because a lot less data is exchanged between the server and the browser, we see more responsive applications as a result. At the same time, a lot of processing work can be completed on the client machine that makes the request, so the processing time of the Web server is also reduced.

The biggest advantage of using Ajax is that it can maintain data without updating the entire page. This allows web applications to respond to user actions more quickly and avoids sending unchanged information over the network.

Ajax does not require any browser plug-ins, but requires the user to allow JavaScript to execute on the browser. Just like DHTML applications, Ajax applications must be rigorously tested on many different browsers and platforms. As Ajax matures, some program libraries that simplify the use of Ajax have also come out. Likewise, another assistive programming technology has emerged to provide alternative functionality for users who do not support JavaScript.

shortcoming:

The main criticism of using Ajax is that it can break the normal behavior of the browser's back button. In the case of dynamically updated pages, the user cannot go back to the previous page state because the browser can only remember static pages in the history. The difference between a page that has been completely read and a page that has been dynamically modified is very subtle; users usually want to click the back button to cancel their previous operation, but in an Ajax application, this is not possible. this way. However, developers have come up with various ways to solve this problem, most of which are by creating or using a hidden IFRAME to reproduce the changes on the page when the user clicks the back button to access the history. (For example, when the user clicks back in Google Maps, it searches in a hidden IFRAME and then reflects the search results onto the Ajax element to restore the application state to what it was at that time.)

A related point of view is that using dynamic page updates makes it difficult for users to save a specific state to favorites. Solutions to this problem have also emerged, most of which use URL fragment identifiers (often called anchors, the part after the # in the URL) to keep track and allow the user to return to a specified application state. (Many browsers allow JavaScript to dynamically update anchors, which allows Ajax applications to update the anchor simultaneously with the displayed content.) These solutions also resolve many of the arguments about not supporting the back button. When developing Ajax, network latency—the time between a user's request and the server's response—needs to be carefully considered. Not giving users a clear response [5], not properly pre-reading data [6], or improper handling of XMLHttpRequest [7] will cause users to feel delayed, which is something users don’t want to see and cannot understand. [8]. A common solution is to use a visual component to tell the user that the system is performing background operations and reading data and content.

                                                                                                                                                                                                                                                   some handheld devices (such as mobile phones, PDAs, etc.) currently do not support Ajax very well; Ajax engines made with JavaScript, JavaScript compatibility and DeBugs are headaches; No-refresh reload, because the page changes are not as obvious as refresh reload, so it is easy to cause trouble to users - users are not sure whether the current data is new or has been updated; existing solutions include: Location prompts, data update areas are designed to be more obvious, and user prompts are given after data updates, etc.; the support for streaming media is not as good as FLASH and Java Applet;