I’m a ‘JS Engineering Intern’ at Behance. Thus, I must JS. And if you JS for long enough, you shall find darkness.
##Bitwise complement and indexOf
Yes. This is roughly equivalent to:
Remember your freshman year computer science class where you learned how 2’s complement works, and that -1 will be represented by a series of 1’s in binary. Thus the bitwise complement operator
~, which flips all the bits, will result in a zero value for only -1.
Yes, that second line is the output of the sort. From the docs:
…elements are sorted by converting them to strings and comparing strings in Unicode code point order
Provided you don’t supply a custom comparator.
The right code?
Imagine you’re writing an algorithm that uses sort. Some test cases pass, others don’t, and you start digging in to your code only to find that it isn’t actually sorted?
Yeah well I guess you should just RTFM, right? Yeah, that’ll solve all your problems.
Okay..so it’s a function that accesses object using…this? So I’m accessing an object, with an object, right?
Then you discover
this, is a string. WHAT?
The assumption in this function is that the caller did something like this:
Now we have an object with a string as its context, right (bind docs here)?
What have we done?
It turns out, what we have here is a string which has had
toObject called on it. If you
'use strict' in
getThing, however, this ‘feature’ goes away.
We just get a string, which seems to make some amount of sense. If we do decide to give a string as our
this (though I would hope you don’t), it is less surprising to have it indeed be a string when we use it. This still does nothing to prevent the sheer terror you potentially inflict on another innocent developer (or intern) who happens to come across a string
You would probably expect
x to be
undefined, yet this code is equivalent to this:
…declaring a variable anywhere in the code is equivalent to declaring it at the top. This also means that a variable can appear to be used before it’s declared. This behavior is called “hoisting”
Writing code that relies on this behavior should be considered cruel and unusual punishment for those who must later decipher it.
What is that semicolon doing, you might ask? Well imagine a scenario like the one below, except the first line is code that got concatenated with yours (which is the second line).
If the author of some other script forgot, or simply opted not to include a semicolon at the end, it might treat your library code as part of an expression in the preceding script.
In fact, there’s a tool out there that abuses the above functionality:
##Is there hope?
Maybe. ES2015/ES6 is quite promising in many ways, yet for all that it may help, it will also enable you to do things like this:
I didn’t come up with this example, and I don’t know how it works. I’ve been told it’s nested destructuring. Is it often useful? Probably. Will people write code that looks like this example? Yes.
In addition, the arrow function syntax (usefully) provides a difference over the current syntax, preventing you from needing to bind functions to
this in callbacks.
While this feature is useful to those who are aware of it, it is just one more obscure detail of the language to those who don’t, no matter how much I enjoy the new syntax myself.
So if you ask me, no. There is no hope.