Scott, I would add other parts that don't fit my requirements in XPath: 1) result set is not an array like, you must ".iterateNext()" and push each item in the set 2) XPath "evaluate" method/interface is only available on the document node object 3) It is too slow for the simplest selections compared to both QSA and DOM API
-- Diego On Sat, Sep 10, 2011 at 2:45 AM, Scott Sauyet <[email protected]> wrote: > Austin Cheney wrote: >> Scott Sauyet wrote: >>> You brought up XPath as an alternative to JQuery's >>> selectors API. JQuery (and most competing selector engines) claim to >>> support most if not all of CSS3. >> >> I have compared XPath to CSS selectors. > > Perhaps I misunderstood. > >> jQuery is not compiled byte code, and so it is too slow to be of worthy >> consideration. > > Neither is JSON2.js, code from addthis.com, or third-party analytics > tools. Nor is your own code. > > What speed is necessary to make this worth consideration? If a > selector takes 28 microseconds and another only 21, is the latter one > the only one worth consideration? > >> You can >> easily verify the difference yourself. Just compare a complex operation >> navigating the DOM from one location to a different, and not necessarily >> descendent, location versus using DOM methods while separately timing >> each operation against a millisecond clock. The timing difference is >> staggering, especially for results in a loop and queries against an >> extremely large DOM. [ ... ] > > You seem to be trying to make the case that there is no place in JS > for CSS selectors. But you're discussing situations (loops against > large DOMs) where running queries against the document already don't > really make sense. If CSS selectors don't work for you, don't use > them. The popularity of selector-based query engines demonstrate that > they are useful to many others. > > >>> Do you intend to make a contrast with XPath-style selection? I simply >>> don't see any particular reusability advantages in targeting the >>> preceeding header to the button being clicked with "../../h3" >> >> This goes to the nature of modules. In a modular environment fragments >> are open to reuse in an isolated capacity compared to a wider context. > > I'm sorry, I'm having trouble again parsing that. > > >> Further more if I were unsure if I should expect a h3 element or h4 I >> could use a union: ../../(h3|h4)[0] > > "I'm sorry, your tool is broken. It's not matching my markup. Why > doesn't it target my H5? Why doen'st it match my STRONG element?" > > >> If the ascendance has changed I could use this: >> ancestor::div//(h3|h4)[0] > > And if that takes you up to a div far removed from the relevant > content, because the relevant container is no longer a DIV but a > FIELDSET? > > >>> Actually, I think having multiple classes enhances reusability. >> >> No, because instead of being bound to some context there is a binding to >> the reuse of a name, or naming convention, in addition to the mapped >> context. This overlap is in conflict with the separation of structure >> and behavior principle. The reuse as addressed by your example is >> reuse within a single document and does not illustrate reuse outside of >> a document instance. > > It most certainly illustrates exactly the sort of reuse I'm used to > getting from subsystems, which is precisely that I can use it in > multiple environments with only a minimum of configuration. How would > combining the `debug` and `new` clases into, say `debugNew` improve > portability? I'd say it would significantly degrade portablility of > both the `addNew` and the `showAll` functionality, as it intertwines > them. > > >>> Obviously if we can target specific elements easily, that's the best >>> approach. But that's not always feasible. In the dynamic environment >>> I'm in, it's rarely feasible. >> >> When absolutely ever other approach has failed there are still regular >> expressions, which is still arguably a faster mode of targeting than >> CSS selectors and certainly faster if the CSS selector is being >> Interpreted by interpreted code. > > How would you use regexes to target nodes in the document? What > strings would your test against a regex? > > >>> But perhaps there's some misapprehension here. I am part of a large >>> team working on a very large web application with many dynamic parts. >>> One team member might be involved in tweaking the look by updating the >>> markup or the CSS while others are adding functionality based on >>> certain class names, and occasionally ids. Although there was a >>> significant up-front design effort, the design has been changing as >>> additional requirements are noted. We certainly don't have the luxury >>> of locking down all the markup ahead of time. Perhaps you are able to >>> do so. >> >> This is why module patterns are becoming increasingly more popular. It >> is also evidence that there is benefit in separating the application >> layer from the UI layer. > > Of course, but with no hooks, how does your application layer interact > with the existing UI? Or is your entire UI generated from the > application layer? > > >>> So because you have no need for it in your project it can't make sense >>> in any environment? >> >> From a business perspective, yes, correct. [ ... ] > > I think you misunderstood; either that or there is a very large ego in > play. :-) Let me rephrase: So because Austin Cheney has no need for > it in his project, no one could possibly need it? > > >>> With the right abstractions on top of the former, it could be quite >>> clean. It would probably not outperform plain DOM methods and >>> doesn't, to my mind, gain very much. It certainly could work. But I >>> rarely have had this need either. If I want nodes to be linked, I >>> usually try to do this with related ids rather than assuming a >>> particular DOM relationship. >> >> Not necessarily. The DOM is slow for two reasons: >> 1) It is an API outside of the JavaScript interpreter >> 2) There is only one document object, so while there can be many >> simultaneous read operations there can only be a single write operation >> to a given node at a given time. > > What sort of simultaneity do you expect in a single-threaded > environment? > > >> The first of those reasons is universal to any API that JavaScript must >> access whether it be the regular expression engine, XPath, or even eval. >> There is a performance hit for requesting access to a separate code >> interpreter. Let's consider the two prior examples: >> >> ../../h3[0] >> x.parentNode.parentNode.getElementsByTagName("h3")[0] >> >> The primary difference is that the XPath expression is a single >> operation. The DOM example is three operations. This means in the >> prior instruction set I have to access a foreign API one for XPath, but >> three times for the DOM query. The evaluation of the instructions is >> not slow, but the lookup and access for each instruction comes at a >> cost. This said, it could be argued that the execution of an XPath >> expression should be roughly equivalent to a regular expression >> operation, which is faster than DOM methods and certainly faster than a >> jQuery index. > > Let's talk real numbers here. > > http://jsperf.com/xpath-vs-dom > > There are three tests on there. On a recent version of Firefox, we > could perform the jQuery version with its three separate calls 35K > times per second, whereas we could do the XPath version 49K times per > second. In a recent Chrome, the difference is larger: jQuery, 67K, > XPath, 114K. So if raw speed is what we want for this, then XPath > seems a better solution. Except... the pure dom version runs 1519K > times per second in Firefox and 1560K times per second in Chrome. If > raw speed is what you want, the DOM API is far superior. Moreover, > the XPath code, at least the stuff from MDN, doesn't even work in IE8 > or the Android version I tested. (If you have better code, please > make a new version of that test.) > > And still one more point, your example was around a click-handler for > a button. Presumably selecting the nearby header will only happen > once during that event. How important is it that it runs in 1/49th of > a millisecond versus 1/35th of one? I just don't see the point of > this sort of optimization in that kind of client-side code. > > If you prefer XPath as your selector format, by all means use it. But > it doesn't seem to me that you've demonstrated any particular reason > for others to choose it. > > -- Scott > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
