technical reviewabout you-dont-know-js

[the-simian]

technical review [email protected]

[the-simian]

Chapter 1 - Scopes and Closures.

This section was pretty straightforward. The conversation between engine and scope was a nice way to explain the entire process. Even though it was simple, you might consider putting the answer to your quiz somewhere "in the back" so that someone can check their understanding up to this point.

The metaphor for nested scope as a many-storied building was very clear.

This chapter was probably the best explanation of scope I've ever seen.

[the-simian]

Chapter 2 - Lexical Scope

Everything ran with no problems.
The section on cheating scope was a really clear explanation why eval and with are dangerous.

[the-simian]

Chapter 3 - Function vs. Block Scope.

Firstly:

Note: Anonymous function expressions are easy to type, and many libraries and tools tend to encourage this style of code. However, they are less desirable in that they create harder to debug code. Also, naming your function expressions removes any need to ever use the deprecated arguments.callee to refer to the current function from within itself, for instance to re-invoke a function for recursion, etc.

First of all, I agree with this statement. You're right, that anonymous are harder to trace and are less self-documenting. However, a lot of readers are going to really question this note on a first pass, because anonymous functions are just so prevalent out in the wild, and usually covered as standard, good practice.

Here are some quick examples :

*http://jstherightway.org/

Listed in 'Good Parts'

*Javascript Enlightment by Cody Lindley "Anonymous Functions", "Self-Invoking Anonymous Function Statements" in chapter 4.

Covered as standard practice.

*Secrets of the Javascript Ninja by John Ressig : Chapter 4.1: Anonymous Functions

"We’re going to see anonymous functions a lot in the rest of this book’s code because prowess with JavaScript relies upon using it as a functional language"

*Javascript Web Applications by Alex MacCaw ch 4.1 The Module Pattern -

"The module pattern is a great way to encapsulate logic and prevent global namespace pollution. It’s all made possible by anonymous functions, which are arguably the single best feature of JavaScript. We’ll just create an anonymous function and execute it immediately."

I should note that other sources, more or less state what you are saying here, for example:
*High Performance Javascript by Nicholas Zakas : Chapter 10.3: Anonymous Functions-

"The best way to enable profiling of anonymous functions is to name them."

If you have an appendix, or chapter going into much more detail about this, reference it right when you say this. Many readers will certainly want to read your explanation on this topic before moving forward, since many folks share differing opinions on the topic.

Secondly:

The let section. I noticed you took the time to compose a very well thought out explanation on let, how to shim it and so on. At the bottom of the section, I see you mention "For another way to express explicit block scopes, see Appendix B."

To be clear, most readers will have this let code fail before they see this message, unless they are running Firefox. (They will be running IE 10 or less, or Chrome). To reduce reader confusion, you might consider referencing your appendix before you introduce code someone might type, and in the appendix also reference the ES6 compatibility table, turning on Chrome's experimental feature and so on. Supposedly the full ES6 spec may not be in all A grade browsers until the end of 2015.

Those two minor things aside, this section was really interesting, and felt like it really built upon the ideas of the previous two chapters. Thusfar, this is the clearest explanation of scope, where it lives and how it works I've seen. I really enjoy this book.

[the-simian]

Chapter 4 - Hoisting
Firstly:

In other words, the egg comes before the chicken.

I wasn't sure what was supposed to be the chicken, and which was the egg in your metaphor until this statement, which made the bolded "in other words" a bit less impactful. Egg is variable declaration, right?

egg = 'chicken';
var egg;
console.log(egg);

perhaps?

Secondly:

After reading the chapter title, I half expected you to demonstrate function hoisting by addressing the situation where functions can even be hoisted past a return statement. Not to say folks should actually write like that, but it does produce an interesting effect.

eg: this works:

function foo(){
    return baz();

    function baz(){
        return 'hoisting!';
    }
}

console.log(foo()); // 'hoisting!'

...but this doesn't:

function foo(){
    return baz;
    var baz = 'hoisting';
}

console.log(foo()); // 'undefined!'

Aside from those thoughts, I felt like the section was very clear. this is a really good explanation of hoisting.

[the-simian]

Chapter 5 - Scope Closures

Closure is when a function is able to remember and access his lexical scope even when that function is executing outside his lexical scope.

Yes! Thanks for introducing this early. It makes the whole chapter very clear.

function activateBot(name,selector) {
    $(selector).click(function(){
        console.log("Activating: " + name);
    });
}

activateBot("Closure Bot 1", "#bot_1");
activateBot("Closure Bot 2", "#bot_2");

Whilst your example does not necessarily need to be aware of this, it is of note that jQuery conventionally 'hijacks' this to always make it target the node that emitted click. You are expected to us .proxy() to change.

Speaking of hijacking this:

Somewhere in this entire Scopes and Closures, I kept expecting explanations of the difference between call() and apply()

As in what is happening here:

(function IFFE() {
    this.meat = 'chicken';
    var scopeOne = {
        meat: 'beef'
    }
    var scopeTwo = {
        meat: 'shrimp'
    }
    function mealPrinter(noodle, vegetables, heat){
        console.log(
            'Meal : ' + 
            noodle + ' noodle with ' + 
            this.meat + ' and ' +  
            heat + ' ' + vegetables);
    }    
    mealPrinter('flat', 'carrots', 'mild');
    mealPrinter.call(scopeOne, 'round', 'potatoes', 'hot');
    mealPrinter.apply(scopeTwo, ['glass', 'yams', 'super spicy']);
})()

//Prints:
//Meal : flat noodle with chicken and mild carrots
//Meal : round noodle with beef and hot potatoes
//Meal : glass noodle with shrimp and super spicy yams

I really, really liked the modules example. It was a very clear example of how all this is leading up to the foundating of some basic design patterns. Double thumbs up!

Of note on that, I should mention:

This is the pattern in JavaScript we call module. Other common names for it include "Revealing Module".

Not to be pedantic, but the Revelaing Module Pattern, is basically a subset of module. Its a way to execute Module Pattern.

Reference: Addy Osmandi's Essential Js Patterns : Module Pattern.

There are a number of ways to handle modules, as seen in the various frameworks mentioned. The revealing module pattern is when you specifically.

simply define all of our functions and variables in the private scope and return an anonymous object with pointers to the private functionality we wished to reveal as public.

So a Revealing Module Pattern Implementation is a Module Pattern Implementation, but a Module Pattern Implementation may not be a Revealing Module Pattern Implementation.

In other words, a square is a rectangle, but a rectangle is not necessarily a square.

I suggest something like:

In JS we call this pattern of writing code 'Module' (or "The Module Pattern"). There are many ways to implement The Module Pattern, but the implementation of module written here is called "The Revealing Module Pattern".

[the-simian]

Appendix C: Lexical-this :

[getify]

Thanks for all the great feedback. I've finished posting revisions that take your comments into account.