Wednesday, July 18, 2012

LET, the new VAR

If you are first getting into the changes that will be coming down once the ES6 spec is finalized, then let might be the perfect place for you to start. It is simple enough to beginners and monumental enough for experts. Using let will, in a very real sense, change the way that we write JavaScript.

Basically it's...
At it's very basic level, let is a replacement for var. Instead of: 

    var foo = 'bar';

We'll say:

    let foo = 'bar';

Considering most of the comments I found about let from the JS community, it appears that most people will attempt to use let as exclusively as possible.

Seems anti-climactic
If all let did was to simply replace our current var syntax, then it wouldn't have a point. However, there are some very beautiful things that we get when using let instead of var.

In order to appreciate pretty much the rest of this post, you will need to have a firm understanding of Variable Hoisting. In the book we covered it extensively. For the sake of brevity, and given that this is a blog and not a book, I would like to refer anyone with questions about Variable Hoisting to this video, where it is explained very well.  

I can haz scope control?
Any developer who has experience with C-based languages understands scope control. Consider the following Java snippet:

        int myInt = 0;

Knowing what we know about these C-based languages, the int inside the if-statement is not available outside of the if-statement. If the next line of code tried to reference myInt, your code wouldn't compile because myInt was locked inside the if-statement.

Now let's try to same thing with var:

        var mynum = 0;

We have an issue here. The code would lead you (the developer) to believe that mynum is isolated inside the if-statement. But we all know that isn't true though, don't we. The JavaScript Compiler re-structured the code to look as follows:

    var mynum = undefined;
        mynum = 0;

Since mynum's declaration was hoisted to the top of the current scope, the mynum variable will be available through out the entire scope.

I am not saying that the way var behaves is a bad thing. It can be very useful. Having said that, one of the downsides of how var behaves is that the code will read differently than it will run. This makes it tough to spot errors some times.

let in action
Let's do the same thing again, but instead of using var we will use let.

        let mynum = 0;

In this situation, our JavaScript will run just like it reads. The variable mynum is scoped inside of that if-statement. Let solves some of our scoping issues.

While the above examples are extremely trivial, there is a lot to consider and re-learn when we start to use let.

let it be
As I mentioned before, the book covered these areas much more slowly and in greater detail, hopefully answering any questions that I left today. Here is a list of let tips:

  • Not sure if IE10 will even support this. If you have to support IE, then let it be. 
  • If you try to declare two let variables inside the same scope with the same variable name, you will get an error. 
  • let also applies to function expressions. 
  • When you read about ES6 Destructuring and Looping, let will appear again. 
  • There was talk about forcing an opt-in environment where var would be disallowed and only let would be allowed. I am not sure what came of that. 
  • let will allow for better IDE support with JavaScript. 
  • let should reduce memory usage at runtime, possibly speeding things up. 
As always, if I have made any mistakes, please point them out here so that we may all learn. 

No comments:

Post a Comment