JamesMGreene / jWalker

A well-tested cross-browser JavaScript implementation of the TreeWalker class defined in the W3C specification for DOM Traversal (DOM Level 2).
http://jamesmgreene.github.com/jWalker/
MIT License
2 stars 1 forks source link

Traversal methods not implemented #2

Closed mskotnikov closed 11 years ago

mskotnikov commented 11 years ago

Hi,

I looked into jWalker.js and found out that all traversal methods of the implementation simply throw "NotImplementedYetException" exception:

this.nextNode = function jWalker$TreeWalker$nextNode() { throw "NotImplementedYetException"; };

Has the library been completed?

JamesMGreene commented 11 years ago

It was completed years ago but due to my employer not allowing me to open source it, I've had to rewrite it from scratch (no worries, it will be all the better for it). Then I just got busy with life: first child born, etc.

I will try to rush an implementation in this week but it won't be in the TDD/Test-First fashion I was hoping for. :)

Thanks for your interest!

~~James

mskotnikov commented 11 years ago

Thanks. By the way, did you measure whether TreeWalker works faster if implemented natively by a browser than a custom JavaScript traversal code (not necessarily emulating TreeWalker API)? In other words, does it make sense trying to use TreeWalker API or custom code will work just fine (except it is standard and other developers may be familiar with it)?

JamesMGreene commented 11 years ago

I don't have any numbers for you but, in my experience, the speed/performance of traversal depends very much on what traversal you're trying to do. For example, if you have a pretty "well-known" traversal path, then you would likely be better using raw DOM access (e.g. Document#getElementById, Document#getElementsByTagName, Document#getElementsByClassName, Document#querySelector, Document#querySelectorAll, etc.) or optimized jQuery selectors — even if it is a small series of them.

I kinda doubt many browser vendors have put in the time to optimize it, i.e. like what Google Chrome has done with V8, optimizing on top of WebKit's JavaScriptCore (JSC) engine. I doubt this mainly because I understand it to be a rarely known/heard of API to even many great JavaScript frontend devs, and thus probably a pretty rarely used API in general if one was recording usage stats — which also implies that, although it is a standardized DOM API, you are not likely to find much familiarity among developers, so I wouldn't bank on that as your reason for choosing to use a TreeWalker. It has also gotten some flack from prominent JS ninja John Resig, creator of jQuery, on both its API design (well, its cousin NodeIterator's API design, technically speaking) and its performance/speed (for specific scenarios, anyway).

However, where I think a TreeWalker really shines is when the traversal is more "fuzzy", e.g. "get all text nodes between these two elements". The TreeWalker's logical filtering feature also makes it brilliant at ignoring DOM hierarchy when desired (as in the previous example, assuming that the end element might not be at the same and/or deeper depth in the DOM hierarchy).

JamesMGreene commented 11 years ago

Note: All traversal method signatures are in place and working, except that they do not currently handle attribute node traversal. Filed separate Issue #3 to address that.