To illustrate, let's say I'm building an invoice object. I start with list of items sold, sum their prices, do a database lookup via JQ's POST to get the applicable sales tax rate, but by the time I've got my data back from the POST call, my code has proceeded to multiply the sum of item prices by the as-yet-unreturned tax rate.
It seems like the way jQuery wants us to deal with this, is by breaking out processing into function chunks which will then get called-back by POST success conditions. We don't want to revert to $.ajax(,,async=false) because a) it locks the browser, which is visually disturbing to the user, b) it's deprecated, and c) not all browsers even support that.
My first approach to faking async was to make an empty loop run while() some flag variable indicated the post() call had not returned its data yet. This turned out to be an infinite loop and I had to manually crash my Chrome window.
Take two, I looped a setTimeout() with a 200ms interval (5x/sec) and a limit of 50 iterations. My PHP middleware is pretty tight; it definitely should not take more than 10 seconds to respond.
This also did not work as expected. From further research I discovered that the lack of a native Javascript sleep() function is something many devs have wrestled with over the years. The intractability of the problem stems from Javascript's single-threaded execution model. So, when you use async jQuery functions like .ajax(), .post() or .get() in the middle of a long processing sequence, you are inevitably forced to do one of two things:
1) Break up the sequence into chunks, and use jQuery's .when().then() or Deferred.done() facilities to control program flow between AJAX calls; or...
2) Package up the necessary data, POST it to a PHP middleware unit, and sequence the processing (including all your database lookups) in PHP, not Javascript.
In my case, the first option would result in a huge and tortured code body to load client-side, and be a horror to maintain. So I'm headed in the second direction, which will result in a much more natural, concise and maintainable code body. But I'm kind of sad because it FEELS like what I tried to do in JavaScript should be totally do-able.