6 ms·

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.

by nadabu 13y ago

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.

SimHacker 13y ago
You're trying to oversimplify something that's just not that simple. When you project something down to a lower number of dimensions, you lose something. In this case, you lose determinism. Your code can break depending on the input. E4X tried to do that (blurring the distinction between XML and XMLNode), and failed. It might look good in oversimplified examples on blog posting, but it's a trap waiting to be sprung when used with real world data.
- nadabu 13y ago
  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. Thank you and good night.
jacobolus 13y ago
You’re completely missing/ignoring his point, and arguing about topics that are entirely unrelated/orthogonal. You shouldn’t return separate types of objects from a function based on the current state of the DOM, because the resulting code will be confusing, fragile, and hell to debug. To take the Clojure guys’ language, such code is “complex”. Don’t make APIs like that: it’s an anti-pattern. Either always return an array, or always return some kind of wrapper, or use separate methods for different return types, or use exceptions, or whatever mechanism you want, but pay close attention to cases where the typical API usage will lead to fragile code, and try to prioritize avoiding those.
- nadabu 13y ago
  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 13y ago
    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?
joesb 13y ago
> The DOM gives you NodeList for querySelectorAll and an Element for querySelector. Because querySelector and querySelectorAll is not the same function, it can return different things. I don't know how this apply to your case where same dot traversal return different things.
- nadabu 13y ago
  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.

by nadabu 13y ago

SimHacker 13y ago

You're trying to oversimplify something that's just not that simple. When you project something down to a lower number of dimensions, you lose something. In this case, you lose determinism. Your code can break depending on the input. E4X tried to do that (blurring the distinction between XML and XMLNode), and failed. It might look good in oversimplified examples on blog posting, but it's a trap waiting to be sprung when used with real world data.

nadabu 13y ago
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. Thank you and good night.

jacobolus 13y ago

You’re completely missing/ignoring his point, and arguing about topics that are entirely unrelated/orthogonal. You shouldn’t return separate types of objects from a function based on the current state of the DOM, because the resulting code will be confusing, fragile, and hell to debug. To take the Clojure guys’ language, such code is “complex”. Don’t make APIs like that: it’s an anti-pattern. Either always return an array, or always return some kind of wrapper, or use separate methods for different return types, or use exceptions, or whatever mechanism you want, but pay close attention to cases where the typical API usage will lead to fragile code, and try to prioritize avoiding those.

nadabu 13y ago
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 13y ago
  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?

joesb 13y ago

> The DOM gives you NodeList for querySelectorAll and an Element for querySelector. Because querySelector and querySelectorAll is not the same function, it can return different things. I don't know how this apply to your case where same dot traversal return different things.

nadabu 13y ago
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.