3 ms·

Obviously you don't need jQuery, and twiddling in the DOM for an Angular app means you are doing something wrong. However, jQuery is still quite useful and I i

Obviously you don't need jQuery, and twiddling in the DOM for an Angular app means you are doing something wrong. However, jQuery is still quite useful and I include it in most projects. It makes various tasks, like event handling, AJAX requests and minor DOM tweaks, quite a bit nicer. Zepto is a good alternative with an almost-compatible API (http://zeptojs.com http://zeptojs.com). I would rather generally that developers used these off-the-shelf tools instead of implementing possibly buggy versions of functions like `height()`!

masklinn 10y ago
Though I've been using it less and less with the rise and convenience of vdoms, I always found that the most useful and delightful bit of jQuery is its treatment of nodesets as proper ordered sets, and that many of its manipulatory methods properly work on sets.
- throwanem 10y ago
  [].slice.call on the result of querySelectorAll turns that NodeMap (NodeList? I forget) into a proper array, on which all of the language's sequence manipulatory methods work as they should. I don't know why that method doesn't just return an array to begin with, but this is how you get one from it.
  - BinaryIdiot 10y ago
    > [].slice.call on the result of querySelectorAll turns that NodeMap (NodeList? I forget) into a proper array, on which all of the language's sequence manipulatory methods work as they should. While true it's important to remember this creates a new, shallow array copy. It's not something you'd want to call often. Also it may be better to use Array.prototype.slice.call instead to avoid the extra, empty array instance your shortcut creates. How much better is likely insignificant, however; it's mostly a personal preference of mine :) > I don't know why that method doesn't just return an array to begin with, but this is how you get one from it. I believe this answers that pretty well (I've had the same, frustrating question in the past): http://stackoverflow.com/a/2601582/242023 http://stackoverflow.com/a/2601582/242023
    - throwanem 10y ago
      That's a fair point about garbage creation; I wouldn't do that in a tight inner loop, either. And now I know why that method doesn't just return an array to begin with. Thanks!
  - masklinn 10y ago
    > on which all of the language's sequence manipulatory methods work as they should. Which is significantly less convenient and readable than using set-operatic traversal and manipulation functions: $('div').prev() will give me the preceding sibling of every div in the page, in native, best case scenario using ES2015 arrow functions and Array.from it's something like this: Array.from(document.querySelectorAll('div')) .map(e => e.previousElementSibling) .filter(e => e) and if you need pre-2015 compat you get this ball of itchy yarn: Array.prototype.slice.call(document.querySelectorAll('div')) .map(function (e) { return e.previousElementSibling; }) .filter(Boolean) jQuery works on and manipulates node sets, and I find that to be a beautiful and convenient abstraction. I expect that is not unlike the satisfaction users of APL or its descendants feel (although I can't for the life of me get beyond their sigil soup).
    - throwanem 10y ago
      I don't really have a positive counter-argument for this claim. The closest I can come is that, while the latter two examples are indeed more verbose, they're not really unattractive in their own right, and they do have the virtue of explicitude which jQuery's set operations, while conceptually clean and syntactically concise, lack. If you're not closely familiar with jQuery - which I no longer am, having touched it barely at all for better than half a decade now - what comes back from $('div').prev() isn't obvious. It probably requires experimentation in the console or a documentation review to be clear on the return value - and jQuery's documentation is, to be charitable, not of the most lucid. Meanwhile, in either of the native ES examples, it is immediately clear what's going on, albeit at the cost of additional verbosity: you're getting a set of elements, mapping each to its prior sibling, and filtering out those whose lack of a prior sibling resulted in a meaningless value in the map. (To this point, in ES5, I would instead write .filter(function(e) { return e !== null; }); the Boolean constructor is a useful shorthand, but shares the jQuery property of lacking lucidity.) In a team with deep enough experience of jQuery that the meaning of your first example would be clear to anyone working on the code, I wouldn't object to writing it that way. In any other context, and especially on a team with widely varying levels of skill and experience not just with jQuery but with relevant concepts in general, I would strongly favor the more verbose examples, both because they're easier to follow from scratch in their own right, and because they serve as complete examples of a pattern with applications far beyond the realm of DOM manipulation and thus have value beyond there mere convenience to type. Horses for courses, I suppose.
throwanem 10y ago
> twiddling in the DOM for an Angular app means you are doing something wrong ...except in defining a directive.

masklinn 10y ago

Though I've been using it less and less with the rise and convenience of vdoms, I always found that the most useful and delightful bit of jQuery is its treatment of nodesets as proper ordered sets, and that many of its manipulatory methods properly work on sets.

throwanem 10y ago
[].slice.call on the result of querySelectorAll turns that NodeMap (NodeList? I forget) into a proper array, on which all of the language's sequence manipulatory methods work as they should. I don't know why that method doesn't just return an array to begin with, but this is how you get one from it.
- BinaryIdiot 10y ago
  > [].slice.call on the result of querySelectorAll turns that NodeMap (NodeList? I forget) into a proper array, on which all of the language's sequence manipulatory methods work as they should. While true it's important to remember this creates a new, shallow array copy. It's not something you'd want to call often. Also it may be better to use Array.prototype.slice.call instead to avoid the extra, empty array instance your shortcut creates. How much better is likely insignificant, however; it's mostly a personal preference of mine :) > I don't know why that method doesn't just return an array to begin with, but this is how you get one from it. I believe this answers that pretty well (I've had the same, frustrating question in the past): http://stackoverflow.com/a/2601582/242023 http://stackoverflow.com/a/2601582/242023
  - throwanem 10y ago
    That's a fair point about garbage creation; I wouldn't do that in a tight inner loop, either. And now I know why that method doesn't just return an array to begin with. Thanks!
- masklinn 10y ago
  > on which all of the language's sequence manipulatory methods work as they should. Which is significantly less convenient and readable than using set-operatic traversal and manipulation functions: $('div').prev() will give me the preceding sibling of every div in the page, in native, best case scenario using ES2015 arrow functions and Array.from it's something like this: Array.from(document.querySelectorAll('div')) .map(e => e.previousElementSibling) .filter(e => e) and if you need pre-2015 compat you get this ball of itchy yarn: Array.prototype.slice.call(document.querySelectorAll('div')) .map(function (e) { return e.previousElementSibling; }) .filter(Boolean) jQuery works on and manipulates node sets, and I find that to be a beautiful and convenient abstraction. I expect that is not unlike the satisfaction users of APL or its descendants feel (although I can't for the life of me get beyond their sigil soup).
  - throwanem 10y ago
    I don't really have a positive counter-argument for this claim. The closest I can come is that, while the latter two examples are indeed more verbose, they're not really unattractive in their own right, and they do have the virtue of explicitude which jQuery's set operations, while conceptually clean and syntactically concise, lack. If you're not closely familiar with jQuery - which I no longer am, having touched it barely at all for better than half a decade now - what comes back from $('div').prev() isn't obvious. It probably requires experimentation in the console or a documentation review to be clear on the return value - and jQuery's documentation is, to be charitable, not of the most lucid. Meanwhile, in either of the native ES examples, it is immediately clear what's going on, albeit at the cost of additional verbosity: you're getting a set of elements, mapping each to its prior sibling, and filtering out those whose lack of a prior sibling resulted in a meaningless value in the map. (To this point, in ES5, I would instead write .filter(function(e) { return e !== null; }); the Boolean constructor is a useful shorthand, but shares the jQuery property of lacking lucidity.) In a team with deep enough experience of jQuery that the meaning of your first example would be clear to anyone working on the code, I wouldn't object to writing it that way. In any other context, and especially on a team with widely varying levels of skill and experience not just with jQuery but with relevant concepts in general, I would strongly favor the more verbose examples, both because they're easier to follow from scratch in their own right, and because they serve as complete examples of a pattern with applications far beyond the realm of DOM manipulation and thus have value beyond there mere convenience to type. Horses for courses, I suppose.

throwanem 10y ago

> twiddling in the DOM for an Angular app means you are doing something wrong ...except in defining a directive.