It makes sense to throw a syntax error but I wasn't sure what the actual behavior would be. Made me wonder if jquery did some magic to understand what is being queried.
That's precisely my point. To put it another way, jQuery converts what would be a javascript error into a technically "valid" empty array. Sometimes this is useful, but it can also help mask poor logic.
> The only thing that's been annoying is that jQuery ignores the difference between querySelector and querySelectorAll, and just treats any operation done on a jQuery selection as if it were mapping a function to each item in a list. Which makes it super easy to write, but makes it much more difficult to know what's actually happening
Does it though? Even years after moving on from jQuery it’s always very clear when reading old code that all selectors will be matched. There’s less cognitive load knowing you’re querying all matching items by default than mentally parsing the difference between querySelector and querySelectorAll, and also having to spread the result because NodeList doesn’t support array functions.
> The only thing I don’t like about jQuery is that commands fail silently when a selector finds zero results.
The set-operatic approach of jquery is one I absolutely love about it, though it does lead to unforeseen behaviours in edge cases (sometimes performance concerns running code on nothing or on way more than expected) it's leads to extremely convenient and fluent code, much more so than the explicit iterations of the normal DOM.
> More often we expect something to happen, and the cases where the results might be empty are obvious enough that adding a “fail silently” flag in those cases wouldn’t be a hardship.
Extending jquery to assert a lower bound (and even an upper bound as well) wouldn't be a hardship either.
jQuery is designed not to fail. So if there's no `.box` on the page, jQuery will not do anything.
`querySelector` may return null, so `$('.box').hidden` will hard break your page if you're not careful enough
2. `$('.box').hide()` is just one such example.
The hilarious https://youmightnotneedjquery.com/ shows that jQuery remains more consistent, concise, and composable than most things in modern browser APIs
> The issue was using innerHTML (or rather $.html()) with strings concatenated together from user input.
> The Signal devs thought $.html() does some kind of escaping
I mean, it does do a kind of escaping. If you assign javascript to innerHTML directly, it won't execute. jQuery specifically checks whether you're adding a script tag, and if so, it takes the extra step to execute it for you.
On the other hand, `$('#'+id)` fails when the ID contains dot or other characters that have special meaning in a CSS selector, and `$(selector)` is overloaded with `$(html)` causing common XSS injection issues in apps misusing it. jQuery's “Do What I Mean” philosophy jas introduced as many of its own bugs as it ever fixed in browsers; I wish there were a happy medium.
So does querySelectorAll, that's not the issue with jQuery API.
The problem is that "jQuery" function, aliased as "$" has 9 signatures (doing 9 different things, depending on which arguments you send to it), while querySelectorAll does only one thing
I'm not sure your jQuery question is quite of the same nature as the nano-questions mentioned in the article. Your example is actually fairly conceptual. Yes, it requires them to know the syntax, but asking them to explain the difference ends up being fairly high level.
The examples in the article have no high-level component at all. I don't know what package File is in off the top of my head. I've never needed to commit it to memory, since the IDE will look it up, and if that doesn't work I can look it up myself. It's not useful information. Your question, on the other hand, is useful information.
We can safely use the word syntax in this context without offending programming languages. You seem overly concerned with latching "syntax" to a tightly controlled definition. Perhaps you should google "jquery syntax" then contact each website informing them of your objections.
>The Signal devs thought $.html() does some kind of escaping:
Uhm... that's a really rookie mistake to make. Like, one of the very basics of jQuery usage. I'm not exactly sure what to think about it after seeing this commit you linked...
But without jquery, everything defined in html attributes, and hence the server responses can further define behaviour in their html attributes. Declarative, not procedural, if you want.
reply