> If you are a professional developer, you can consider these examples as a great resource for interview questions and quizzes for newcomers in your company<p>No, do not consider these examples as a "great" resource for interview questions. They are nothing more than tricks and hacks abusing the bad aspects of the language and anyone who includes them in an interview has failed in screening JavaScript developers, at least in my book.<p>A JS developer should understand that JavaScript has some flawed, unfixable core concepts and educate themselves on how to avoid them, not use them in actual production code or memorize every coercion scenario.<p>Some simple rules:<p>1. Always use referential equality checks (triple equal `===`). In idiomatic JS you can also use double equality only when explicitly checking against undefined or null (foo == null). It's the only use of abstract equality that I find acceptable.<p>2. Learn how the `this` execution context works. Kyle Simpson explains it very well in YDKJS (<a href="https://github.com/getify/You-Dont-Know-JS/blob/master/this%20%26%20object%20prototypes/ch2.md" rel="nofollow">https://github.com/getify/You-Dont-Know-JS/blob/master/this%...</a>). There are four simple rules that matter and are straightforward to grasp.<p>3. Familiarize yourself with how type coercion works in JS but avoid it. The spec is quite easy to follow in this matter and follows very specific, documented rules. e.g.:<p><a href="https://www.ecma-international.org/ecma-262/8.0/index.html#sec-additive-operators" rel="nofollow">https://www.ecma-international.org/ecma-262/8.0/index.html#s...</a>
<a href="https://www.ecma-international.org/ecma-262/8.0/index.html#sec-abstract-equality-comparison" rel="nofollow">https://www.ecma-international.org/ecma-262/8.0/index.html#s...</a><p>Use strictly as reference.<p>4. Stop using plain ES5, the language currently is ES2017. ES2015 and beyond provide modern constructs that make most of ES5's weirdness obsolete. For example, never use `var` anymore, `const` and `let` are superior initializers.<p>By following the above rules a JS developer should be fine in 99% of cases, in my experience. Yes, JavaScript will possibly implode on you on the rest 1%, but I'd be hard pressed to find a (similarly popular) language that doesn't. If one finds that to be unacceptable, enabling types via TypeScript or Flow should make their life even easier.
<i>We can fix this with Greater than or equal operator (>=):</i><p><i>3 > 2 >= 1 // true</i><p>What? No, JavaScript doesn't have chained comparison operators, as the author seems to know but not explain. Overall this list is pretty misleading and uninteresting IMHO.
> Object.create(Array).length === 1 //true<p>it bothers me how the examples are often misleading or just misusing language features but people who don't know the language will gladly agree with them and have their "js sucks" belief reinforced
<p><pre><code> $python
Python 2.7.9 (default, Jun 29 2016, 13:08:31)
[GCC 4.9.2] on linux2
>>> True + True
2
>>>
</code></pre>
okay...<p><pre><code> python3
Python 3.4.2 (default, Oct 8 2014, 10:45:20)
[GCC 4.9.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> True + True
2
>>>
</code></pre>
I'm going to try this in Rust.
From a few years back but made me laugh a lot: <a href="https://www.destroyallsoftware.com/talks/wat" rel="nofollow">https://www.destroyallsoftware.com/talks/wat</a>
Such blatant misuse of the language in these examples. Not sure what to think. It seems like the author has a good understanding of JS, but then goes out of the way to purposefully misrepresent things to construct strawmen simply to then tear them down. If someone comes across this without being familiar with JS, they could very easily be misled.<p>As a comparison, how many WTF C++ examples could be constructed if people misused arrays, pointers, bitwise comparators, oeprator overloads, templates, etc... to create nonsensical operations?
<p><pre><code> (typeof (new (class { class () {} }))) // -> 'object'
It seems like we're declaring a class inside of class. Should be and error, however, we get an 'object' string.
Explanation:
Since ECMAScript 5 era, keywords are allowed as property names.
</code></pre>
Can anyone explain why allowing keywords as property names seemed a good idea? To me it creates a lot of potential for confusion without providing enough benefits, but I'd like to be... enlightened
From now on I'm going to include at least one of these in each interview I'll be conducting - for extra points of course.<p>Anyway a lot of these examples can be explained if you know how type coercion works in JS and are aware what the `valueOf` method exists for.<p>Here's a nice write-up about this mechanism: <a href="http://2ality.com/2011/12/fake-operator-overloading.html" rel="nofollow">http://2ality.com/2011/12/fake-operator-overloading.html</a>
My favorite:<p><pre><code> x = "053"
y = 50
z = "40"
x > y
// -> true
y > z
// -> true
z > x
// -> true</code></pre>
Except for "Precision of 0.1 + 0.2" which all programmers should know is a floating point fraction arithmetic limitation, not a JavaScript issue.
It's interesting to see that a lot of people make fun of JS, publish articles on how weird it could be, receive a ton of likes, but still it's the most popular programming language at the moment. It's like Stockholm Syndrome we developed with time!