5 ms·

When I first started learning JavaScript, I wondered how people became proficient at the langue with all these weird quirks[0] that don't raise errors. Turns ou

When I first started learning JavaScript, I wondered how people became proficient at the langue with all these weird quirks[0] that don't raise errors. Turns out that there are a bevy of things to help combat these quirks. Two of them are strict mode[1] (which can be scoped[2] in instances were libraries/frameworks would fail running in strict mode) and linters. Strict mode and linters do not fix everything. This is doubly so if your developers ignore the warnings and errors that the linter throws. The language isn't inherently bad, but plain old JavaScript is not beginner friendly for new developers. It requires the discipline to not just throw things together. [0]: https://dorey.github.io/JavaScript-Equality-Table/unified/ https://dorey.github.io/JavaScript-Equality-Table/unified/ [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]:https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode#Invoking_strict_mode https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Udik 10y ago
> I wondered how people became proficient at the langue with all these weird quirks[0] (links the usual loose equality table) Why don't you all just use === instead of ==? Tell me, how long does it take to learn it?
- tracker1 10y ago
  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.
  - lloyd-christmas 10y ago
    > There are plenty of times where you want == FWIW, I've never used ==
    - Udik 10y ago
      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.
      - lloyd-christmas 10y ago
        > 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.
        tracker1 10y ago
        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.
- noxToken 10y ago
  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.

Udik 10y ago

> I wondered how people became proficient at the langue with all these weird quirks[0] (links the usual loose equality table) Why don't you all just use === instead of ==? Tell me, how long does it take to learn it?

tracker1 10y ago
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.
- lloyd-christmas 10y ago
  > There are plenty of times where you want == FWIW, I've never used ==
  - Udik 10y ago
    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.
    - lloyd-christmas 10y ago
      > 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.
      - tracker1 10y ago
        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.
noxToken 10y ago
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.