I don’t know JS
April 03, 2019
When I was in college, I mostly stuck to programming in C and C++, apart from occasional fiddling with Java, C#, and Python. I got a job as a Python programmer, and I read this book called Think Python, which had practice exercises that were really fun to work on. This solidified my understanding of Python.
So when a colleague told me about this series of books called “You Don’t Know JS” by Kyle Simpson (getify) I was like, well, I actually don’t know JS, and it sounds like a great idea to read this series!
But the author says we’re missing out.
The first chapter is called “Into Programming”. I could’ve skipped this, because it introduced programming concepts that I’m already familiar with. My favourite part of this chapter was a discussion about the assignment operator. When we write, say,
a = 10, we mean, assign the value
10 to the variable
a. The author says this could be confusing or non-intuitive for people who are new to programming. He says using a different syntax, say,
10 -> a is better to indicate that the value
10 is assigned to the variable
a. I’m used to syntax like
a = 10, because I read it as “
10”. But I remember thinking about this when I was programming on an 8086 in college: the syntax for a move is
mov ax, 10h, which means move the value
10h to the register
ax, and I wonder if syntax like
mov 10h, ax makes it more understandable (to me).
- Loose equals: I used to think of loose-equals as something to be used only when I’m sure the values on both sides are the same type. I’ve even read styleguides that tell you to completely avoid loose-equals. The author explains that loose-equals is equality with coercion allowed, and links to the ES5 specification for loose equals. This turns out to be an easily readable algorithm for something that I thought was “weird”. I even found a really cool visualisation of the algorithm on https://nem035.github.io/js-equality-algorithms/
- Hoisting: I had no idea that I could declare
vars after I use them, even though I was pretty comfortable with declaring functions after I use them. The author says we can think of
vardeclarations as conceptually being moved to the top of the scope, making the
varavailable throughout the scope. However, he says we should not rely on hoisting to declare variables later, because that’d make it confusing.
- Closures: This section has an enlightening example that shows how closures can access a function’s variables even after the function has been executed. This reminds me of Dan Abramov’s blog on the difference between function and class components where he says function components “capture” props. I think I’ll need to understand closures well before I can understand this blog post.
thisidentifier does not refer to the function in which it appears! There are examples of the four ways in which
thisis set, and I’m told to refer to “this and Object Prototypes” for more info.
- Prototypes: When I look up array or object methods on MDN, the headings are of the type “Array.prototype.filter()”. I have a vague idea that a prototype is where the object’s default properties and methods are declared, and this chapter has an example illustrating how prototype linkage works, and suggests that I read chapters 4–6 of the title “this and Object Prototypes”.
The third chapter is titled “Into YDKJS” and it’s a summary of the rest of the titles in the series:
- In this and Object Prototypes, he takes a stance against JS developers using object Prototypes to emulate classes and inheritance, and suggests we follow a pattern that he calls “behaviour delegation”.
- In Types and Coercion, he suggests that type coercion is an underestimated tool that we should be using in code! This is a stance against the lint rules that throw errors whenever I use loose-equals.
- In Async and Performance, he says asynchrony is required for high performance, and describes why callbacks are insufficient for asynchronous programming. He introduces promises and generators to fill this gap.
- In ES6 and Beyond, he lists exciting ES6 things to look forward to.
The last chapter was difficult for me to read, because I wanted concrete explanations for everything he said. I’m looking forward to reading the other titles of You Don’t Know JS!