[nadabu]

If you don't know, use each() and only() to act on the results. They're always available and don't care if it is an element or array of elements.

[lhorie]

2 more thoughts :)

1 - you cannot be sure that return types will not change in the future (e.g. markup changes in maintenance phase), especially in large projects with lots of devs, hence my comment about brittleness.

2 - each() is verbose and encourages procedural style, which can cause redraw performance hits (i.e. someElements.readDOM().writeDOM() redraws much faster than someElements.each(function(el) {el.readDOM().writeDOM()}) since the browser's engine doesn't need to recalculate layout at every iteration

re: closest() - I've seen people do things like

  $("li ul").closest("li").addClass("has-children")

for things like dynamic expandable tree initialization. Granted, it's not a very common use case though.

[nadabu]

1) i can reliably assume HTML.find('#foo') is a node, and HTML.find('.foo') must use each(). These things get even easier as web components and shadow DOM become widely available. I'm aiming at the future here, not the past.

2) elements.each('readDom').each('writeDom', 'value')

3) HTML.find('li ul').each('parentNode.classList.add', 'has-children')