Wsrtjtyk

The following works as expected:

$(".foo").first().text("hi!")

...because first() returns a jQuery object.

However, if I want to work with the text() method for all matches, I need to do:

$(".foo").each( function(idx, obj) {

  $(obj).text("hi!")

  }

)

...because each() gives you DOM objects.

What is the design reason behind this baffling difference? How can I avoid having to build a jQuery object for each match?

Possibly due to performance reasons related to looping over large collections? If you only need the DOM objects, then you save cycles. If you need the jQuery object, then you can easily get that.

I typically don't provide the 2nd parameter to each, so I can use $(this).

Internally jQuery call this for $("sel").each(function(){});

if ( isObj ) {

    for ( name in object ) {

        if ( callback.call( object[ name ], name, object[ name ] ) === false ) {

            break;

        }

    }

}

And the eq is a simple slice:

eq: function( i ) {

    return i === -1 ?

    this.slice( i ) :

    this.slice( i, +i + 1 );

}

So you can create a new each function that instead of object[name] will do a object:eq(i)

$("*").slice(1,2).toSource() == $("*").eq(1).toSource();

So to create your own each:

$.fn.each2 = function(callback)

{

   for ( var i = 0; i < this.length; ++i ) {

      callback.call( this.eq(i), i, this.eq(i) )

   }

};



$("*").each2(function(i, obj) {

    alert(obj); // now obj is a jQuery object

});

It seems that each3 is faster than each2 http://www.jsfiddle.net/m7pKk/2/

$.fn.each2 = function(callback)

{

   for ( var i = 0; i < this.length; ++i ) {

       var jObj = this.eq(i);

      callback.call( jObj, i, jObj )

   }

};



$.fn.each3 = function(callback)

{

   for ( var i = 0; i < this.length; ++i ) {

       var jObj = $(this[i]);

      callback.call( jObj, i, jObj )

   }

};

See this example on jsFiddle with performance measurement.

There's the obvious performance hit that would be taken per iteration. Creating a new jQuery object each iteration would be much slower and probably noticeable over large collections. Quite often, you don't need the added convenience of the wrapped object, especially when accessing single attributes or properties. All too often you see cycle wasting code like $(this).is(":checked") instead of this.checked.

Aside from that, though, I would say that it's because it makes sense. A jQuery object typically represents a collection of DOM objects that can be any number in size. Sometimes jQuery is used purely for its selector support and event binding and not much beyond that. It doesn't make much sense to return a collection containing a single element when iterating over a collection of more elements. It makes much more sense to return a single item that you're more likely to need, the DOM element, then you can wrap it with jQuery if you want the added features. This also keeps it in line with iterating over NodeList and other types of collection.

I believe that since jQuery uses wrapper objects, the first method uses the original wrapper, and just removes all but the first element in the wrapper, thus keeping it being a jQuery object.

However, if they were to feed in a jQuery object for each of the nodes for the each() function, they would be incurring that overhead of creating the wrapper for each one. And since you don't necessarily want that wrapper object, it would incur unnecessary overhead.

Probably because, in your example there's no reason to even use each. Instead of:

$(".foo").each( function(idx, obj) {

  $(obj).text("hi!");

)

Just use:

$(".foo").text("hi!");

Everything is automatically plural when dealing with jQuery sets.