Welcome to Part 4 of this review of the Pluralsight and Front End Masters course Advanced JavaScript by Kyle Simpson.

Kyle Simpson is Head of Curriculum for MakerSquare and an evangelist of the open web. He lives in Austin, Texas, and is passionate about all things JavaScript.

He’s written 8 books published by O’Reilly, including six books in the You Don’t Know JS series.

Kyle teaches JavaScript and has eight courses recorded by Front End Masters.

He’s a public speaker, and contributes to the world of OSS.

In this series:

Part 1 – Introduction
Part 2 – Scope
Part 3 – Lexical Scope
Part 4 – Block scoping
Part 5 – Dynamic Scope, Hoisting and this
Part 6 – Closure
Part 7 – Object Prototypes

Block Scoping

Block Scope in ES6

Kyle reintroduces ES6 block scope with the let keyword.

function foo() {
var bar = “bar”;
for (let i=0; i<bar.length; i++) {
console.log(bar.charAt(i));
}
console.log(i); //ReferenceError
}

foo();

If we had use var instead of let in the above example it would log out i to the console.

let attaches the scope to the for loop as opposed to the function. This is how languages such as Java and C# work with scoping.

Kyle gives an anecdote: Mozilla have used the let keyword for about a decade, and his early code commits were reject because he used var instead of let.

I find it very hard to disagree with Kyle’s assertion that the var keyword still has a place in JS development. It has not and never will be deprecated. And if you write JavaScript, understanding how var works is one of the most basic things that you need to know.

In a week or two I will be reviewing Mark Zamoyta’s “Rapid ES6 Training” course so expect a lot more ES6 coverage on this blog soon.

Problems with the let keyword

These are Kyle’s opinions on the problems:

1. The let keyword does not hoist, which could cause problems in very long functions if you don’t manually put all your lets at the top.
2. Block scoping creates an extra mental tax for refactoring
3. It’s sort of hijacking the scope of whatever blocking exists. Implicit mechanisms are usually harder to maintain than explicit mechanisms, so Kyle prefers explicit scope blocks

So there is another form of let known as a let blocks that Kyle prefers:

function foo(bar) {
let (baz = bar) {
console.log(baz); //”bar”
}
console.log(baz); //Error
}

foo(“bar”);

Unfortunately this never made it passed the proposal stage and isn’t part of the ES2015 or ES2016 standard 😦

Kyle “actually cried for a few days”. Then he wrote this gist and created let-er.

We see that (like many, or perhaps even all transpilers) the code that it produces look “awful and ugly”, wrapping your block scoped code in try catch blocks.

On the plus side, this works with all ES3 browsers. I believe that even IE6 fully supports that.

He says Traceur, the official TC39 tool from Google produces this same code.

(Since this course was recorded, Babel JS has really exploded, both in popularity and in overall quality. So if you want to use a transpiler check that out.)

Continue to Part 5 – Dynamic Scope