Wait if querySelectorAll exists why does jQuery waste time with its dollar sign method?
I know normally you'd expect a big long rant about how stupid jQuery is, but in this case it's not -- well, not entirely -- their fault. Simple fact is that querySelectorAll didn't exist in JavaScript when jQuery was originally created. In terms of browser support it does not exist in IE 7 or earlier, and when jQ was new, support back to at least IE6 was still considered "essential".
Sadly their use of it for EVERYTHING is part of what makes jQ such an inefficient and outdated mess. Even when new it was pretty pointless, but like a lot of things it has aged like milk. See all the things that 15 years ago REQUIRED JavaScript to be done that as of about ten years ago we could use CSS for.
Also can you explain this:
do/while is a less used but important construct to know. Well, it's less used in C syntax languages because C programmers think about almost every problem backwards.
In many languages starting the loop and then testing the condition is the norm. This is even true in assembler where it's more natural to put the test at the end of the loop, instead of pointlessly looping back to the test at the start that then on failure has to jump-out. In Wirth family languages -- Pascal, Modula, Ada -- they have the "repeat until" construct which is identical in functionality to do/while. In point of fact in older versions of said languages they had no equivalent of while {}.
Hence something like:
program testInput;
uses
crt;
var
ch : char;
begin
writeln('Press <ESC> to Exit');
repeat
ch := readkey();
until ch = #27;
end.
Being the norm for loop logic in such languages.
It can be extremely useful in cases like this where our operation to get the first element -- parent.firstElementChild -- does not match our loop to get the next element. You could write the same section as:
while (li) {
li.firstElementChild.addEventListener('click', lightBoxClickEvent, false);
li = li.nextElementSibling;
}
But it's not necessarily clearer and it can execute slower since it forces an extra return to the start of the while at the end. Whether or not it's actually slower would hinge more on how the JavaScript engine is implemented. I know some people prefer this approach, more power to them. Both are valid ways of coding it, use whichever you're more comfortable with.
Why do I see so much code where people do all of them off document and then loop through them looking for classes, data or checking the parent?
Ignorance.
As I often say, I don't meant that as an insult. Ignorant just means you don't know any better. You can fix ignorance.
In this case as JavaScript just has a LOT of functions, objects, and methods and it's hard to be sure you've learned all of them, or that you've learned to use any of them to their full potential. I still go to MDN regularly to look something up that I've forgotten the nitty gritty details of, and ended up going "huh, how about that!". This is more the case now that the ECMA is adding new stuff with such frequency, and browser makers -- or at least Quantum and Blink -- are keeping up with implementation.
This is often worse in languages that have truly massive function/object libraries like PHP. So often you'll see people brute force code things that PHP already has functions/methods to handle. It's not because these programmers are stupid, it's because they don't know everything PHP basically hands you on a silver plate.
A situation only exacerbated by the fact that so many developers learn by blind copypasta
without comprehension. This is because so many people will hand you a snippet, then NOT explain it.
Part of why I put so much effort into my code breakdowns and explanations. Might make a few half-tweet TLDR mouth-breathers scream "AAAH WALL OF TEXT", but in my view you get no points for half-answers.