Wicked Good XPath: Fast Xpath on Javascript

We are pleased to present a new library developed by Google - Wicked Good XPath , an implementation of the XPath specification for DOM Level 3 . We are sure that today this library is the fastest of all existing ones.

To start using it, simply download the wgxpath.install.js file and enable it on your page.


')
Then call the w gxpath.install() method in the page code, which will provide access to the document.evaluate , the Xpath navigation function, in the current window. If you need to add library functionality in another window, just pass the pointer to this window to the install() method.

Despite the growing popularity of CSS selectors, XPath is still a useful tool for selecting elements in an HTML document. It is especially used in front-end testing applications such as Selenium and Web Puppeteer . Well, sometimes there are times when Xpath is the only possible solution for accessing certain elements on a page.

If you've never met an Xpath before, take a look at an example: on the Google search results page, the expression //li[@class=”g”][3] will point to the third result in the list. This can be seen from the screenshot of the Chrome Xpath Viewer plugin.



The main difficulty in using XPath is the lack of native support in some browsers. For example, IE does not support XPath on HTML documents. As a result, many developers are forced to use Javascript solutions. Back in 2005, Google engineers released the AJAXSLT library, which implemented the correct, but not very fast, Xpath work. Querying this library in IE has been quite long.

Later, in 2007, Cybozu Labs introduced another library, Javascript-XPath , which was 10 times faster than AJAXSLT. Many testing applications switched to it, and everything was fine, but not for long. The library quickly lost support, there was no one to fix bugs. Well, in view of the fact that it was not written on Google Closure , it was difficult for us, the Google users, to implement it into their applications. The library needed to be rewritten.

But we didn't just port it to Google Closure. We made some corrections that significantly affected the performance of the library - our version runs 30% faster than the original. In addition, the Closure compiler was able to shrink it to 25 KB, which is 40% less than Javascript-XPath. Well, finally, we are confident that the new structuring, and the documentation of the code will provide speed and ease in the further support of the library.

Separately, we would like to thank our two interns, Google-a, Michael Zhou and Evan Thomas, who have done most of the work in this project.

Google engineers, Greg Dennis and Joon Lee.