Deferreds should always resolve asynchronously

[scottgonzalez]

Deferreds should always be resolved asynchronously. Any abstraction that deals with a potentially async operation should always act asynchronously. The current implementation prevents users from writing code that takes advantage of async behavior and can cause bugs in bad code that is written against an initially synchronous implementation that later becomes asynchronous.

This also has the (positive) side effect of cached XHR requests in IE being resolved asynchronously.

[jaubourg]

I agree, but async=false in $.ajax() disagrees.

If we want to make Deferred 100% asynchronous, then we have to remove synchronous ajax requests (which I'd love to be able to do btw, but I doubt I'll see the day).

[scottgonzalez]

Do we know if there's a lot of use of deferreds on sync XHR requests?

If we can't always force deferreds to resolve asynchronously, can we at least have an option during creation of the deferred for whether or not it should be forced to be async, with the default being async? Then sync XHR can set the flag and continue working as it does today.

[jaubourg]

OK, so this is clearly about changing behaviour... do I wait for 1.8 for trying and fixing it or do I try it for 1.7? (async option was something I intended to add in $.Callbacks later on FYI)

[jaubourg]

+1

[mikesherov]

+0

[Timmy Willison]

+0, As I understand it, we are sometimes dependent on the synchronous nature of certain deferreds.

[Rick Waldron]

+1

[gnarf]

I'm against this at this point, I can't use Deferred in animate any longer if it becomes async. No matter what we end up doing, It would break at least two use cases within jQuery core to not somehow still support the sync behavior.

[gnarf]

I retract my earlier complaint under the assumption that this only causes a "async" step if it is resolved/rejected in the same event loop it was created in.

[scottgonzalez]

@gnarf That is my intention. If the deferred is resolved in a future tick then the callbacks should be invoked in that same tick (synchronous with the resolution, but asynchronous compared to the creation of the deferred).

[dmethvin]

Pushing to 1.9, current plan is to move the now-deprecated async:false option to a compat plugin which would allow $.Deferred to be totally async.

[tj@…]

+1, if a callback may occur asynchronously to the code hooking it up, it should always occur asynchronously to that code. In fact, I recently file ticket #12044 because ready is chaotic in this respect.

[dmethvin]

Bulk change from enhancement to feature.

[dmethvin]

In the email thread we had, it seemed like there was just too much potential for breaking lots of code (including cases currently in our own ajax and effects) so I don't think we can do this. Note that the Promise/A discussion leaves this intentionally unspecified.