On Mar 30, 11:12 pm, Ricardo <[email protected]> wrote:
> The docs say all that is needed:
>
> "By default, if no context is specified, $() looks for DOM elements
> within the context of the current HTML document. If you do specify a
> context, such as a DOM element or jQuery object, the expression will
> be matched against the contents of that context."
Hm? This seems to complex for an API call ? A LOT of problems arrise
from the fact
that $() signature has optional arguments, and several outcomes, plus
some outcomes which are result of "forgivnes" for users who does this
'$()' or this call '$(selector)', or this call $(string, string)...
but this is a matter of taste I suppose ... I tried to explain that
this kind of API makes novices get easier into the wrong habbits.
>
> The speed difference I mentioned is insignificant for most jQuery
> users, you'll start optimizing other stuff way before that.
jQ (or not) enabled web apps grow in complexity every day. It is very
difficult to control teams of jQ users, how are they using jQ. I have
seen blogs where lead developers complain. As I explained somewhere in
this discussion. To these team leders very flexible and forgiving $()
is very quickly becoming an issue. Because 90% of their large teams
have beein coding it ever so sliglhtly wrongly. Pages have grown and
slow down has became noticeable.
>
> I don't understand what you're arguing either,
this here and a lot of stuff in this discussion I have posted.
> there is no sensible reason to enforce the context argument. Everyone can see
> that it's the "current HTML document" by default, and it's expected behavior.
There is only one reason: speed.
>
> "Ah yes, and jQ "next" needs to stop the abundance of $(selector)
> calls, and enforce $(selector, scope ) calls."
> Why, what's the advantage? Performance is not always better, and that
> would bloat code a lot, why would you want to type 'document' over and
> over?
As I explained I would not want to type 'document'. I would "force" my
team to use always a second argument if the first one is a query. And
I would force them to give a proper second argument , so that scope is
narrow and query is fast. On my blog I suggested a solution for that,
as a simple javascript function. A link is somewere in my recent
postings here.
>
> "introduce selection scoping" - what would that be? $(selector).find
> (stuff) is already supported.
Exactly. Is terminology confusing here? Selection scoping is an usual
term used in
every selection (aka querying) language. For example SQL always
imposes very narrow scope (aka TABLE) : "SELECT <what> FROM <scope>
WHERE <filter>"
While jQ allows users to simply ignore the "scope" and let jQ make the
rezult set, by looking into the whole dom tree, each time...
Fortunately browsers keep indexes of id's of elements which are hash
tables of pointers to the dom tree. But still this "scoping" gives
significant speed boost to the query:
jQuery(<scope>).find(<what>)
>
> jQuery is constantly optimized for every possible use case, not just
> "well balanced" DOM trees.
What is left is to "optimise" the users. The usage patterns.
Programming idioms, etc.
> Guaranteeing that is beyond the grasp of a
> JS framework, good development practices should be left out of the
> documentation.
Really? What would David Flanaggan think of that? Or Bjarne
Stroustrup? Or Douglas? Or ... History of computer science is dotted
with few books as cornerstones which are all in essence API
documentations, but vastly enriched with a lot of brilliant examples,
peppered with good development practices.
Cheers: Dusan
>
> cheers,
> - ricardo
>
> On Mar 30, 4:33 am, DBJDBJ <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>:
>
> > > > >>>> 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
>
> ...
>
> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
