citeproc-js and JavaScript engines Was: Disambiguation: changes to test fixtures

To return briefly to the issue of executing citeproc-js using embedded JavaScript engines. In the meantime I am able to use citeproc-js embedded into Ruby using either Rhino (for JRuby) or SpiderMonkey (for Ruby 1.8.7); because the V8 is so fast it would be great to use that to run citeproc-js, too; however, the engine itself comes without the DOM parsing functions (such as getElementsByTagName) – could anyone suggest a good DOM parsing solution for citeproc-js + V8? (Perhaps ‘jsdom’?)

Many thanks!


If you’re planning to parse a style and then use it many times, jsdom would work. It’s what we use in citeproc-node ( However, jsdom is glacially slow, at least with larger documents. If you can’t cache and reuse styles, it’s possible that SpiderMonkey would be faster than V8+jsdom.


Have you checked on the state of alternative XML libraries lately Simon?

I see this mentioned a fair bit, for example:

Like o3 (which is now on npm) it has some dependencies though (but
libxml is notoriously fast):

Still hoping we can get to “npm install citeproc” at some point.


The idea was to use it for the cite processor test suite to simultaneously test citeproc-js, citeproc-hs and citeproc-ruby, i.e. I would mostly use very short styles but caching is more or less out of the question. My results with SpiderMonkey are very encouraging so I will probably stick with it.

Many thanks,


o3 crashes and leaks memory, which makes it unsuitable for use in a production environment. My understanding is that libxmljs is the only working DOM parser. Unfortunately, the DOM it exposes isn’t W3C-compliant, so it was unsuitable for my uses when I was testing it. citeproc-js would need a new XML parsing module to support libxmljs’s non-standard API, but it could probably be made to work. However, it may not simple to adapt a node.js binary package to run in Ruby.

SpiderNode (, which is node.js ported to use SpiderMonkey instead of V8, presumably has E4X support. However, I’ve been hearing rumblings that, at some point, Mozilla will be rewrite a large part of their E4X implementation in pure JS and remove features that can’t be implemented with an ES5 Harmony proxy.