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.
If you want to use those, use them, then HTML.ify() the results or not. Either way, the point here is to encourage DOM use and eschew wrapper APIs.
If you want to use HTML.js's find() or dot-traversal, you must accept that your decision point was moved to how you handle the return value. And that you can use each() and only() to write code that safely abstracts the difference in results. Not an increase in complexity, just a shifting of it to somewhere i currently prefer.
I'm hoping it returns undefined. Dot-traversal on a list goes into the first item, the first item should be empty. I have had some issues with the demo, since it hacks some things for presentation's sake. What did you expect?
Why would you have no idea? If you're querying by id, you have one, if you're querying by anything else, assume you have more. Once you assume you have more, you use each() to operate on all or only() to narrow the list. Those functions handle the abstraction for you, just like a jQuery wrapper does.
Yes, code that's unprepared for variable input can break when input varies. So use code that is prepared for it, like each().
And thank you for your anecdote, but i have never and will never stop doing something merely because some guy on the internet points out that some completely other person in a different context failed to pull it off.
How else can i spell this out... you do not need to worry about the distinction between nodes and node lists, if you just use each(). It's a proxy function that deals with the abstraction for you, just like jQuery's wrapper object does.
YOU. DO. NOT. NEED. AN. OBJECT. TO. HAVE. AN. ABSTRACTION.
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?
I gave a solution (each()). You say it adds complexity. But adding it to what? The DOM gives you NodeList for querySelectorAll and an Element for querySelector. Is choosing between those at runtime and working with the results simpler than each()? No. Is one of those enforced? No. Fewer mistakes will be made with HTML.js than the straight-up DOM. I've reduced (and somewhat shifted) the complexity, not added it.
You say my dismissal of wrappers is entirely orthogonal because you are only comparing HTML.js to jQuery on jQuery's terms. jQuery made the choice to have syntax independent of the runtime state of the DOM. That's great, very useful!! I use jQuery all the time, it's not going away anytime soon. But with that benefit comes the cost of having to maintain a wrapper API, to learn a separate API with its own orthogonal set of drawbacks to using the DOM directly.
Web dev is changing. Single-focus libraries, web components, shadow DOM, all of these do not look fondly on wrapper APIs. Wrappers are essentially foreign tongues, not the native DOM they are designed to consume. HTML.js is designed for that world, where you are working with small, tightly controlled sections of native DOM.
If your page is the wild west with complex selectors and lots of interacting runtime changes, by all means, use a wrapper API like jQuery. But stop measuring every DOM helper with that stick. Sheesh.
By all means, use the plain old DOM interface! That's kinda the point i'm driving at with this library. We don't really need jQuery anymore (at least not all of it). Small components like HTML.js can still be handy when you want a little sugar to save some typing though. :)
Wrappers actually have their share of subtle problems, we've just gotten used to the jQuery way of coping. Hmm, i sense another blog post coming... :)
At root, the issue is that without widely available Proxy implementations (wildcard property intercept), wrappers must duplicate the entire underlying (and widely varying) API of the wrapped elements. You could do this by slavishly copying the DOM or by creating an entirely separate API (like jQuery).
Returning a list for all operations is returning a wrapper, not the path i'm on. I would never argue that variable return types is ideal, but i currently prefer its problems to the problem introduced by using a wrapper API. :)
HTML is the root element (<html>), so it cannot be a function. HTML.ify() is only needed if you have a different library/interface that hands you an element, not retrieved via find() or dot-traversal.
Yeah, i agree, which is one reason heavy-weight DOM manipulators are losing ground to small components. There will always be some need for working with the DOM though.
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.
In cases where the return value type is actually unknowable, you can reliably use each() on the results. The whole point here is to use the DOM, not a wrapper. I'm open to pull requests if you have a way to have consistent interface and return types without a wrapper.
Yes, the performance has been fixed. Further improvements are possible (prototype extension), but come with tradeoffs so i'm hesitant.
Apart from the dot-traversal technique (both fixed and enhanced), everything is different in HTML (see the FAQ): each(), only(), extensibility, emmet abbreviations, and the upcoming event support.
Yeah, i'm still hacking on this a lot. It's not v1.0 ready. The Chrome tests pass again, but the alter module still needs some work. And the new event module needs docs, and so on and so on... :)
Eh, not a wrapper, sorry. It's a helper that directly extends the DOM to provide syntax sugar. Yes, it is not pure DOM interface, but if it were, then the library would be a whopping 0KB. :)
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.