Remove core/ready hard dependency on $.Deferred

[mgol]

Originally reported by m_gol at: http://bugs.jquery.com/ticket/15174

If $.Deferred is unavailable (e.g. because it was removed via custom compilation), the core/ready implementation should fall back to the standard Promise.

Issue reported for jQuery 2.1.1

[dmethvin]

Also related to gh-1823

[timmywil]

Hmm, I don't think this is necessary. Deferred is simply a hard dependency of core/ready. If Deferred is removed from a custom build, so core/ready should be too (which we could easily add to the Gruntfile). Those making custom builds are usually also accustomed to placing scripts at the end of the body, making core/ready wasted space. Maybe this is a docs issue instead.

[scottgonzalez]

.ready() is a pretty important API. I don't think it should go away just because someone doesn't want $.Deferred. Also, I thought there were still some cases where just putting scripts at the end of the body isn't enough. I think @gibson042 might remember when that's the case?

[timmywil]

I used to think that too. We had this conversation a while ago and it turned out it is sufficient.

Also, Deferred is an important API too. It is used internally in other areas besides core/ready. core/ready is probably the least important of them all.

[timmywil]

I did think of a limitation. On a very large document, you'd probably prefer to start downloading the script immediately, but still defer so the browser can download and parse the DOM in parallel. In this case, doc ready can still play a role just in case the script loads before the document is ready, but I think script loaders often have that covered.

[timmywil]

Ah, here is the conversation I was thinking of. That only overlaps because I don't remember finding evidence that putting scripts at the end if the body wouldn't work.

[timmywil]

You know what, I think I've already gone over to the other side. Sorry for the brain dump of notifications. This could be useful to users. My only question is, how do we handle the lack of native Promise in certain environments?

[mgol]

Up until very recently we used to divide support tests into two parts:
one that didn't require attaching anything to document that was invoked at
start and one that did that was invoked on doc ready. Therefore, if you use
any jQuery earlier than 1.11/2.1 (a.k.a. latest), you have to run your code
on doc ready or you risk stumbling upon bugs as the one linked to by
timmywil in this thread.

Now we have this second part of support tests lazy; in 2.x they have
elements attached to document.documentElement so this can happen anytime;
in 1.x they are attached to document.body and you'll have no results until
document.body exists; you'll be fine if you put scripts at the end of body.

What bothers me most here is that if you do depend on core/ready and
consume it via AMD, you'll get Deferred pulled into automatically by
RequireJS and - later - the builder. Of course if we determined that
relying on core/ready is no longer necessary then the importance of this
fact decreases.

I was thinking that if you exclude Defered and not core/ready you're
required to provide window.Promise. Now, that approach will blow up for
people using our AMD modules that will not use $.ajax, .animate or Deferred
by themselves but will use core/ready...

Michał Gołębiowski

[dmethvin]

I think it's reasonable to focus on doing any dependency reduction just on master and not compat.

How about this? When Deferred is missing we just do something simple like convert .ready(handler) to window.addEventListener("DOMContentLoaded", function(){ handler(jQuery); }). We wouldn't need to maintain the queue ourselves, the browser should maintain FIFO order, and handlers that throw exceptions don't affect subsequent ones.

At the moment, jQuery.ready is undocumented. We've stated the intention to document it in jquery/api.jquery.com#205 but as a thenable and not specifically as a Deferred or Promise. For consistency of behavior in all the edge cases I think it's best to use Deferred if it's there. Our docs should tell anyone doing a custom build without Deferred that they need to provide a Promise shim.

[scottgonzalez]

Wouldn't that break the usage of .ready() after the event has occurred?