Fat Arrow Notation

Fat arrow notation is syntactic sugar for writing named and anonymous functions. It's particularly suited for the latter case due to the prevalent style in JS of passing around functions as callbacks. More importantly, unlike regular functions, they support a lexical 'this', which simply means they retain a correct reference to the 'this' variable of the surrounding code. Let's look at some examples:

//Anonymous arrow notation function
let f = x => x + 1

//Multiple arguments
let ma = (x, y) => x * y

//Block body
let fb = (x, y) { return Math.pow(x, y) }

//Arrow functions can only be named via variable assignment
let subtract = (x ,y) => x - y

Caveats

1. Arrow functions have a lexical 'this'

let basket = {
    basketName: 'myBasket',
    contents: ['oranges', 'bread', 'salami', 'cheeze'],
    printBasket: function() {
        this.contents.forEach((item) => {
            console.log(this.basketName + ' contains ' + item);
        });
    }
}

2. Always have a bound 'this', so calling arrow functions with .call() or .apply() cannot change the value of 'this'. You can, however use them to pass arbitrary amounts of aruments. 

3. They don't have a [[Construct]] internal method, nor a prototype property. This means they cannot be invoked as a constructor so the follwing code will fail: 

new (() => {})

Caveats (cont')

4. They don't have the 'arugments' special variable. They achieve the same functionality with the more syntactical mechanisms of Rest, Spread, and default values.

//y will be an array of arguments
function fn(x, ...y) {
  console.log(y.length);
}

5. Named arrow functions are under discussion and may not be implemented in the ES6 spec. 

Classes

As anyone who's ever had to implement classes in JS knows, they're highly vebose and cumbersome, forcing us to use the dreaded prototype syntax, as well as manually fixing the constructor

function className() {}

className.prototype.methodName = function() {}

className.prototype.constructor = className;

Not only is this syntax not semantic, it's quite verbose and feels like a hack, something dressed onto the language as an afterthought rather than a first class feature. And to top it all off, there's no notion of 'super' which leads to fun things like

Backbone.View.prototype.render.call(this);

ES6 classes propose solutions to almost all of these issues.

A Simple Class

class Monster extends Character {
    // A method named "constructor" defines the class’s constructor function.
    constructor(name, health) {
      this.name = name;
      this._health = health;
      //Perform superclass initialization
      super();
    }

    // An identifier followed by an argument list and body defines a
    // method. A “method” here is simply a function property on some
    // object.
    attack(target) {
      console.log('The monster attacks ' + target);
    }

    // The contextual keyword "get" followed by an identifier and
    // a curly body defines a getter in the same way that "get"
    // defines one in an object literal.
    get isAlive() {
      return this._health > 0;
    }

    // Likewise, "set" can be used to define setters.
    set health(value) {
      if (value < 0) {
        throw new Error('Health must be non-negative.')
      }
      this._health = value
    }
  }

Usage

  // The only way to create prototype data properties is by
  // modifying the prototype outside of the declaration.
  Monster.prototype.numAttacks = 0;

  // Immutable properties can be added with defineProperty.
  Object.defineProperty(
    Monster.prototype, 
    "attackMessage", 
    { value: 'The monster hits you!' }
  );

  let monster = new Monster('Ogre', 100);

  monster.attack('poor schmuck');
  console.log('The monster is ' + (monster.isAlive ? 'alive' : 'dead') + '!');
  console.log('The monster attacked you ' + monster.numAttacks + ' times');

  //Will output: 
  > The monster attacks poor schmuck
  > The monster is alive!
  > The monster attacked you 0 times 

Promises

We've had promises around for some time now in the form of libraries like Q and When.js, but ES6 finally introduces this concept as a native object. Promises generally resolve the issue of large callback hell style problems like the following:

fs.readdir(source, function(err, files) {
  if (err) {
    console.log('Error finding files: ' + err)
  } else {
    files.forEach(function(filename, fileIndex) {
      console.log(filename)
      gm(source + filename).size(function(err, values) {
        if (err) {
          console.log('Error identifying file size: ' + err)
        } else {
          console.log(filename + ' : ' + values)
          aspect = (values.width / values.height)
          widths.forEach(function(width, widthIndex) {
            height = Math.round(width / aspect)
            console.log('resizing ' + filename + 'to ' + height + 'x' + height)
            this.resize(width, height).write(destination + 'w' + width + '_' + filename, function(err) {
              if (err) console.log('Error writing file: ' + err)
            })
          }.bind(this))
        }
      })
    })
  }
})

Instead, promises let us do awesome things like this:

getSomeData()
.then(filterTheData)
.then(processTheData)
.then(displayTheData);

The ES6 promise constructor and basic usage

function timeout(duration = 0) {
  return new Promise((resolve, reject) => {
    setTimeout(resolve, duration);
  })
}

var p = timeout(1000).then(() => {
  return timeout(2000);
}).then(() => {
  throw new Error("hmm");
}).catch(err => {
  return Promise.all([timeout(100), timeout(200)]);
})

Side note: jQuery has a concept of deferred which is somewhat like a promise but does not properly conform the A+ spec. However, it has a then method which means it can be converted to proper ES6 promise. Be carefull of jQuery passing multiple arguments to resolve and reject.

Block Scope, Let and Constants

To fix Javascript's confusing scope and hoisting rules, ES6 introduces block scope as well as the let and const keywords.

function variableHoist() {
  console.log(hoisty);
  hoisty = 1;  
  console.log(hoisty);
  var hoisty = 2;
  console.log(hoisty);
}
 
variableHoist(); 
//outputs undefined (would get a ReferenceError if no var declaration existed in scope)
//outputs "1"
//outputs "2"

The let keyword effectively replaces var, and const is a new keyword which allows for truely frozen constants enforced by the runtime. 'use strict' helps with some of this, but is not as elegant.

Example of Block Scoping

function f() {
  {
    let x;
    {
      //block scoped constant
      const x = "sneaky";
      // error, assignment to constant
      x = "foo";
    }
    // error, already declared in block
    let x = "inner";
  }
}

Proxies

Proxies enable proper runtime level support for interception, virtualization, logging and profiling. Many test frameworks like (mocha, jasmine, etc.) perform various hacks and work arounds to instrument objects for inspection and mocking purposes. A large chunk of their hacks can now be easily replaced using the new Proxy object. Other uses include live instrumentation of objects while minimally distrupting the object's original functionality and allowing for hooked method logging and profiling.       

let obj = {
  a: 'str',
  b: 123
};

let p = new Proxy(obj, {
  get: (reciever, propName) => {
    console.log(typeof reciever[propName])
  }
});

p.a
//"string"

p.b
//"number"

There's more

let handler = {
  get: function() {},
  set:  function() {},
  has: function() {},
  deleteProperty: function() {},
  apply: function() {},
  construct: function() {},
  getOwnPropertyDescriptor: function() {},
  defineProperty: function() {},
  getPrototypeOf: function() {},
  setPrototypeOf: function() {},
  enumerate: function() {},
  ownKeys: function() {},
  preventExtensions: function() {},
  isExtensible: function() {}
}

Proxies can handle virtually all of the built in terms of interception.

ES7: Object.observe()

Technically speaking, Object.observe is not part of the ES6 spec, however, Google has been making a serious push towards the implementation of this features, even to the point the latest Chrome 37 already has a working .observe() function.

Every self-respecting MVC framework has a notion of an object which can have another object susbcribe to or observe the events that it emits.  Most frameworks go the route of .get() and .set() methods, and simply trigger events manually when changes occur, Angluar being the exception in it's use of dirty checking. 

Both approaches have flaws, get/set being unsemantic, adding overhead, and Angular having to jump through some serious hoops and face performance problems with it's dirty checking method.

Object.observe() addresses all of these issues. 

Observing Objects

var model = {
  prop1: 'str',
  prop2: 123
};

function observerFn(changes) {
  // Do something with changes
  changes.forEach(function(propChange) {
    console.log('Name of property: ', propChange.name);
    console.log('Type of change: ', propChange.type);
    if (propChange.type === 'update')
      console.log('The old value was: ', propChange.oldValue);
  });
}

Object.observe(model, observerFn);

> model.prop1 = 'new string';
//Name of property:  prop1
//Type of change:  update
//The old value was:  str

> delete model.prop2
//Name of property:  prop2
//Type of change:  delete

Object.unobserve(model, observerFn);

//Observing only specific events
Object.observe(model, observerFn, ['delete', 'update']);

var arr = [1,2,3,4,5,6];

function observerFn(changes) {
  console.log(JSON.stringify(changes, null, 2));
}

Array.observe(arr, observerFn);

arr.push(7);
// [
//   {
//     "type": "splice",
//     "object": [ 1, 2, 3, 4, 5, 6, 7 ],
//     "index": 6,
//     "removed": [],
//     "addedCount": 1
//   }
// ]

arr[1] = 18;
// [
//   {
//     "type": "update",
//     "object": [ 1, 18, 3, 4, 5, 6, 7 ],
//     "name": "1",
//     "oldValue": 2
//   }
// ]

delete arr[2];
// [
//   {
//     "type": "delete",
//     "object": [ 1, 18, null, 4, 5, 6, 7 ],
//     "name": "2",
//     "oldValue": 3
//   }
// ]