Why is $ (). Ready (handler) not recommended?

Question

The docs jQuery API site for ready

All three of the following syntaxes are equivalent:

• $ (document) .ready (handler)
• $ (). ready (handler) (this is not recommended)
• $ (handler)

After doing homework - reading and playing with the source code , I have no idea why

 $().ready(handler) 

Not recommended. The first and third methods, exactly the same, the third option calls a ready-made function to the cached jQuery object using document :

 rootjQuery = jQuery(document); ... ... // HANDLE: $(function) // Shortcut for document ready } else if ( jQuery.isFunction( selector ) ) { return rootjQuery.ready( selector ); } 

But the ready function has no interaction with the selector of the selected node elements, the source code is ready :

 ready: function( fn ) { // Attach the listeners jQuery.bindReady(); // Add the callback readyList.add( fn ); return this; }, 

As you can see, it simply adds a callback to the internal queue ( readyList ) and does not change or use the elements in the set. This allows you to call the ready function on each jQuery object.

how

• regular selector: $('a').ready(handler) DEMO
• Nonsense series : $('fdhjhjkdafdsjkjriohfjdnfj').ready(handler) DEMO
• Undefined : $().ready(handler) DEMO

Finally ... to my question: Why is $().ready(handler) not recommended?

Answer 1

I received an official response from one of jQuery developers:

$().ready(fn) only works because $() was a shortcut to $(document) _{(jQuery <1.4)}
So $().ready(fn) was readable code.

But people usually did things like $().mouseover() and all sorts of other crazy things.
and people had to do $([]) to get an empty jQuery object

So, in 1.4 we changed it, so $() gives an empty jQuery, and we just did $().ready(fn) work so as not to break a lot of code

$().ready(fn) literally now just fixed in the kernel so that it works correctly for an obsolete case.

The best place for the ready function is $.ready(fn) , but it's a really old design decision, and that is what we have now.

---

I asked him:

Do you think $ (fn) is more readable than $ (). ready (fn) ?!

His answer was:

I always do $ (document) .ready (fn) in real applications and, as a rule, in an application there is only one ready-made block of a document, it does not quite look like a service item.

I think $ (fn) is also pretty unreadable , it's just A Thing That You To To Know Works ™ ...

Answer 2

Since the various options do almost the same thing you specify, it is time to put on a library writer hat and make some guesses.

• Perhaps jQuery people would like to have $() for future use (doubtful, since $().ready documented to work, even if it is not recommended, and will also pollute the semantics of $ cased).

• A much more practical reason: the second version is the only one that does not end with the document wrapper, so it is easier to break it when serving the code. Example:

   // BEFORE $(document).ready(foo); // AFTER: works $(document).ready(foo).on("click", "a", function() {}); 

  Contrast this with

   // BEFORE $().ready(foo); // AFTER: breaks $().ready(foo).on("click", "a", function() {}); 

• Related to the above: ready is a freak in the sense that it (the only?) Method will work the same regardless of what the jQuery object wraps (even if it does not wrap anything, as is the case here). This is a significant difference from the semantics of other jQuery methods, therefore, in particular, it is justified.

  Update: As Esailija points out, technically, ready should really be a static method, as it works as follows.

Update # 2:. Delving into the source, it seems that at some point in the branch $() 1.4 $() was changed to match $([]) , and in 1.3 it behaved like $(document) . This change will reinforce the above rationale.

Answer 3

I would say that it is simply a fact that $() returns an empty object, while $(document) does not make your application ready() for different things; it still works, but I would say that it is not intuitive.

 $(document).ready(function(){}).prop("title") // the title $().ready(function(){}).prop("title") //null - no backing document 

Answer 4

Most likely, this is just a mistake with the documentation and should be fixed, the only minute of using $().ready(handler) is its readability. Of course, they claim that $(handler) is also unreadable. I agree why I do not use it.

You can also argue that one method is faster than another. However, how often do you call this method enough times in a row on one page to notice the difference?

Ultimately, it comes down to personal preference. There is no shortage of using $().ready(handler) other than the readability argument. I think in this case the documentation does not work.

Answer 5

Just to make it clearly obvious that there is some inconsistency in the three cases, plus I added a fourth commonly used form: (function($) {}(jQuery));

With this markup:

 <div >one</div> <div>two</div> <div id='t'/> 

and this code:

 var howmanyEmpty = $().ready().find('*').length; var howmanyHandler = $(function() {}).find('*').length; var howmanyDoc = $(document).ready().find('*').length; var howmanyPassed = (function($) { return $('*').length; }(jQuery)); var howmanyYuck = (function($) {}(jQuery)); var howmanyYuckType = (typeof howmanyYuck); $(document).ready(function() { $('#t').text(howmanyEmpty + ":" + howmanyHandler + ":" + howmanyDoc + ":" + howmanyPassed + ":" + howmanyYuckType); }); 

Displayed div results from last statement: 0: 9: 9: 9: undefined

SO, only versions of Handler and Doc are consistent with the jQuery convention of returning something useful, since they get a document selector, and with the submitted form you have to return something (I wouldn’t do this, I would think, but put it just for in order to show "inside" there is something).

Here is the script version for the curious: http://jsfiddle.net/az85G/

Answer 6

I think this is really more for readability than anything else.

It is not so expressive

 $().ready(handler); 

but

 $(document).ready(handler) 

Perhaps they are trying to promote some form of idiomatic jQuery.