8 ms·

I'm not sure what you mean by "cases where the return value type is actually unknowable". Does that mean you only return an Element when it's something for whi

by jayferd 13y ago

I'm not sure what you mean by "cases where the return value type is actually unknowable". Does that mean you only return an Element when it's something for which there can be only one on the page (like document.body)? As far as APIs go, one way would just be to return a list always. The DOM, afaik, returns a special NodeList thing that isn't even an array. ( https://developer.mozilla.org/en-US/docs/Web/API/NodeList?redirectlocale=en-US&redirectslug=DOM%2FNodeList https://developer.mozilla.org/en-US/docs/Web/API/NodeList?re... ). What's the actual issue with using wrappers?

nadabu 13y ago
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). Back when the DOM was a mess (3-4 years ago), the wrapper was the only sane approach (witness jQuery crushing Prototype). I'd argue things have changed: https://github.com/nbubna/mind-hacking/blob/gh-pages/extending-the-dom.md https://github.com/nbubna/mind-hacking/blob/gh-pages/extendi... 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. :)
- emn13 13y ago
  What you say is entirely orthogonal to the issue at hand. The question isn't whether you want to proxy dom properties - the question is what you return from a search query that conceptually may return several results, one result, or no results. That state - that return value - does not behave like a DOM node. It doesn't quack like one. Sure, you can somehow create a mapping between the various scenarios - 0 results to null (or undefined?), 1 result to the result itself, and several to an array, but that just means that working with the result becomes harder. As an API consumer of HTML.js as-is, I've got a few choices - I can be hyperverbose and check all the time what the return value was (shudder) - I can use a special-purpose api that happens to work in all cases. This is ok, but adds complexity, and since it's not enforced, I'm going to makes mistakes that will bite me confusingly at inopportune moments. - I can make assumptions about the dom... this element must always be unique, right? and this selector always matches something, right? This coding style is hell to debug, especially without liberal asserts nor even the implicit asserts that a static type checker would make. This is the syntax the examples use, must be a great idea... Let me put it this way: you're basically writing a query DSL, but you've chosen to make the syntax depend on the runtime state of the DOM. e.g. finding a link inside a div inside a section is written differently depending on whether there are several divs, or just one.
  - 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.

by jayferd 13y ago

nadabu 13y ago

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). Back when the DOM was a mess (3-4 years ago), the wrapper was the only sane approach (witness jQuery crushing Prototype). I'd argue things have changed: https://github.com/nbubna/mind-hacking/blob/gh-pages/extending-the-dom.md https://github.com/nbubna/mind-hacking/blob/gh-pages/extendi... 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. :)

emn13 13y ago
What you say is entirely orthogonal to the issue at hand. The question isn't whether you want to proxy dom properties - the question is what you return from a search query that conceptually may return several results, one result, or no results. That state - that return value - does not behave like a DOM node. It doesn't quack like one. Sure, you can somehow create a mapping between the various scenarios - 0 results to null (or undefined?), 1 result to the result itself, and several to an array, but that just means that working with the result becomes harder. As an API consumer of HTML.js as-is, I've got a few choices - I can be hyperverbose and check all the time what the return value was (shudder) - I can use a special-purpose api that happens to work in all cases. This is ok, but adds complexity, and since it's not enforced, I'm going to makes mistakes that will bite me confusingly at inopportune moments. - I can make assumptions about the dom... this element must always be unique, right? and this selector always matches something, right? This coding style is hell to debug, especially without liberal asserts nor even the implicit asserts that a static type checker would make. This is the syntax the examples use, must be a great idea... Let me put it this way: you're basically writing a query DSL, but you've chosen to make the syntax depend on the runtime state of the DOM. e.g. finding a link inside a div inside a section is written differently depending on whether there are several divs, or just one.
- 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.