4 ms·

I still use jQuery even for new projects. Yes, these days it's possible to do everything jQuery does using native JS, but I find the native version to be much m

by acabal 5y ago

I still use jQuery even for new projects. Yes, these days it's possible to do everything jQuery does using native JS, but I find the native version to be much more verbose and its naming conventions to be far less clear. For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Meanwhile, natively getting a list of classes is `el.classList`, but when I'm getting children I also get a list, so why not `el.childList` instead of `el.children`? Natively cloning a node is `el.cloneNode(true)`, so now I have to remember what `true` is for and whether I want it or not (surprise: the default changed between JS versions, so the "optional" argument must always be included for compatibility!). Probably the most commonly used line in web JS in jQuery is the terse `$('selector')` but natively is the mouthful of `document.querySelectorAll('selector')`. So while jQuery isn't strictly necessary, it's certainly a nice syntactic sugar, and IMHO a more sane and consistently-designed API than native. It's a great choice for developers who want avoid big frameworks like Vue and get as close to plain HTML/JS as possible, but still want a pleasant JS development experience.

Aperocky 5y ago
I've used jQuery in the past, but switched to native js/ts. I found that while jQuery offers some nice synthetic sugar, it's mostly geared towards web frontend and actual logic continue to have to reside in native. I'd rather just know one thing (but I'm a backend programmer that only does js/ts for fun, so there's that).
- wil421 5y ago
  Mostly geared toward frontend? It’s been a while since I used JQuery but I thought it is specifically a frontend library.
  - PhillyG 5y ago
    Maybe they mean UI?
chrismorgan 5y ago
> For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Actually, .children is the child elements; .childNodes is all the children (including comments and text as well as elements). > Meanwhile, natively getting a list of classes is `el.classList`, but when I'm getting children I also get a list, so why not `el.childList` instead of `el.children`? I’m not sure why they want with .classList instead of .classes, but I expect .className is a part of the history. If redesigning it from scratch and still retaining the functionality of .children, I’d rename it .childElements. Certainly not .childList. And of course, the reasons for most of this stuff is the history. Some of the web’s APIs have aged well; others haven’t.
gmiller123456 5y ago
> but natively is the mouthful of `document.querySelectorAll('selector')` I'm curious as to whether there's a proper use case for querySelectorAll. I always use the getElementsByClassName, getElementById, and getElementsByTagName based on what I want. I find the more general querySelectorAll to be too likely to produce a bug when someone uses a CSS class name that equals a tag or ID. You can make it work, but I find it's too easy to re-use a word in different context, especially if it's different people doing the coding vs CSS.
- acabal 5y ago
  The question should be the other way around: Why is there `getElementsByClassName` when you can do `querySelectorAll('.myClass')`? Why have `getElementById` when we have `querySelectorAll('#myId')`? Why have `getElementsByTagName` when we have `querySelectorAll('tagName')`?
  - spiralx 5y ago
    Apart from the historical reasons both `getElementsByClassName` and especially `getElementById` are optimised - the latter being a simple lookup - which I'm not sure `querySelectorAll` is able to take advantage of.
    - setr 5y ago
      You’d pay the cost of parsing every time, but otherwise I’d expect SelectorAll to directly depend on getElementBy.. as relevant
- spiralx 5y ago
  Selecting descendants or sibling elements? Selecting based on tag and class? Selecting elements with a given attribute present or matching a particular value? Selecting elements with classes starting or ending with a given string? Selecting elements without children? Selecting elements that aren't any of the above.
- faitswulff 5y ago
  I use it all the time for bookmarklets and userscripts when I want to customize a page that I can't modify directly. Vendor site showing too many out of stock items? querySelectorAll('div.out-of-stock') and wipe them all out. Filter options not good enough? querySelectorAll('div.price').forEach( /* delete products between x and y prices */ ).
SavantIdiot 5y ago
jQuery is nice for small widgets (if you don't mind loading another library), but as soon as you start to make truly reactive content, it falls on its face. A reactive framework like Vue essentially makes your javascript variables control what is rendered implicitly based on their value, instead of explicitly calling a function. Since the ViewModel binds the variables to the controls, hundreds of lines of jQuery required to update controls literally vanishes. It blew my mind once I understood what reactivity meant in real life. I rewrote a fairly large site in Vue and the JS LOC shrank by nearly two orders of magnitude (of course, a lot of that was due to the previous webdevs problems). Now that I'm used to Vue, I view jQuery more like a skin disease, some kind of rash that makes everything ugly and swollen.
emodendroket 5y ago
You can just assign document.QuerySelector and document.QuerySelectorAll to $ and $$ yourself.
- claviska 5y ago
  You can, and some JS consoles provide this for convenience if those vars are unused, but jQuery really shines with method chaining. That’s what I miss the most from it. You could manipulate the DOM in incredible ways in “one line” of code.
  - emodendroket 5y ago
    Depends what you want to do, but I've kind of come around because I feel like if what I want to do is so complicated that I can't easily do it in vanilla JS, it's also complicated enough that I don't necessarily want to do it by manual DOM manipulation. Changes the calculation if you have to support older browsers and such though.
  - hoten 5y ago
    FYI chaining and a handful of the most common operations can be implemented in just a few lines of code: https://gist.github.com/paulirish/12fb951a8b893a454b32 https://gist.github.com/paulirish/12fb951a8b893a454b32 (Although I reach for the "cash" library instead of this or jQuery when I need something jQuery like)

by acabal 5y ago

Aperocky 5y ago

I've used jQuery in the past, but switched to native js/ts. I found that while jQuery offers some nice synthetic sugar, it's mostly geared towards web frontend and actual logic continue to have to reside in native. I'd rather just know one thing (but I'm a backend programmer that only does js/ts for fun, so there's that).

wil421 5y ago
Mostly geared toward frontend? It’s been a while since I used JQuery but I thought it is specifically a frontend library.
- PhillyG 5y ago
  Maybe they mean UI?

chrismorgan 5y ago

> For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Actually, .children is the child elements; .childNodes is all the children (including comments and text as well as elements). > Meanwhile, natively getting a list of classes is `el.classList`, but when I'm getting children I also get a list, so why not `el.childList` instead of `el.children`? I’m not sure why they want with .classList instead of .classes, but I expect .className is a part of the history. If redesigning it from scratch and still retaining the functionality of .children, I’d rename it .childElements. Certainly not .childList. And of course, the reasons for most of this stuff is the history. Some of the web’s APIs have aged well; others haven’t.

gmiller123456 5y ago

> but natively is the mouthful of `document.querySelectorAll('selector')` I'm curious as to whether there's a proper use case for querySelectorAll. I always use the getElementsByClassName, getElementById, and getElementsByTagName based on what I want. I find the more general querySelectorAll to be too likely to produce a bug when someone uses a CSS class name that equals a tag or ID. You can make it work, but I find it's too easy to re-use a word in different context, especially if it's different people doing the coding vs CSS.

acabal 5y ago
The question should be the other way around: Why is there `getElementsByClassName` when you can do `querySelectorAll('.myClass')`? Why have `getElementById` when we have `querySelectorAll('#myId')`? Why have `getElementsByTagName` when we have `querySelectorAll('tagName')`?
- spiralx 5y ago
  Apart from the historical reasons both `getElementsByClassName` and especially `getElementById` are optimised - the latter being a simple lookup - which I'm not sure `querySelectorAll` is able to take advantage of.
  - setr 5y ago
    You’d pay the cost of parsing every time, but otherwise I’d expect SelectorAll to directly depend on getElementBy.. as relevant
spiralx 5y ago
Selecting descendants or sibling elements? Selecting based on tag and class? Selecting elements with a given attribute present or matching a particular value? Selecting elements with classes starting or ending with a given string? Selecting elements without children? Selecting elements that aren't any of the above.
faitswulff 5y ago
I use it all the time for bookmarklets and userscripts when I want to customize a page that I can't modify directly. Vendor site showing too many out of stock items? querySelectorAll('div.out-of-stock') and wipe them all out. Filter options not good enough? querySelectorAll('div.price').forEach( /* delete products between x and y prices */ ).

SavantIdiot 5y ago

jQuery is nice for small widgets (if you don't mind loading another library), but as soon as you start to make truly reactive content, it falls on its face. A reactive framework like Vue essentially makes your javascript variables control what is rendered implicitly based on their value, instead of explicitly calling a function. Since the ViewModel binds the variables to the controls, hundreds of lines of jQuery required to update controls literally vanishes. It blew my mind once I understood what reactivity meant in real life. I rewrote a fairly large site in Vue and the JS LOC shrank by nearly two orders of magnitude (of course, a lot of that was due to the previous webdevs problems). Now that I'm used to Vue, I view jQuery more like a skin disease, some kind of rash that makes everything ugly and swollen.

emodendroket 5y ago

You can just assign document.QuerySelector and document.QuerySelectorAll to $ and $$ yourself.

claviska 5y ago
You can, and some JS consoles provide this for convenience if those vars are unused, but jQuery really shines with method chaining. That’s what I miss the most from it. You could manipulate the DOM in incredible ways in “one line” of code.
- emodendroket 5y ago
  Depends what you want to do, but I've kind of come around because I feel like if what I want to do is so complicated that I can't easily do it in vanilla JS, it's also complicated enough that I don't necessarily want to do it by manual DOM manipulation. Changes the calculation if you have to support older browsers and such though.
- hoten 5y ago
  FYI chaining and a handful of the most common operations can be implemented in just a few lines of code: https://gist.github.com/paulirish/12fb951a8b893a454b32 https://gist.github.com/paulirish/12fb951a8b893a454b32 (Although I reach for the "cash" library instead of this or jQuery when I need something jQuery like)