I've been bitten by it.

I'm used to statically typed languages that allow calling HOF's with a function reference. If the signature matches, there's no reason to wrap it in a lambda.

So I did the same, reflexively in a Node project recently.

I've learned my lesson and now I just know to always use a lambda forJS function arguments.

In my experience yes and I use it myself as well, but with care. Optional parameters are a thing so when you're doing something like the author describe, you need to consider that your function is quietly receiving these parameters but just discarding them.

I see people using .filter(Boolean) a lot for example. If the signature of that were to change, for sure it wouldn't be something that quietly gets implemented, but I wouldn't pass formatting functions to these operations carelessly, especially in a codebase where there may not be tests. Some of the safer ways I've seen are use of unary helper functions to wrap the callback, or having the callback actually take the arguments but discarding them like (element, _index, _array). At least that way you communicate some intent.

I don't think so, maybe before JS had arrow functions. Now you would usually have an anonymous arrow function as a callback to explicitly state the calling contract. Then inside it apply the original function.

The parseInt bug that's mentioned in thd article is very likely to catch you eventually if you use Javascript for long enough.

The habit that I developed as a response to that is to always pass a lambda to the callback. That is, write this:

    foo(x => f(x))

instead of

    foo(f)

Yeh, first thought when I saw it was "who does this lol"

Yes it is (JavaScript is so widely used that probably every pattern is in use somewhere. I myself have done this many times and seen it being done as well!)