The fact that $('#foo').find('.someclass'); is faster than $('#foo 
.someclass'); right now is completely irrelevant to reasonable arguments.
While it may be faster now, it is highly likely that future work to the 
selector engine will soon reverse that statement and make the former 
faster than the latter.
Not to mention that the latter is also unnecessary code when you aren't 
trying to find the intermediate nodes.

The second argument to $ is NOT scope, it's context. Context is meant to 
tell jQuery what document is being used, or document node if you are 
dealing with nodes given to you from outside sources.
If you want scope, use scope: $(scope).find(selector);
The fact that $(selector, context); is an internal alias to 
$(context).find(selector); and as a side effect you can use it for scope 
is also irrelevant.

By saying that $(selector) calls should be enforced as $(selector, 
scope); calls you are saying that $(scope).find(selector); calls should 
be avoided.
This counters the whole point of making code readable and sensible.

~Daniel Friesen (Dantman, Nadir-Seen-Fire)

DBJDBJ wrote:
> @Thanks Ricardo, this is actually very on the topic ;o)
>
> I do not understand what is beiong argued here? If anything ? My
> assertions are certainly not "horrible lies"? I knew this speed
> difference , (and Daniel should know by now ...)
>
> We just need jQ "next" to sort out the lack of explanation in the
> docs, arround context.
> And to introduce selection scoping
> And to support the explanations with examples of well balanced dom
> document trees.And their goodnes for faster web.
> Ah yes, and jQ "next" needs to stop the abundance of $(selector)
> calls, and enforce $(selector, scope ) calls.
>
> I have done some R7D here, on the subject: http://x.dbjsystems.com/blog/?p=86
>
> Thanks ...
>
> On Mar 29, 12:52 am, Ricardo <ricardob...@gmail.com> wrote:
>   
>> A bit off-topic: actually in 1.3.2, due to the bottom-up filtering
>> approach, $('#foo').find('.someclass') is about 3x faster than $
>> ('#foo .someclass'). See for yourself:http://jquery.nodnod.net/cases/273/run
>> (enable firebug)
>>
>> Some improvements to that have been landed a few weeks back, it was
>> even worse. But in other situations the single string selector is
>> faster, it depends on the selector complexity and size of the DOM.
>>
>> cheers,
>> - ricardo
>>
>> On Mar 27, 7:09 pm, Daniel Friesen <nadir.seen.f...@gmail.com> wrote:
>>
>>     
>>> Context is not scope!
>>>       
>>> Context's purpose is not to narrow down querying. It is perfectly valid
>>> to use a selector without context. Context's purpose is for sorting out
>>> document context.
>>>       
>>> You're telling me that my $('#foo .someclass'); selectors are slow
>>> because they don't have context, which is a horrible lie.
>>>       
>>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire)
>>>       
>>> DBJDBJ wrote:
>>>       
>>>> Can we just have next  jQuery(selector, context)  version throw an
>>>> exception,
>>>> IF context argument is not jQ instance or dom element exception will
>>>> be thrown. As simple as that.
>>>>         
>>>> I would even suggest going even further. Throw an exception if context
>>>> argument is not given.
>>>> Make context mandatory. And make it right.
>>>>         
>>>> Otherwise people will start blaming jQuery for slow pages, instead of
>>>> sorting out their lazy $(selector) calls without any context given
>>>> to act as a SCOPE to narrow down the querying of the dom document
>>>> tree ...
>>>>         
>>>> On Mar 26, 3:04 pm, Daniel Friesen <nadir.seen.f...@gmail.com> wrote:
>>>>         
>>>>> Example 1 is invalid jQuery.
>>>>>           
>>>>> Example 2's speed comparison to Example 3 is trivial. In fact Example 2
>>>>> has an advantage to it. Do remember IE6's bug with getElementById,
>>>>> jQuery's selectors have code to fix that bug.
>>>>>           
>>>>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire)DBJ wrote:
>>>>>           
>>>>>> // jq132-vsdoc.js, line # 145
>>>>>>  return jQuery(context).find(selector);
>>>>>>             
>>>>>> From this one might draw following Conclusions :
>>>>>>             
>>>>>> C1:  if context is not a dom document jQ will find things faster
>>>>>>        because the scope of the search is narrow(er)
>>>>>> C2: if context above is a single dom node (aka element) jQ will
>>>>>>       find things the fastest, please refer to:  jq132-vsdoc.js, line # 
>>>>>> 107
>>>>>>             
>>>>>> (please everyone use this structure in a discussion :
>>>>>> <body>
>>>>>>    <span id='people'>
>>>>>>      <span id='person' name='john' ></span>
>>>>>>      <span id='person' name='bad robot' ></span>
>>>>>>     <!-- and so on -->
>>>>>>   </span>
>>>>>> </body>
>>>>>> )
>>>>>>             
>>>>>> We are in the royal mess because we have no crystal clear and
>>>>>> unambigious terminology here. On top of that one important term is
>>>>>> missing:
>>>>>> SCOPE.
>>>>>>             
>>>>>> Right now we have this (by now apparently) ambiguous term: CONTEXT.
>>>>>> Sometimes it is (acts like, is used for) scope and sometime it does not.
>>>>>>             
>>>>>> 1 :: $("[name]", "#people" )  // CONTEXT
>>>>>> (internaly: selector := "#people     [name]", context := document )
>>>>>>             
>>>>>> 2 :: $("[name]", $("#people") ) // SCOPE
>>>>>> (internaly: selector := "[name]", context := element with id 'people'  )
>>>>>>             
>>>>>> 3 :: $("[name]", document.getElementByID("people") ) // SCOPE
>>>>>> (internaly: selector := "[name]", context := element with id 'people'  )
>>>>>>             
>>>>>> Do we all agree  with the above? If not we have to, I think.
>>>>>>             
>>>>>> Furthermore. Line 3:: above is the fastest possible $() , because it
>>>>>> boils down to  :
>>>>>> $( document.getElementByID("people")).find("[name]") ;
>>>>>>             
>>>>>> This provides immediate and narrow scope for Sizzle to work in.
>>>>>> (reminder: jQuery.find = Sizzle )
>>>>>>             
>>>>>> And last but not the least >:o)
>>>>>>             
>>>>>> Please refer to : jq132-vsdoc.js, line # 100
>>>>>>             
>>>>>> What am I asking for is to enforce this in jQuery. Nothing much and
>>>>>> nothing else. So :
>>>>>>             
>>>>>> $( selector:string, context:string )
>>>>>>             
>>>>>> Should be forbidden. should throw an exception.
>>>>>>             
>>>>>> The non-enforcing style of jQuery sometimes bears no fruit. The above
>>>>>> line is now possible, same as just saying : $() , because jQuery
>>>>>> authors think it is a "good thing" not to slap junior or senior but
>>>>>> lazy jQuery users, when they do these kind of coding.
>>>>>>             
>>>>>> But. It is a fact that companies are using jQuery. The more they use
>>>>>> it, the more problems they have with code that uses context in a wrong
>>>>>> way. And. 90% of coders actualyl use no context at all. The badly
>>>>>> written code mushroms and slows things down exponentially. One way out
>>>>>> if that (mess?) would be to enforce proper usage of context and define
>>>>>> the term SCOPE. Explain it to people and gently force them to use it.
>>>>>>             
>>>>>> 2009/3/26 Daniel Friesen <nadir.seen.f...@gmail.com>:
>>>>>>             
>>>>>>> I disagree. First thing to note is there are two definitions of context.
>>>>>>> jQuery(selector).context; And jQuery(selector, context);
>>>>>>>               
>>>>>>> They are two different things which overlap just a bit.
>>>>>>> jQuery(selector).context; Is the document context. It is the only
>>>>>>> "context" that is stored in jQuery.
>>>>>>>               
>>>>>>> jQuery(selector, context); Is a node/document context for the query.
>>>>>>> It's primary purpose is to establish document context so that jQuery
>>>>>>> knows what document (current document, an iframe, another frameset) to
>>>>>>> perform selectors in and use when constructing new document nodes to
>>>>>>> insert. It does have the ability to be used to limit the scope of a
>>>>>>> query, however that is unintuitive and makes programs confusing to read.
>>>>>>>               
>>>>>>> Your pagination example would be better handled in a different way:
>>>>>>> $('.pagination .pagelist'); // jQuery selectors are not single-level.
>>>>>>> Don't think everything needs to be separated into contexts. Most of the
>>>>>>> time it doesn't
>>>>>>> var pagination = $('.pagination');
>>>>>>> $(pagination).find('.pagelist'); // $(selector, context); is just an
>>>>>>> alias to $(context).find(selector); don't abuse it in ways that don't
>>>>>>> make sense
>>>>>>> pagination.find('.pagelist'); // Your use of another jQuery selector is
>>>>>>> completely unnecessary anyways, you already have a jQuery object just
>>>>>>> use .find
>>>>>>>               
>>>>>>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire)
>>>>>>>               
>>>>>>> chris thatcher wrote:
>>>>>>>               
>>>>>>>> I'm trying to follow this thread but it's a little loose so apologies 
>>>>>>>> if I'm
>>>>>>>> missing the point.
>>>>>>>>                 
>>>>>>>> The only thing I want to disagree with is the last point.  it doesnt 
>>>>>>>> matter
>>>>>>>> whether the context is a class or id.  The context's function is to 
>>>>>>>> reduce
>>>>>>>> the scope of the selectors search, and the primary reason for that is 
>>>>>>>> simply
>>>>>>>> performance.
>>>>>>>>                 
>>>>>>>> I know there are many signatures for $, but when providing a selector 
>>>>>>>> and
>>>>>>>> context the primary goal is to reduce the scope of the current 
>>>>>>>> selector.
>>>>>>>> There are plenty of cases where the context is a large set of nodes.
>>>>>>>>                 
>>>>>>>> For example I might need to modify a portion of the dom that 
>>>>>>>> represents a
>>>>>>>> pagination interface that is provided at the top and bottom of the
>>>>>>>> interface.  So I create a contect based on the class representing the
>>>>>>>> interface. Say
>>>>>>>>                 
>>>>>>>> var pagination = $('.pagination');
>>>>>>>>                 
>>>>>>>> Then to update a potion of that sub-dom I would do somthing like:
>>>>>>>>                 
>>>>>>>> myCustomUpdate($('.pagelist', pagination));
>>>>>>>>                 
>>>>>>>> This saves jquery from having to seach the entire document  for 
>>>>>>>> elements
>>>>>>>> with the class 'pagelist', a big win. Instead the selector only looks 
>>>>>>>> under
>>>>>>>> the element array represented by the context array for my variable
>>>>>>>> 'pagination'.
>>>>>>>>                 
>>>>>>>> Does this help you?  can we talk in very general examples to help 
>>>>>>>> illuminate
>>>>>>>> the cases you are concerned about?
>>>>>>>>                 
>>>>>>>> Thatcher
>>>>>>>>                 
>>>>>>>> On Wed, Mar 25, 2009 at 8:53 PM, Julian Aubourg 
>>>>>>>> <aubourg.jul...@gmail.com>wrote:
>>>>>>>>                 
>>>>>>>>>> In my mind context (as I said but I will repeat ;) should be only dom
>>>>>>>>>> node, or single id string. If given by user. So these will be only
>>>>>>>>>> three valid forms:
>>>>>>>>>>                     
>>>>>>>>> I so disagree with this. If we're talking efficient pages here, you 
>>>>>>>>> HAVE to
>>>>>>>>> authorise a jQuery object as context.
>>>>>>>>> Say you have a list of items with elements within you wanna bind click
>>>>>>>>> handlers to. A nice way (and AFAIK efficient, both in term of 
>>>>>>>>> performance
>>>>>>>>> AND memory consumption) to do so would be like this:
>>>>>>>>>                   
>>>>>>>>> var items = $(itemSelector);
>>>>>>>>> $(subElementSelector1,items).click(function() {...});
>>>>>>>>> $(subElementSelector2,items).click(function() {...});
>>>>>>>>> ...
>>>>>>>>> $(subElementSelectorN,items).click(function() {...});
>>>>>>>>>                   
>>>>>>>>> Your idea of having only *1* dom node or to limit context expressions 
>>>>>>>>> as id
>>>>>>>>> only would forbid such a construct and would only lead to a less 
>>>>>>>>> elegant and
>>>>>>>>> less efficient solution.
>>>>>>>>>                   
>>>>>>>>> I'm a great fan of contexts and use them as often as I can. They are 
>>>>>>>>> as
>>>>>>>>> good as the power of expression we have to express them. Reduce that 
>>>>>>>>> and you
>>>>>>>>> can be sure no one will ever use contexts again, at least not in a
>>>>>>>>> real-world web application where ids are far less used than classes.
>>>>>>>>>                   
>>>>>>>>> To me, the rational behind contexts within jQuery is crystal clear. 
>>>>>>>>> Why
>>>>>>>>> reduce it to a getElementById wrapper?
>>>>>>>>>                   
>>>>>>>>> 2009/3/26 DBJ <dbj...@gmail.com>
>>>>>>>>>                   
>>>>>>>>>> This is, of course, true and fine. Exactly the purpose of the 
>>>>>>>>>> context.
>>>>>>>>>> To define the starting node BELLOW which it will look further. Fine.
>>>>>>>>>> It is only that this is not what current documentation is saying :
>>>>>>>>>>                     
>>>>>>>>>> http://docs.jquery.com/Core/jQuery#expressioncontext
>>>>>>>>>>                     
>>>>>>>>>> At least NOT clearly and NOT unambigously...
>>>>>>>>>>                     
>>>>>>>>>> On top of that jQuery.selector and jQuery.context in this case are
>>>>>>>>>>                     
>> ...
>>
>> read more ยป
>>     
> >
>   

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to