We Keep Coding

Why "$().ready(handler)" is not recommended?

From the jQuery API docs 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)
is not recommended. The first and third ways, are exactly the same, the third option calls the ready function on a cached jQuery object with 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 ready source code:
ready: function( fn ) {
// Attach the listeners
jQuery.bindReady();
// Add the callback
readyList.add( fn );
return this;
},
As you can see, it justs add the callback to an internal queue( readyList) and doesn't change or use the elements in the set. This lets you call the ready function on every jQuery object.
Like:
regular selector: $('a').ready(handler) DEMO
Nonsense selector: $('fdhjhjkdafdsjkjriohfjdnfj').ready(handler) DEMO
Undefined selector:$().ready(handler) DEMO
Finally... to my question: Why $().ready(handler) is not recommended?

I got an official answer from one of the jQuery developers:
$().ready(fn) only works because $() used to be a shortcut to $(document) (jQuery <1.4)
So $().ready(fn) was a readable code.
But people used to do things like $().mouseover() and all sorts of other madness.
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 made $().ready(fn) work so as not to break a lot of code
$().ready(fn) is literally now just patched in core to make it work properly for the legacy 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 that $(fn) is more readable than $().ready(fn) ?!
His answer was:
I always do $(document).ready(fn) in actual apps and typically there's only one doc ready block in the app it's not exactly like a maintenance thing.
I think $(fn) is pretty unreadable too, it's just A Thing That You Have To Know Works™...

Since the different options do pretty much the same thing as you point out, it's time to put on the library writer hat and make some guesses.
Perhaps the jQuery people would like to have $() available for future use (doubtful since $().ready is documented to work, even if not recommended; it would also pollute the semantics of $ if special-cased).
A much more practical reason: the second version is the only one that does not end up wrapping document, so it's easier to break when maintaining 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's (the only?) method that will work the same no matter what the jQuery object wraps (even if it does not wrap anything as is the case here). This is a major difference from the semantics of other jQuery methods, so specifically relying on this is rightly discouraged.
Update: As Esailija's comment points out, from an engineering perspective ready should really be a static method exactly because it works like this.
Update #2: Digging at the source, it seems that at some point in the 1.4 branch $() was changed to match $([]), while in 1.3 it behaved like $(document). This change would reinforce the above justifications.

I would say its simply the fact that $() returns an empty object whereas $(document) does not so your applying ready() to different things; it still works, but I would say its not intuitive.
$(document).ready(function(){}).prop("title") // the title
$().ready(function(){}).prop("title") //null - no backing document

More than likely this is just a documentation bug and should be fixed, the only downside to using $().ready(handler) is it's readability. Sure, argue that $(handler) is just as unreadable. I agree, that's why I don't 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 a single page to notice a difference?
Ultimately it comes down to personal preference. There is no downside to using $().ready(handler) other than the readability argument. I think the documentation is miss-leading in this case.

Just to make it patently obvious that there is some inconsistency in the three, plus I added the fourth often 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);
});
The displayed results of the div from the last statement are: 0:9:9:9:undefined
SO, only the Handler and Doc versions are consistent with the jQuery convention of returning something of use as they get the document selector and with the Passed form you must return something (I wouldn't do this I would think, but put it in just to show "inside" it has something).
Here is a fiddle version of this for the curious: http://jsfiddle.net/az85G/

I think this is really more for readability than anything else.
This one isn't as expressive
$().ready(handler);
as
$(document).ready(handler)
Perhaps they are trying to promote some form of idiomatic jQuery.

Namespacing jQuery plugins

Let's assume that we have following jQuery plugins (each of them in separate files):
$.fn.foo
$.fn.foo.bar
$.fn.foo.baz
I use standard jQuery plugin pattern. The first one is actually a proxy or "facade" to the rest plugins of it's namespace.
For example, when I call $('#el').foo(), under the hood I also call:
var context = this; // context is equal to $('#el')
$(context).foo['bar'].apply(context);
$(context).foo['baz'].apply(context);
There are two problem when I want to call only (without $.fn.foo) $('#el').foo.bar(). The first problem is that there are no $.fn.foo namespace but I can create it, so this is actually no problem. The second problem is that this inside $.fn.foo.bar is equal to document object but I want to be equal to $('#el'). How can I do that?
So, making a long story short, both should work:
$('#el').foo(); // This also calls foo.bar and foo.baz under the hood
$('#el').foo.bar(); // I'm calling foo.bar explicitly

I think you might just need to follow a different plugin pattern. Here is a nice repository of jQuery plugin patterns, but the one you might want to look at would be the namespace pattern - you'll see how the namespace gets defined initially if it doesn't already exist, and this allows you to more easily extend from a single namespace across multiple scripts.
Update: Hmm, I'm still learning so I wouldn't say I'm an expert at this, but trying to get this $('#el').aaa.bbb.ccc() to work got really messy for me. Maybe it would be better to not use that format, but instead do this (demo):
$.aaa.bbb.ccc( $("#el") );
because then it is relatively easy to set up:
(function() {
if (!$.aaa) {
$.aaa = {
bbb : {
ccc: function(el, options){
alert(el[0].id);
}
}
};
};
})(jQuery);
$(function() {
$.aaa.bbb.ccc( $("#el") ); // alerts "el"
});

How does jQuery protect overwriting jQuery and $

These variables are located immediately after defining a local copy of jQuery in the jQuery source.
// Map over jQuery in case of overwrite
_jQuery = window.jQuery
// Map over the $ in case of overwrite
_$ = window.$
One can read the comments and know the why... but
How do these lines of code do this?
Would adding something similar protect my personal namespace or is there more too it deeper in the source?
What is an example of something bad that could happen if this weren't in the source code?

If you look through the jquery.js file you will find that they start by saving the previous definition (line 31-32 v1.4.4):
// Map over the $ in case of overwrite
_$ = window.$,
Then if you call noConflict it just sets the value back (line 397-398)
noConflict: function( deep ) {
window.$ = _$;
You can add something similar to your own project to protect the name space. The concept holds for more than just javascript.
If these lines were not included, then you wouldn't be able to run jQuery and Prototype on the same page as both use the $ operator - nothing bad may happen, it's just that your code won't work and possibly cause errors.

How does jQuery protect overwriting jQuery and $
It doesn't (but see below). If you load jQuery, and then load something else that writes something else to those symbols, they won't be associated with jQuery anymore. Example:
HTML:
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>
<script src="http://ajax.googleapis.com/ajax/libs/prototype/1/prototype.js"></script>
JavaScript:
window.onload = function() {
// Outputs false, because Prototype has overwritten it
display("Does $ === jQuery? " + ($ === jQuery));
// Outputs true, because Prototype has overwritten it
display("Does $('foo').id === 'foo'? " + ($('foo').id === 'foo'));
function display(msg) {
var p = document.createElement('p');
p.innerHTML = msg;
document.body.appendChild(p);
}
};​
Live copy
But, it does seem to preserve them. How?
The answer is closures. It has a local reference, inside its scoping function, which is unconnected to the global reference (the property on window), so internally it doesn't care whether you overwrite those symbols. Of course, you care, if you overwrite both $ and jQuery, because if you do you have no way of calling jQuery. :-) But if you only overwrite $, that's not a problem, just use jQuery or if you don't like typing that (and let's face it, it's awkward), do this:
(function($) {
// Your usual jQuery code here using `$`,
// this code runs immediately
)(jQuery);
...which shadows the $ symbol locally within the anonymous function (which is defined and called at the same time). jQuery makes this particularly easy if you're using its ready event:
jQuery(function($) {
// Your usual jQuery code here using `$`,
// this code runs when the DOM is ready (see
// the `jQuery.ready` function).
});

If you were to include another library like prototype, which uses $, then jQuery needs to have a reference of both $ and window.jQuery in order to support the jQuery.noConflict() function, etc...
http://api.jquery.com/jQuery.noConflict/
$ is used because it is convenient, but this comes at the price that it may be used by more than one library.
Does that help?

Javascript doesn't have the means of providing the kind of protection you are looking for.
JQuery isn't "protecting" those variables. It's just copying the references $ and jquery into two other variables. The code you have read is equivalent to:
var obj1 = {}; /* create an empty object and reference it as obj1 */
var obj2 = obj1; /* made a second reference to that same object */
This code doesn't "protect" obj1. It's perfectly valid that your code later on changes the value of obj1:
obj1 = 'foo'; /* now obj1 references a string */
obj1 doesn't "magically retain its value"; after that line, it's just a string. But the object is still available in obj2.

The purpose of those lines is to be able to restore the original $ and jQuery global variables in case jQuery itself overrides them. It doesn't do anything to protect other code from overriding jQuery.
If you want to protect your own namespace, you can do a setInterval that checks if the global variable is still an instanceof your object (only if your object is protected inside a closure, otherwise it can be modified too). But, this isn't good practice, as the idea of javascript is to be able to extend and customize. Put the control in the hands of the developer, don't try and "lock in" your objects.

Javascript plugins design pattern like jQuery

Could someone write down a very simple basic example in javascript to conceptualize (and hopefully make me understand) how the jQuery plugin design pattern is done and how it works?
I'm not interested in how creating plugin for jQuery (so no jQuery code here at all).
I'm interested in a simple explanation (maybe with a bit of Javascript code) to explain how it is done the plugin concept.
Plz do not reply me to go and read jQuery code, I tried, but I it's too complex, otherwise I would have not post a question here.
Thanks!

jQuery has a library of functions stored in an internal object named fn. These are the ones that you can call on every jQuery object.
When you do $("div.someClass") you get a jQuery object containing all <div> elements of that class. Now you can do $("div.someClass").each( someFunction ) to apply someFunction to each of them. This means, that each() is one of the functions stored in fn (a built-in one in this case).
If you extend (add to) the internal fn object, then you automatically make available your custom function to the same syntax. Lets assume you have a function that logs all elements to the console, called log(). You could append this function to $.fn, and then use it as $("div.someClass").log().
Every function appended to the fn object will be called in such a way that inside the function body, the this keyword will point to the jQuery object you've used.
Common practice is to return this at the end of the custom function, so that method chaining does not break: $("div.someClass").log().each( someFunction ).
There are several ways to append functions to the $.fn object, some safer than others. A pretty safe one is to do:
jQuery.fn.extend({
foo: function() {
this.each( function() { console.log(this.tagName); } );
return this;
}
})

Tomalak already posted almost everything You need to know.
There is one last thing that helps jQuery do the trick with the this keyword.
it's amethod called apply()
var somefunction=function(){
alert(this.text);
}
var anObject={text:"hello"};
somefunction.apply(anObject);
//alert "hello" will happen
It really helps in creating abstractions so that framework/plugin users would just use this as intuition tells them, whatever there is inside Your code

It works, as many other js frameworks, using javascript prototype orientation.
For instance you can declare a simple function
var alertHelloWorld = function() {
alert('hello world');
}
And then tie it to an existing object (including DOM nodes)
document.doMyAlert = alertHelloWorld;
If you do this
document.doMyAlert();
The alertHelloWorld function will be executed
You can read more about javascript object prototyping here

How to make custom, no editing need, bulletproof jquery's noconflict version?

in my job i always have to use jquery with prototype can i make any custom jquery with library file like once i will add in head and then no need to change anything in any code.
is it possible?
I don't want to change anything in an code $ to jQuery.

from http://www.cssnewbie.com/runing-jquery-with-other-frameworks-via-noconflict/
Keeping it Short
The noConflict mode does have one other bit of functionality that I’ve found useful in some of my projects: you can select a different variable to use instead of the standard “jQuery”. The usage looks like this:
var $j = jQuery.noConflict();
Now in addition to using the default jQuery() notation, I can also use the shorter $j() notation. This allows me to avoid running into problems with other frameworks, while still enjoying almost the same conciseness in my code.

This just begs the question why dont you simply implement all your stuff in Prototype then - or implement everything in jQuery. Overall they both have the same capabilities.
However to directly answer your question - ther isnt really a way to make a custom build of jQuery. But you could simply put your noConflict call immediately following your inclusion of the jQuery library.
Then for your stuff you can simply wrap it all in
(function($){
// your jQuery code here... Can be used with $ as normal.
})(jQuery);
within that function youll be able to use $ as the alias - outside of it you would need to use jQuery. The only gotcha here is that if you want a variable defined inside here to be global youll need to make it that way manually as everything within this will be scoped to the function. You can do this like so:
(function($){
window.myGlobalVar = 'This is a global variable';
})(jQuery);

The best thing is often to wrap the $ in a private scope:
(function($) {
// jQuery stuff
})(jQuery)
You can also call the jQuery.noConflict() function before the wrap: http://api.jquery.com/jQuery.noConflict/
Another clean option is chaining the noConflict() into a domReady callback:
jQuery.noConflict()(function($){
// code using jQuery or $
});
console.log(typeof $ === 'undefined') // prints true

To address your question of whether you can have an "include-once" file, yes, you could do something similar to:
/* MyLibLoader.js */
document.write("<script type='text/javascript' src='prototype.js'></script>");
document.write("<script type='text/javascript' src='jquery.js'></script>");
window.$j = jQuery.noConflict();
And then in HTML
<head>
<script type='text/javascript' src='MyLibLoader.js'></script>
</head>
But this approach assumes you're happy to change your jQuery usage to $j