33 ms·

You don't need an abstraction to do something that's natively implemented on your platform.

by sfeng 13y ago

jpatte 13y ago
Abstractions are meant to, well, abstract an implementation. You might very well want to abstract a native operation for a bunch of different reasons. You don't need to, but maybe you should. For example, $(el).hide() is quite more readable than el.style.display = 'none' . And I'm not even talking about the other advantages.
- daleharvey 13y ago
  Its el.hidden = true; in modern browsers
  - nostrademons 13y ago
    I'm curious - is this spec'd anywhere? I just tried it in Chrome and it works great, but I couldn't find it in any of the specs for Element or Node.
    - epmatsw 13y ago
      The best I found http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#the-hidden-attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/... https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes#hidden https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
  - rwaldron 13y ago
    The documented semantics of the hidden attribute say otherwise https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes#hidden https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... http://www.w3.org/html/wg/drafts/html/master/editing.html#the-hidden-attribute http://www.w3.org/html/wg/drafts/html/master/editing.html#th... " it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar"
  - talmand 13y ago
    According to specs mentioned elsewhere, it seems to have reasons to exist other than just display hide/show purposes. It's easily overridden by CSS. el.style.display = 'none' pretty much works everywhere. To me, it seems to depend upon what the purpose of hiding/showing the element is in specific cases.
- drdaeman 13y ago
  > $(el).hide() > el.style.display = 'none' You meant something more like document.querySelectorAll(el).forEach(function(e) { e.style.display = 'none'; } and a polyfill for IE8 due to lack of native Array#forEach, right?
  - kibibu 13y ago
    This equivalency only works when el is a DOMElement, not a selector string.
    - talmand 13y ago
      Which one is likely to be more common?
  - deleted 13y ago
    [deleted]
Me1000 13y ago
Right, because why have "var x = 2+2" when you have perfectly maintainable assembly!
- sinkasapa 13y ago
  I think the point is that "$.contains(el, child)" is not a useful abstraction of "el.contains(child)".
  - hrktb 13y ago
    You wont have $.contains, instead $(el).children(child) returns a chainable filtered list of the first level of child nodes, or $(el).find(child) will go down recursively. jQuery rarely dumbly duplicates some native functionnality, as for the example above, most of the time it will diverge in meaningful ways.
    - sinkasapa 13y ago
      These two new functions you mentioned are both in the article linked to above. 'el.children' and 'el.querySelectorAll(selector)' are given as alternates. It is true they aren't 100% the same but JQuery isn't different enough in my opinion for there to be any clear reason to use it instead of what is already available. As a side note, I know this is totally a matter of taste but "chainable" in the JQuery sense reads to me as "spaghetti generator".
      - hrktb 13y ago
        > As a side note, I know this is totally a matter of taste but "chainable" in the JQuery sense reads to me as "spaghetti generator". I think this is more important than a side note. The reason jQuery's 'children' or 'find' is way better in my eyes is because of the support for arrays as target and argument, and the possibility to pass the resulting collection to the next command as is. Going the native route, filtering the children will need an extra loop, doing so on an array of parent elements will also bring an other loop. And we'd have to deal with a Nodelist instead of an array. A 2 command jQuery line would be 5 to 10 lines in native code, every time there is some node tree to filter. Manipulating collections of DOM elements is such a common case that having to deal with loops every time is just tiring, less readable and more prone to basic errors. In a way I see it as an anti-spaghetti feature. Less boilerplate, shorter, more concise code with clearer intents. My side note would be that el.querySelectorAll(selector) is versatile, but not as much as the jQuery find. Telling which cases for which browsers would not work with the native function could be some interview question, but that's not the kind of thing I'd like to remember.
sergiotapia 13y ago
No thanks, I'll take something that I'm sure 99% of web developer know by heart and works cross browser. I don't want/need to spend hours upon hours writing "clean" code that doesn't use jQuery. I have business problems to solve.
- boie0025 13y ago
  That's what it all boils down to... "I have business problems to solve".

You don't need an abstraction to do something that's natively implemented on your platform.

by sfeng 13y ago

You don't need an abstraction to do something that's natively implemented on your platform.

Abstractions are meant to, well, abstract an implementation. You might very well want to abstract a native operation for a bunch of different reasons. You don't need to, but maybe you should. For example, $(el).hide() is quite more readable than el.style.display = 'none' . And I'm not even talking about the other advantages.

daleharvey 13y ago
Its el.hidden = true; in modern browsers
- nostrademons 13y ago
  I'm curious - is this spec'd anywhere? I just tried it in Chrome and it works great, but I couldn't find it in any of the specs for Element or Node.
  - epmatsw 13y ago
    The best I found http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#the-hidden-attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/... https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes#hidden https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
- rwaldron 13y ago
  The documented semantics of the hidden attribute say otherwise https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes#hidden https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... http://www.w3.org/html/wg/drafts/html/master/editing.html#the-hidden-attribute http://www.w3.org/html/wg/drafts/html/master/editing.html#th... " it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar"
- talmand 13y ago
  According to specs mentioned elsewhere, it seems to have reasons to exist other than just display hide/show purposes. It's easily overridden by CSS. el.style.display = 'none' pretty much works everywhere. To me, it seems to depend upon what the purpose of hiding/showing the element is in specific cases.
drdaeman 13y ago
> $(el).hide() > el.style.display = 'none' You meant something more like document.querySelectorAll(el).forEach(function(e) { e.style.display = 'none'; } and a polyfill for IE8 due to lack of native Array#forEach, right?
- kibibu 13y ago
  This equivalency only works when el is a DOMElement, not a selector string.
  - talmand 13y ago
    Which one is likely to be more common?
- deleted 13y ago
  [deleted]

Me1000 13y ago

Right, because why have "var x = 2+2" when you have perfectly maintainable assembly!

sinkasapa 13y ago
I think the point is that "$.contains(el, child)" is not a useful abstraction of "el.contains(child)".
- hrktb 13y ago
  You wont have $.contains, instead $(el).children(child) returns a chainable filtered list of the first level of child nodes, or $(el).find(child) will go down recursively. jQuery rarely dumbly duplicates some native functionnality, as for the example above, most of the time it will diverge in meaningful ways.
  - sinkasapa 13y ago
    These two new functions you mentioned are both in the article linked to above. 'el.children' and 'el.querySelectorAll(selector)' are given as alternates. It is true they aren't 100% the same but JQuery isn't different enough in my opinion for there to be any clear reason to use it instead of what is already available. As a side note, I know this is totally a matter of taste but "chainable" in the JQuery sense reads to me as "spaghetti generator".
    - hrktb 13y ago
      > As a side note, I know this is totally a matter of taste but "chainable" in the JQuery sense reads to me as "spaghetti generator". I think this is more important than a side note. The reason jQuery's 'children' or 'find' is way better in my eyes is because of the support for arrays as target and argument, and the possibility to pass the resulting collection to the next command as is. Going the native route, filtering the children will need an extra loop, doing so on an array of parent elements will also bring an other loop. And we'd have to deal with a Nodelist instead of an array. A 2 command jQuery line would be 5 to 10 lines in native code, every time there is some node tree to filter. Manipulating collections of DOM elements is such a common case that having to deal with loops every time is just tiring, less readable and more prone to basic errors. In a way I see it as an anti-spaghetti feature. Less boilerplate, shorter, more concise code with clearer intents. My side note would be that el.querySelectorAll(selector) is versatile, but not as much as the jQuery find. Telling which cases for which browsers would not work with the native function could be some interview question, but that's not the kind of thing I'd like to remember.

sergiotapia 13y ago

No thanks, I'll take something that I'm sure 99% of web developer know by heart and works cross browser. I don't want/need to spend hours upon hours writing "clean" code that doesn't use jQuery. I have business problems to solve.

boie0025 13y ago
That's what it all boils down to... "I have business problems to solve".