It's surprising in almost every language that does it to any degree. JS's is only slightly stranger than, say, PHP. About the only exception is "empty values are falsy", and even that surprises people pretty frequently, and can be used to construct highly confusing snippets of behavior.
Sometimes it seems javascript has a mind of its own, and turns all my numbers into strings when I'm not looking, so I have to sprinkle x = x | 0 throughout the code, like hanging garlic.
It seems to me like those two things are orthogonal. (Not that JS wouldn't necessarily be nicer with a separate concatenation operator.)
const y = +x + 12;
Will be number addition even if x is a string.
const y = Number(x) + 12
1 + "five" is an error in PHP, not some random correct-looking value.
On older ones though, it's not an error: https://onlinephp.io?s=s7EvyCjg5UpNzshXMFTQVlBKyyxLVbIGAA%2C...
Even in the previous major version (7) it's only a warning.
I agree that philosophy is likely the main cause of decisions like this, but JS is hardly unique in having it.
Meaning of course "no errors reported, at any cost".
Programming language language has redefined "error" - to substantial cost to programmers.
It’s a philosophy that might be acceptable for a simple-ish frontend, but when if you try and build something significant it’s just awful.
Source: I inherited responsibility for a > 5m LOC system written in JavaScript. The problems aren’t all JavaScript’s fault, but it does play a major part in it.
+1
A case I'm struggling with recently is Fastmail mail search. Given a valid query which it cannot handle, rather than show an error report, it does its "best" and delivers a false result. With potentially great cost to the unwitting user. Is there even a warning on the doc page?? No.
Forget JavaScript, that's not even an error in Java.
But anyway, it's much less bad in Java because you can force it to err by declaring what type of thing you want it to return.