[wizzwizz4]

In my experience, Python, C and JavaScript* all have this property; whereas I have to relearn Pascal, Haskell, sh and (to an extent) Rust every time I go away from them for a bit. I think this is more a property of you or I than of particular languages.

*: excluding `for (… of …)` and `for (… in …)` – I can never remember which is which. `for (… of …)` is the one you can use with Arrays and other iterables.

[lelanthran]

> *: excluding `for (… of …)` and `for (… in …)`

There's more that will trip you up in JS if you leave it for too long. Off the top of my head:

1. Which function definition (`function` or `=>`) do I need to use in order to make the `this` keyword point at the correct object in an event handler/anonymous function/foreach parameter?

2. I see code with both `!==` and `!=` - what is the significance of using both?

3. Long chains of `filter` and `map`.

[jameshart]

Long chains of filter and map are common in any language - they may have better chaining syntaxes, but since mapreduce can basically implement any collection operation you can imagine, filter and map chains are going to crop up.

With its tuple, object, and destructuring syntaxes JS actually ends up with some of the most readable mapreduce code of mainstream C-derived languages (it’s soooo much worse in Java).

[wizzwizz4]

1. `function` gives you a new `this`, whereas `=>` closes over the `this` from the parent scope. Which to use depends on what you want. (Full disclosure: I would've had to think for a bit whether the syntax was `->` or `=>` – though I'd probably guess `=>` because `->` means something in C.)

2. `!==` is strict comparison, and `!=` tries to do incomprehensible magick to munge incomparable types together. I still know some of the rules (array to string sticks in my mind), but I doubt many people know all of them. There's almost never a good reason to use `!=`, outside `elem.value != my_integer`. (Though `NaN !== NaN`, so you need to watch out for that: since equality is defined recursively on objects I'm pretty sure this is infectious.)

3. The length of the chain is easy (though, iirc there are performance implications since it's not lazy). The hard part is the fact that map callbacks can take one, two or three arguments, so stuff like `["123", "456", "10", "1234"].map(parseInt)` will behave unexpectedly. (Something like `[123, undefined, 2, 5]`, though I might be thinking of PHP.) Not sure whether `Array.prototype.filter` has similar gotchas.

That's off the top of my head. I haven't seriously used JavaScript since the ES5 times, but JavaScript's a very… memorable… language. (I can't even remember hello world in Pascal.)

[Jean-Papoulos]

I just tried make a ".any" generic function for arrays, and by god :

Most languages : myArray.any((e) => true);

Delphi : AClass.any<Type>(myArray, function (e) : Boolean begin Exit(True); end);

The readability is through the roof, lol.

[fzzzy]

Just always use !==. != will automatically cast and !== won't, therefore "1" != 1 is false and "1" !== 1 is true.

[hellcow]

Unless you’re testing if something is null or undefined, in which case a single “x != null” handles it.

[fzzzy]

Sure. I usually just use !x for that.

[SamBam]

That doesn't test if it's null or undefined, that just tests if it's not falsy.

x = 0; !x → true

y = ""; !y → true

z = null; !z → true