Hacker News new | past | comments | ask | show | jobs | submit login

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".




> 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.


It's the main reason I dislike jQuery. It's hard to debug.

    document.getElementById('non-existent').classList; // error

    $('#non-existent').addClass('yay'); // hidden bug
I prefer the explicit solution.


I don't think Array.prototype.forEach.call(el.querySelectorAll(selector)) is complex enough to pull in a new library.


It's not, but then you fall on IE9+ land, and you'll have to check if querySelectorAll returns anything first.

The sibling comment points out how a function silently failing when given empty value can be deceiptive. I guess your way of seeing it would be also in line with checking valid values before using them.

It's a very sane approach, and it requires more care and attention for each step. I'm not against it, but usually I'm not sure to see a real payoff for very conservative programming in front end DOM manipulation, I tend to prefer taking some performance hit and ignore the nitty gritty details as well as the small errors, as long as it can be recovered at a higher level.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: