I think I have used weak equality once, because I needed truthy/falsy. I've always used strong equality. I always tell people that unless there is an absolute need for weak equality and you can thoroughly explain why weak equality works better than another solution, refactor for strong equality.

The all these weird quirks thing was really a naive me talking back then. JS was my second language after Java. Anonymous functions, async execution, implicit typing, weak typing - it requires a different way of thinking when you move from Java to JS and you're just starting. Most everything is explicitly defined, and everything executes in the order that is listed in Java. JS is whole different beast.

There are plenty of times where you want ==, or for that matter, any falsy/truthy expression in JS... about the only points where I have issues with some of the defaults for falsy/truthy come down to the number 0... Outside that, I find that there are times where I'm dealing with inputs that can be a string or number, and the coercion can be handy.

I would never suggest people start learning programming with JS first... although, there is the huge benefit of not needing more than a text editor and browser (already on their machine) to get started with it. One area of JS that I HATE is Date... it sucks, it's woefully incomplete and moment-timezone is huge to download in a browser.

The primitives, coercion and a lot of other bits of JS I really appreciate... but === vs == is pretty low on my list... that said, I tend to prefer the airbnb eslint preset, so it makes me use it anyway.

> There are plenty of times where you want ==

FWIW, I've never used ==

FWIW, I almost always use ==. Very rarely, if ever, had any problems- probably I'm used to javascript enough to think in advance of the edge cases and use === when I feel it's necessary.

> I'm used to javascript enough to think in advance

I don't consider it a foresight issue. I'm a believer in putting the burden on the caller not the callee. If I expect 0 and you have "0", it's your job to call parseInt(), not my job to branch out some if statements for type checking and coercion. For a few reasons:

1) debugging someone else's code is a lot more time consuming than debugging your own

2) actually fixing a bug in someone else's code means a pull request to someone who may not actively maintain that code

3) the docs are simpler to write and easier to read.

It's my only pain point with the JS community. The "give me whatever and I'll see if I can handle it for you" mentality:

  function doStuff(a, b, c) {

      if (!c && b instanceof Function) {
          c = b;
      }
      c()
  }

"`doStuff` takes 2 or 3 arguments, depending on what you feel like giving it."

I'd rather be expressly told what to give you than try to read a wall of if statements in both the docs and your code.

True, although your example is probably just an attempt to offer method overloading. But I agree that it is confusing. And you do see a lot of times functions trying to sanitise their inputs, which I agree is wrong.

It's my opinion that if I can execute without error, I should execute without error... if that means I `~~input` to make certain I'm working with a whole number, I'll do it. If someone calls me with invalid input, and it's coerced and you get invalid output, so be it.. it didn't crash/error.

That said, the biggest problem I've seen in a lot of projects, bigger than coercion and in languages including, but not limited to JS is not properly handling error cases.

> so be it.. it didn't crash/error.

That's a HUGE problem. This is an absolutely fucking nightmare. It's arguably the hardest thing to possibly debug, because you're not informed it's a bug. No amount of error handling will solve that, which you've pointed out as "the biggest problem".

> If someone calls me with invalid input, and it's coerced and you get invalid output

But this isn't the problem. The problem is when it gets called with invalid input and somehow gets coerced into a valid but unexpected output. Expected input -> Expected output means you get instant gratification as to whether or not it works. This dramatically reduces the number of error cases which naturally and effortlessly moves toward solving your complaint.

Multiple dispatch would be a cleaner approach for languages that support multiple versions of doStuff.