modisposition

As usual, as soon as I decide it's time to go to sleep, somebody :P has to post a stunning benchmark about a selector matcher ... did I shut down? No, I had to read the entire source code of the library, and this is my quick summary, but consider I am tired ... NWMatcher , A Selector Monster First of all, I did not know or remember this project and I must congrats with Diego Perini for different reasons. The first one is that Diego used almost all best and unobtrusive technique to make it as reliable as possible, which is good, the second one is that Diego introduced something new to achieve its goal: create a Ferrari matcher via pre- compiled functions. About NWMatcher It is a lightweight stand alone library (so far, but already namespaced) which aim is to standardize some common DOM related task. The initial aim was to create a faster way to understand if a node matches a specific selector, something truly useful with event delegation. About The Technique To make things as fas...

Update I completely re-wrote the test suite. You can check a live example here where results are compared with Sizzle selector engine against the common W3C page. After this Ajaxian post and some opinion exchange in its comments, I decided to extract the css2xpath function I used inside experiments in vice-versa project , creating a separated project specific for this purpose that some how could be interesting or useful. Bugs, problems, questions, and helps are more than welcome, so far I focused my attention to SlickSpeed test selectors and nothing else but at least for that it seems to be stable and reliable.

I am putting some effort to make vice-versa project a good, production ready, alternative against common libraries, and since these days I am working hard with XML, XSL(T), and XPath I decided to try an experiment implementing CSS to XPath translator for FireFox 3.0 With version 3.1 we will have querySelector and querySelectorAll but version 3.0 is still the most used one, FireFox speaking! The nightly build of vice-versa introduces a new file, mainly used for personal experiments via vice-versa library and the first experiment is an improved document.query for those browsers with document.evaluate support without document.querySelectorAll . Unfortunately Internet Explorer SlickSpeed Selector Speed Test comparing latest version of each library such Dojo , DOMAssistant , Sizzle (congrats for the new site!), Sly , and finally vice-versa project. Here the summary, from faster to slower: vice-versa 760ms Dojo 1.3.1 868ms (2 tests failed) DOMAssistant 880ms (good stuff Robert!)...

Thanks to new DOM methods introduced recently in most common browser, e.g. querySelectorAll, we will not hopefully need full libraries to implement common CSS selectors. Nowadays, this could be the basement to create any kind of selector engine but we are still stack with old fashion browsers a la Internet Explorer version 6 or 7, both far away from W3 standards and with the slowest JavaScript engine in browsers panorama. At the same time, whatever great selector API/engine we have under control, most used selectors are really few: #id .class tag tag.class Reasons behind this fact are different, but in my opinion the most valid one is that Web Developers use CSS selectors in the same way they create CSS files and since CSS has become standard only recently thaks to Internet Explorer full CSS 2.1 support (n.d. other browsers are working on the CSS 3 since ages ...) our CSS files and our selectors will be that simple for long time. Accordingly, and since we have some intermediate and co...