[nadabu]

And you missed mine. I made a willful-and-fully-knowledgable choice to conflate nodes and lists. I understood then and still understand that it shifts complexity from the call to the return value. How is explaining motives for that decision "entirely unrelated"?

I also, knowing that complexity was shifted to the return value, created an each() function that solves that problem entirely. It allows (even encourages) you to handle the result exactly like a proxy/wrapper. Again, how is that not related?

Yes, i am doing something unconventional, something that failed for others in the past. In fact, i'm doing several things like that. I'm also extending the DOM, not even using prototypes, but manually! Now, why don't ya'll explain to me all the conventional wisdom about those things too. I've gone against it, therefore i must be ignorant, right?

[emn13]

I don't mind going against conventional wisdom; and I think HTML.js's let's see what we can get away with is kind of neat - but conflating nodes and node-lists isn't avoiding a proxy, it's just making the api harder to use.

You mention .each, but the fact that you don't use it yourself in the primary HTML.js example should be telling you something: HTML.js does not encourage it's use. It's a cop-out; an escape valve that forces you into a less-than ideal syntax.

If you want to look at this through the lens of breaking with conventional wisdom you should be looking at why that convention arose in the first place.

Extending the DOM? You've got a good argument that the original reasoning no longer applies there! Conflating nodes and node-lists? What's different now that makes this a good idea?

Personally, if anything, I think the conflation is a worse idea now than it was a long time ago. Back when JS was "just" a small snippet in an otherwise static site making assumptions on the DOM of that site made some sense if it simplified your JS. Nowadays, the DOM is more and more an API for building an app, and less a static representation of a document. It's far from static, and depending unnecessarily on structural details of the DOM just means you need a more complicated (slower, more error-prone) mental model while programming.

It's not impossible - it's just making things hard for yourself. But what for? Where's the commensurate gain?

[nadabu]

You're wrong about each(). I do use it in the demo twice. Writing each() was the main challenge and goal in my development process; the most enjoyable part of it. Look at the code itself and how much of core.js is devoted to giving each() it's power and flexibility. each() also powers the alter.js (as it should all extensions). Calling it a cop out is flat out ignorant. What you also don't know is that i've writing javascript since it's beginning. I am no stranger to the DOM nor its history. I've been building apps with web technology full time for 12 years. Your "you don't know what your doing" posturing is again, founded in ignorance of me and my code. There is no choice in this library that i made in ignorance of the tradeoffs nor of the conventions i am challenging. Accept that, please.

And i am most certainly NOT making things hard on myself. I forked Voyeur and rewrote it because the concept was so close to what i needed to make things much easier for working with the DOM. I needed a tight library that let me avoid branching code (unwieldy if/else) into either querySelector (node returned) and querySelectorAll (list returned). I wanted something that made it easy to traverse the short and usually quite static structures of my shadow DOMs or web components. The gains are numerous for me (and many others). It baffles me that you think using HTML.js is harder than straight DOM.

Now my lecture... You need to stop seeing the DOM as a large, dynamic structure of myriad, loosely defined nodes. The future of the web (what i'm aiming for) is components: groups of encapsulated structures whose internal relationships are well-defined and whose external relationships are nearly irrelevant. You probably won't understand the value of working close to the DOM with tiny libraries that don't abstract everything away for you until you pull your head out of 2010 design patterns and into 2015 ones.