I agree with all the points here except for the part about bit flags. Bit flags are still arguably the best way to store "sets" of non-duplicate information. For example, if I wanted to aggregate the kinds of nodes I'd want with John's API, I'd have to accumulate them in an array, then use apply() because I can't pass that array in. Then there's the problem of duplicates, and also easily being able to check, add, and remove. All these operations are of course possible with an array (even if they contain duplicates), but it seems a bit much to go down a route where all these operations are inherently O(N) when there is an O(1) solution that isn't that hard to learn. Additionally you can easily construct shorthands for often used combinations: ElementsAndText = Element | Text. In the array world, you're going to be having to concat arrays to achieve a similar effect. It's also really nice that you can say "ALL" just with 0xF...FFFF (-1) and be assured that it is future proof, whereas in the array world if new nodes creep in in the future, you have to now go back to every instance where you called this and add a new parameter. I suppose the "easy" fix for this is to just say that if nothing is passed in it means "all", or alternatively have an ALL constant.
We recently tackled a similar issue in Cappuccino and our solution was to create two parallel ways of specifying this information that were transparently convertible: a pure bit flags version and a strings version, such that (Selected | Highlighted) is equivalent to "selected+highlighted". You can pass in either the string form or the bit form to the methods, and you can convert between them as well. All in all, none of the "JS people" using our framework seemed to mind the use of bit flags.
We're talking about JavaScript, so Scheme is a better example than C. At the level of abstraction Javascript deals in, bit twiddling like this should not be necessary. Even using all caps constants just feels dirty. And JavaScript isn't even any good at bit twiddling, as it doesn't use native machine integers.
Sure, but aren't you the guy whose claim to fame is taking DOM API's written by people who think in C++ and translating them into JavaScript? Get to work!
This is a nice example for the (not so) subtle brain damage that java has inflicted upon a whole generation of developers. John points out nicely how the insanity even creeps into other languages when nobody's looking...
He's right about this rightfully being a node method rather than a document method. But if the common developer can't understand bit flags, I don't think they are going to have a long career. And I can't think of a good reason to use entityReferenceExpansion=false unless you're going out of your way to handle entities yourself (which he's clearly not inclined to do).
The common developer or the common web developer? I think most web developers can go very far without ever using bit flags - especially considering that no common JavaScript or DOM APIs use them.
"And I can't think of a good reason to use entityReferenceExpansion=false..." It's all about the element of least surprise - are developers more likely to expect the syntax that they see on the page (e.g. &foo;) or something else in its place. Whatever the right answer is to that question should be made the default option and left as that.
I'm not a web developer, but I do like javascript quite a bit. The 'bit flags' are easily understandable, but they don't 'feel' like a Javascript API -> I think that was the point of the post. All things being equal, jresig's proposed API feels a lot more natural to a javascript developer. In another language, this API may fit right in.
We recently tackled a similar issue in Cappuccino and our solution was to create two parallel ways of specifying this information that were transparently convertible: a pure bit flags version and a strings version, such that (Selected | Highlighted) is equivalent to "selected+highlighted". You can pass in either the string form or the bit form to the methods, and you can convert between them as well. All in all, none of the "JS people" using our framework seemed to mind the use of bit flags.