• Denys Nykula@piefed.social
    link
    fedilink
    English
    arrow-up
    2
    ·
    3 days ago

    == has never, ever caused me a single issue. Parsing all server input with type-safe schemas makes sure that where I expect a string, I get a string; where I expect a number, I get a number. Bad data must result in an error before it reaches logic.

      • grue@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        2 days ago

        I wonder how many millions of programmer man-hours have been wasted working around JavaScript’s design mistakes that could’ve been saved simply by putting Scheme or Python (which were actually being considered) in the browser instead.

      • Denys Nykula@piefed.social
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 days ago

        Opposite, living in a house of cards is when you blindly trust data that comes from user. Regardless of the language. eqeqeq isn’t in the recommended linting presets because if you end up needing it, you’re probably already in big trouble because of insecure software design.

          • Denys Nykula@piefed.social
            link
            fedilink
            English
            arrow-up
            0
            ·
            2 days ago

            Then where do you see the house of cards? What’s the practical difference between == and ===, when your app is type-checked and the inputs are safely parsed?

            • NateNate60@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              1 day ago

              Because you don’t know whether you’ve actually type-checked everything and that your inputs are safely parsed. Part of defensive programming is to adopt multiple defences to prevent bad data from getting through, including avoiding ==.