Comment

Except strict equality, that’s a JavaScript only problem. Imagine thinking “0” should be falsy in comparison due to string literal evaluation, but truthy with logical not applied based on non-empty string. Thus !“0”==“0” is true. They couldn’t just throw away == and start over nooooo let’s add === . Utter madness

source

Sort:hotnew top

soloner@lemmy.world ⁨1⁩ ⁨year⁩ ago
Browser compatibility. Design flaws can’t easily be fixed like how other languages can just switch to a new major version and introduce breaking changes. ES must keep backwards compatibility so has had to do more additive changes than replacing behavior altogether so that older web pages pages don’t break.

source
- MyNameIsIgglePiggle@sh.itjust.works ⁨1⁩ ⁨year⁩ ago
  Meanwhile google is about to break the internet with html drm
  
  source
JonEFive@midwest.social ⁨1⁩ ⁨year⁩ ago
Strict vs loose equality has gotten me so many times, but I can sort of see why they did it. The problem you mention with integers 0 & 1 is a major annoyance though. Like it is fairly common to check whether a variable is populated by using if (variable) {} - if the variable happens to be an integer, and that integer happens to be 0, loose quality will reflect that as false.

But on the other side, there have been plenty of occasions where I’m expecting a boolean to come from somewhere and instead the data is passed as a text string. “true” == true but “true” !== true

source