Since the xml-module was written there have been "good looking" developments/discoveries of xml libraries for nodejs and in pure javascript.
The focus of the xml module is to provide a unified access to XML-DOM (w3c) apis for the browsers and for nodejs.
On further task will be to provide the same interfaces for WebWorkers where no access to the browser DOM api is given.
The current approach using libxmljs for parsing and jsdom for the object model is cumbersome. Often in the past libxmljs would not compile straight with the latest node releases and thus be difficult to use and time-consuming to repair/find a workaround.
jsdom in turn has a much broader focus on recreating a complete browser environment within nodejs. Which also means a lot of dependencies and complexity. E.g. it would execute HTML5 with Javascript+jQuery, it can do AJAX etc. To accomplish that all the library focuses much more on getting HTML5 right than on XML. There are similar build problems with some node-js versions for dependencies of jsdom as with libxmljs.
Then, the APIs that we use are deeply buried within jsdom and not "officially anounced" public interfaces, also, they are not quite implemented as in the browsers.
Further, jsdom since version > 3.x requires nodejs >= 4.x. There is no good reason why we, with our much more minimalistic xml-needs should follow that in a rush (node is still on 0.10.x on some linux distros). Thus, right now we are stuck at jsdom 3.x
A purely in JavaScript fallback to the native browser API would be best, because it would solve some issues for us:
unproblematic dependencies i.e. the whole pipeline of c-compilers, gyp etc. wouldn't cause problems anymore (which is the case on a fairly regular basis)
we can easily use ufoJS in WebWorkers (which is an important feature for future plans)
much easier install for contributors and easier packaging
Here are some options (not fully evaluated and probably not a complete list):
http://xmljs.sourceforge.net/index.html looks like a very complete choice. (It also includes XPath, which we need!) the Sourceforge hosting is a bit antiquated. When evaluating this, project activity/health should be checked. This could be a good one.
https://github.com/goto100/xpath plus https://github.com/jindw/xmldom Both look like pure JS. However, the focus seems to be node-js. If useful, we could ask how much the stated nodejs focus could be turned into a more general JavaScript focus. The WebWorkers use case is a strong one. I'd like to test this option against the previous one.
https://github.com/kripken/xml.js This is libxmljs translated with emscripten, so it is probably fast, however, it doesn't com with the w3c-dom. When there are speed issues with parsing with the final library choice, this could be a replacment. Currently our xml module in nodejs mode uses the sax-parser of the libxmljs-(binding library to libxml) to construct a DOM tree using dom-apis.
Since the
xml-module was written there have been "good looking" developments/discoveries of xml libraries for nodejs and in pure javascript.The focus of the xml module is to provide a unified access to XML-DOM (w3c) apis for the browsers and for nodejs. On further task will be to provide the same interfaces for WebWorkers where no access to the browser DOM api is given.
The current approach using
libxmljsfor parsing andjsdomfor the object model is cumbersome. Often in the pastlibxmljswould not compile straight with the latest node releases and thus be difficult to use and time-consuming to repair/find a workaround.jsdomin turn has a much broader focus on recreating a complete browser environment within nodejs. Which also means a lot of dependencies and complexity. E.g. it would execute HTML5 with Javascript+jQuery, it can do AJAX etc. To accomplish that all the library focuses much more on getting HTML5 right than on XML. There are similar build problems with some node-js versions for dependencies of jsdom as with libxmljs. Then, the APIs that we use are deeply buried within jsdom and not "officially anounced" public interfaces, also, they are not quite implemented as in the browsers. Further, jsdom since version > 3.x requires nodejs >= 4.x. There is no good reason why we, with our much more minimalistic xml-needs should follow that in a rush (node is still on 0.10.x on some linux distros). Thus, right now we are stuck at jsdom 3.xA purely in JavaScript fallback to the native browser API would be best, because it would solve some issues for us:
Here are some options (not fully evaluated and probably not a complete list):