Exactly this. It's extremely useful to be able to say "with all document elements that matches this selector (whether there are any or not), do this."

It's possible it's also situationally useful to say "if there aren't any document elements that match this selector, error out, if so do this with all of them." I'm struggling to imagine a specific situation in which that has compelling advantages (and would be interested in elaboration), but let's say it exists. Then something like this:

    $.fn.mustMatch = function(onNoMatch) {
        if (!this.length) {
            if(typeof onNoMatch == 'function') onNoMatch(this);
            else throw "mustMatch failed on selector " + this.selector;
        }
        return this;
    }

would make it easy to explicitly add the guard condition with an invocation like `$("#selector .nonextant").mustMatch().each(function (emt) { /*do this*/ })`, rather than having it invisibly ride along with every comprehension and making the "whether there are any or not" case harder.

And if for some reason one were possessed of the conviction that implicit enforcement of this universally within their project outweighed the advantages of explicit options for both ways, it'd probably be better to patch the jQuery lib for that specific project than enforce it as a standard for everyone worldwide.

Just had a script today that fires in 2 contexts and ran into an error where the element I attach a handler to doesn't exist in one of the contexts which breaks JS on the page. Since I already had jQuery as a dependency in the project, in the moment it felt easier to replace the querySelector call with jQuery, which I did, instead of checking the querySelect result so I second this, the 'fire and forget' part still holds up very well even though the tree traversal pain points have mostly been solved by browsers.

Optional chaining is widely supported and solves this problem for single-element queries. qsA returns an empty NodeList when the selector matches no elements, as long as the string is a valid selector. Then forEach doesn't require it anyway.

For every one of these we had ten where a button press definitely needed to definitely update a DOM element.

As I said above, you’d want a way to override the behavior in the few cases where it’s inappropriate

true it is tedious but I have a vs code shortcut for doing the following (and same goes for queryselectorall) let foo = document.queryselector(‘.foo’);

if (!!foo) { //do thing }