Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As you may know, XMLHTTPRequest can be used synchronously or asynchronously, but synchronized requests have always been considered bad practice, and I've always agreed with that.

Not only is the ideology of modern JS development heavily based on an event model, but there were also some more prosaic reasons to avoid synchronized requests. For example, old Internet Explorer versions could just freeze suddenly.

Today I saw a synchronized request in Liferay source code and thought "What a shame, how dare they. Don't they know that it is wrong?". But then I asked myself what is actually wrong with this approach in modern times, and I wasn't able to give an accurate, logical answer.

For example, on the server side it is common practice to use synchronized HTTP requests. Of course all the data could be fetched asynchronously, and perhaps should be fetched that way, but we often need data that will be used to fetch another chunk of data, so in that case the request must be synchronized.

So, should this still be considered bad practice?

PS: I haven't used the term AJAX since the first A stands for asynchronous. :)

share|improve this question
    
Just because synchronous IO on the server is common doesn't mean its good. async IO is better, it's just not as "easy" to write. – Raynos Oct 6 '11 at 11:28
    
Bad practice is to do something in a not so properly way. That does not mean that it will not be useful in another scenario. Best|Bad Practices are not law. They are not even any standar. It's just conventional. The more tools/possibilities you have the better. I encourage to you to ask Liferay Dev Team about their synchronizedrequest. It can be a bug, or may be there's a good reason beneah. What doesn't make sense to you, doesn't mean that have no sense for anybody else. Don't you forget that the only word that means law is requirements – Laiv Apr 29 at 8:33
up vote 6 down vote accepted

In short, yes.

Synchronous HTTP requests halt execution of subsequent code while they are en route. While browsers may no longer block the UI during this time, we're relying on the user's available bandwidth, network reliability, and the server's current load for the performance of our code. This is generally not good practice.

On the MDN "Using XMLHttpRequest" page, there is also a vague warning about memory use and event leakage when using synchronous XMLHttpRequest. There is no detail given, but given that the UI is not blocked, and JavaScript is, it would make sense that we might miss UI events we would have caught had we been using Async.

Note: You shouldn't use synchronous XMLHttpRequests because, due to the inherently asynchronous nature of networking, there are various ways memory and events can leak when using synchronous requests.

Edit: Server Side

While I agree that synchronous requests are common, I don't know that they're best practice. They may, however, be better practice on the server than on the client. It is better to put faith in your own server and its network connections than it is to put faith in those of your user. The server is (theoretically) a constant, the client is a variable. There are also no UI issues to deal with, and no possibility of uncaptured events.

share|improve this answer
    
Ryan, but, once again, when we are talking about serverside solutions, it's pretty common to do something like data = req_sync(some_params); req_async(build_params(data)) – shabunc Oct 5 '11 at 13:28
    
besides, if it so useless, why should we even try to keep in in standard? I'm not arguing, actually, as I have wrote, I always said that sync it an evil, I'm just trying to be more objective. – shabunc Oct 5 '11 at 13:30
    
Ah, I did neglect the server-side portion. Will edit. – Ryan Kinal Oct 5 '11 at 13:34
    
@shabunc Generally, everything that gets into the standard has to stay there for backwards compatibility, so the fact that a feature is still in the standard is never (by itself) an argument that the feature is good. – Ixrec May 19 at 8:27

Here is a good reason not to totally abandon sync calls just yet.

You have just downloaded a new tool from a vendor.

You get it working in your AngularJS application. (you spend weeks at this POC)

Then you are asked to use one option that has to communicate to your web server.

You create OWIN secure applications, so ALL calls must be Authorized!

The option to upload/download NEEDS to have an Authorization Token.

Authorization Tokens time out!!

So you must get a new one so that it is fresh BEFORE you start the option to upload/download.

BUT the option to upload/download where you get the Authorization Token is a event handler WITHOUT Promise/Q/$q capabilities.

Javascript is single threaded, so promises are not executed until the end of the event handler!

So you HAVE to do a Synchronous XmtHttpRequest!

I believe we should use Asynchronous Calls, but until Javascript is multi-threaded or event handlers return promises or Tool vendors use promises; we will need a Synchronous XmtHttpRequest call for secure web sites, just to refresh Authorization Tokens!

Regards

GregJF

share|improve this answer
    
Are you saying authoriztion tokens time out after a certain number of event loop tickets, or a certain number of real-world seconds? This argument only makes sense to me if it's the former, and that seems very unusual. – Ixrec May 18 at 21:33
    
Ixrec all authorization tokens should and do time out. My argument is pointed at the gap between the timeout of token and the need to have a fresh token. Vendors of some HTML/CSS tools only allow for synchronous calls inside their event handler. This makes refreshing the authorization token impossible without a synchronous call from within the event handler. This only applies when a communication to the web server is required from with in the event handler (for whatever reason). Remember I didn't write the event handler, the tool's vendor did – GregJF May 19 at 7:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.