hour1

Speaker Introduction Part 1

@getify -- Kyle Simpson -- Teaches JS professionally
- 50-75% traveling and teaching, rest of time “community building” -- open source / speaking / meet-ups
LABjs -- dynamic script loader, 5-years old -- fast, ensure order for dependencies
- Concatenate everything, why script loader? Seeing a switch to HTTP2. Why is this important? HTTP2 changes the way we optimize page load -- persistent socket protocol. Parallel downlaoding.
“Grips” -- templating engine.
- There are “logicless” templating engines like mustache. Requires a brittle connection between backend and frontend. Lots of data massaging.
- Alternative -- whole programming language embedded into template. I.E. PHP, Dust, Handlebars. Causes mess of business logic leaked into template due to business pressure.
- “Grips” is an oppinionated templating engine

"browser versions are dead" talk
- People outside the industry (sales, etc) have been dictating our architecture -- we should push back
We need to feature-test -- features are important, not browser versions
Sites / applications should be built so they perform the same in all environments
- Turn features on/off depending on browser environment, don't block users
90% of the time, you will still be forced to support outdated browsers
100% of the time you lose the battles you do not fight.
"You don't know JS: Scope and Closures" -- first version is out. Book is 100% free on github
- https://github.com/getify/You-Dont-Know-JS
Second title is complete, will be available soon.
Recommended books:
- High-performance JS
- JavaScript Patterns

Mozilla Developer Network (an open public Wiki) -- owned by the web-platform community
- Sign-in for free and edit it if examples are missing or wording is weird or things are simply wrong
Do a search for all topics discussed on MDN
idiomatic.js -- write-up of styles associated with JS projects

Have you ever looked at it? Kyle checks his work against it while writing books
"Something about the way the 'this' keyword gets bound" -- seemed like a misconception.
- Author of a blog post felt one way because of quote by John Resig
- Speaker disagreed.
- Spec says this -- are you sure what you're saying is correct?
- Speaker says he went through spec to build an argument to defend his point
How to find something in the spec?
- Scan Table of Contents (i.e. look for 'this' keyword)
- Follow the rabbit trail
- 'this' -> 'ThisBinding' -> thisArg
Nothing in JS is magical -- it's all spelled out in the spec. It takes some practice, but in addition to blog posts etc you can reference the spec
Homework: Check things you learn against the spec -- see if you can figure it out / if you agree
ES6 spec is the future -- you can learn not just where the language is but where it's going
ES7 is also being discussed... macros? operator overloading?
TC39 community is incredibly open, with notes from their bi-monthly meetings etc. Take a look.

"What you need to know"
It's recommended you're atleast familiar with the language. We're not covering syntax
We will break down things like lexical scope into compiler terminology
There are things in JS you wouldn't know in 10 years of working with it -- we're going to learn that.
We will cover the practical terms rather than the accademic formalities
Scope / Closures
- Nested Scope
- Hoisting
- 'this' -- for contrast
- Closure
Exercises are 15 minutes of free-time to work on something
- these are followed by the solution
Goal: solid understanding of core functions that JS relys on.
You will understand what "a module hiding in scope" means
Node isn't the same as JS -- Node forces you to know more about JS than you would otherwise need to know, "or trouble"

Where to look for things (i.e. variables / lexical identifiers)
Who is doing the looking? (JavaScript is a compiled language)
- We don't distribute JS binaries
- It's compiled every time it is run
- Interpreted vs Compiled -- Bash is interpreted
  - When bash runs line 3, it has no idea about line 4
  - Interpreted langauges are top-to-bottom
  - Compilers do multiple passes through the code, so it has seen line 4 before running line 3
JavaScript has "function scope only"
- smallest unit in the language is the function

var foo = "bar";

function bar() {
   var foo = "baz";
}

function baz(foo) {
   foo = "bam";
   bam = "yay";
}

Tokenizing etc, we're glossing over that stuff
Important for us: finding declarations of variables and functions and putting them into the appropriate scopes
First pass for compiler, second pass to execute
var foo = "bar"; <-- variable declaration.
- This is two separate operations -- declaration and initialization
First pass finds all declarations
- First, JS finds variable declaration for "foo" and recognizes it's in global scope, so registers 'foo' in global scope
- Then we find "bar" which we note is a function, and so we register function "bar" in same global scope
  - We don't compile "bar" until we're asked to execute it (Just-in-time)
  - There's also "hot-swapping" where compiler guesses and hot-swaps bits when necessary
  - We're focused on naive top-down compiler approach

var foo = "bar";

function bar() {
   var foo = "baz";
}

function baz(foo) {
   foo = "bam";
   bam = "yay";
}

bar is in global scope, there's a var foo which is in "bar" scope
baz is in global scope, the arg (foo) gets declared implicitly in scope baz
no other declarations -- nothing else for scoe resolution
What about execution?
- the second operation of var foo = "bar" i.e. the (foo = "bar") is left
- if you do var foo; var foo; var foo; etc 100 times, after the first declaration the other 99 declarations are ignored. They don't exist during execution
"LHS" and "RHS" are compiler terms for left-hand-side and right-hand-side of an assignment
- in var foo = "bar", var is gone. foo is the LHS and "bar" is "RHS"
- LHS is target, RHS is source
- when I have an "LHS", I have to find "where" the LHS reference exists -- we check in scope.
- i.e. on line 1, "foo" is the LHS and it's in global scope
- "bar" is an immediate value on the RHS, no lookups needed

var foo = "bar";

function bar() {
   var foo = "baz";
}

function baz(foo) {
   foo = "bam";
   bam = "yay";
}

From an execution perspective, lines 3-10 don't exist anymore because they were already declared
If bar() gets called, we execute line 4
- var foo = "baz";
- Where's foo? In local scope of bar()
- the LHS is in local scope, the RHS is immediate value again
- the "foo" in local scope gets assigned the immediate value "baz"
what about line 9? bam = "yay"?
- LHS is bam -- is it in local scope? No. Is it in global scope? "Yes -- it was just created"
  - because bam is LHS, and we're not in strict mode, the global scope creates it for us
  - not in local scope, but in global scope
- this assignment is to the global variable "bam"
- if you get to the global scope and the global says "no", then it's an error condition
An undeclared variable means we were unable to find a proper LHS reference in any scope
Undefined is not the same as undeclared
- undecalred means no declaration
- undefined means it was declared, but has an uninitialized "empty" value called undefined