This supports a idea I've had for some time, particularly as I've had one of my common libraries take a performance dip when I added "use strict".

I'm usually the one railing against industry "advice" that seems unfounded. In Strict's case there is no reason to think it would be faster, because it just adds more checks to throw errors over. Those checks introduce overhead. Much akin to how when if deploying client-side JS using TypeScript is basically "driving with the parking brake on" since you're introducing the overhead of vigorous type-wrangling in an interpreted runtime.

I initially didn't like "use strict" just because of how a number of things it does are just pedantic BS typical of -- as you mentioned -- linter rubbish.

Take the one that really raised my ire, the "don't use WITH" rubbish that's as idiotic as how linters kvetch about "yodish" or "drop-through on case" or the vast majority of the rest of the nonsense they spew.

It all really does reek of "I'm too stupid to understand this coding technique, so nobody else should be allowed to use it."

Which is why C++, Object Pascal, Ada, and Smalltalk programmers would look at the removal of "with" and respond with a string of insulting expletives. It's kind of like the nutjobs screaming "don't use IF as it can end up indenting too much" being pointed at, laughed at, and disrespected by Python dev's.

I didn't fight it ~12-13 years ago because of the claims of ALLEGED speed bonuses, even though it kind of had some "developer smell" to it. That was stupid and inconsistent behavior from me, and as of right now I'm dropping it from all my codebases.

Thanks for giving me the nudge and confirming one of my long held suspicions.