问题
I already know the difference between synchronous and asynchronous requests, like explained here for example: Synchronous and asynchronous requests
When you try to make a synchronous XMLHttpRequest (with firefox for example), you get this famous warning:
Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience
However, I think you can use the synchronous aspect in a positive manner, for example during the page load, to get some important data on which the loading process depends hardly (without which the content can't be displayed at all). There, it's quite natural that the user has to wait for the request; it behaves like if the request's content would be a real part of the calling file, which would have to be read as well as the rest of the file.
It seems to be pretty much the case for the less.js css tool :
It needs to parse the .less files before any display. The less team apparently decided to choose a synchronous request : I can imagine that with an async request instead, the page could be displayed before the less files would have been parsed, and would display some raw content for a short time, without any style defined. It would not be the an expected or convenient behaviour. So a synchronous request seems to be a better solution there.
The warning says :
because of its detrimental effects to the end user's experience
Obvioulsy, it's the developper's responsability to make sure that the request will run as fast as possible, but in the case of a website sending a mandatory request to its own server (to a php file that is part of the website), or in the case of less.js, the synchronous behaviour is the wanted one.
So, why are synchronous requests considered as deprecated, whereas they seem to be so useful?
回答1:
You're mixing different concepts which is why you're wondering why it was deprecated.
Firstly, the asynchronous calls were not invented to make calls faster. In fact, they have almost zero impact on the speed.
Secondly, the asynchronous calls were not invented to specifically make required or non-required calls. It is the responsibility of the developer to make such a decision.
Having said that, the message answers the question clearly:
because of its detrimental effects to the end user's experience
Your main confusion is about the goal of the asynchronous calls. The whole idea behind asynchronous calls is NOT to ensure that the user will not have to wait for the results, but it is to make the application more responsive.
You gave an example of the required call during the page load. By using asynchronous request, the user will still have to wait for the results (the goal of asynchronous calls is not to solve this problem), but the application will stay responsive to the user input. For instance, some applications can have a [Cancel] button so the user can cancel the request. Some other applications may display some animation or progress bar. You, the developer, decide what to do, but only asynchronous gives you this chance to make the decision. Synchronous calls on the other hand will block the execution, the application will look like frozen, you, the developer, cannot do anything during the call, and that's the detrimental effects to the end user's experience the message is talking about.
来源：https://stackoverflow.com/questions/33053955/why-is-synchronous-xmlhttprequest-considered-as-deprecated