To be fair, I lost patience reading such threads. They usually boil down to:

“If you are a disciplined hardcore veteran like myself you’ll never make these mistakes!”

Which is so dumb and unrealistic that it should not even be graced with the honor of replying to it.

This seems to rear its ugly head pretty often when having to deal with a JSON API. Had to deal with this a few times recently. Discovered the other week, if you give it a JSON object with only numeric keys (which are strings with numbers in them because numbers as keys are not valid JSON) regardless of whether they are sequential, it thinks the object is an array. Who would have thought {“1”; “one”, “9”: “nine”} should be turned into [“one”, “nine”]? apparently someone

I’m not sure if it is more or less, JS weirdness I’m much more familiar with which doesn’t make it particularly easy to look at objectively. I do tend to find that while JS has a lot that is really easy to poke fun at, it is also generally fairly easy to avoid (within the bounds of a complete lack of type safety) many of the pitfalls. I also generally find a lot of discussion, examples of usage etc go a long way to pushing you away from those pitfalls as well. Laravel by default decodes JSON in this way, so with what is one of the most popular web frameworks you are basically being guided towards having this problem and certainly on the versions I’ve had to deal with recently (which are old) there is no easy way to get at the original request in the middleware chain or the validation rules they have, making things impacted by this decision painful to do validation on. Also today I learned in another case of PHP weirdness that the string “0” is falsey, so

if(“0”) {
    // do nothing
} else { 
    echo “wat!”; 
}

Does indeed echo “wat!”. Even JS isn’t quite that insane unless you introduce some coercion into the condition (at which point you will receive all the pain and suffering that comes with doing something so stupid).