JavaScript


ES 2015


The New Parts


by Andreas Schipplock

Introduction

JavaScript is dead and it successfully reincarnated in the form of ECMAScript 2015. Sometimes it's called ECMAScript 2015, ES6, ECMAScript 6 or ECMA-262 6th edition. This booklet doesn't cover every new addition of ECMA-262 6th edition but the most interesting ones. If you want to read all of ECMA-262 6th edition, you can read the specification:

http://www.ecma-international.org/ecma-262/6.0/


let

The first new notable addition to ES6 is 'let':

(function() {
    console.log(bar);
    { var bar = 'hello'; };
    { var bar = 'world'; };
    console.log(bar);
})();

In this example I have a function with 2 blocks inside where I define and initialize 'bar' with 'hello' and 'world'.

In this case 'bar' is defined with 'var' which tells the JS engine to scope this variable to the nearest function. The JS engine will hoist 'var bar' to the top of the function block.

I can access 'bar' just fine and it will have the value of 'world'. My 'application' will continue to run without a problem though it might cause a bug in the future. 'var'-hoisting really can lead to bugs in the future. Whenever someone adds more code, you will be prone to 'var'-hoisting-related bugs sooner or later.

The example from before but with 'let':

(function() {
    console.log(bar);
    { let bar = 'hello'; };
    { let bar = 'world'; };
    console.log(bar);
})();

In this example I have a function with 2 blocks inside where I define and initialize 'bar' with 'hello' and 'world'.

In this case 'bar'' is defined with 'let' which tells the JS engine to scope this variable only to the nearest block.

JS will not hoist 'bar' to the nearest function here and because 'let' is new I get a nice 'Uncaught ReferenceError' when I try to access this variable outside its block. This is nice because my 'application' will die when I try to access 'bar' in places where it should be inaccessible.

(function(){
    let foo = 'hello';
    let bar = 'world';
    let foo = 'hello world';
})();

When I define a variable with 'let' twice, I will get 'has already been declared'. This is great because I will notice when I try to use a variable with the same name in a big spaghetti code block.

(function() {
    let foo = 'hello';
    let bar = 'world';

    {
        let foo = 'yup, that will work';
        let bar = 'and this as well';
    };

    console.log(foo);
})();

If I want to use the same names in a new block, I can just do it because, well, it's a new block.

That's all you need to know about 'let' right now. It's much better than any automatic and 'invisible' hoisting that 'var' provides. 'let' variables can be changed anytime unlike in some other programming languages.

So 'let' isn't immutable but that's ok. Just use 'let' instead of 'var'. It will provide the expected behaviour though, after some discussions, there are some people who are actually used to the function hoisting 'var' provides. I'm personally aware that even PHP does it though I simply hate it. It's easy to miss so it's even easier to introduce new bugs especially if you aren't the only one adding code. I chose to write 'function()' only to emphasize that we are inside a function. In ES6 you, however, could write '() => {}' instead.


const

'const' isn't really a new addition to ES2015 because it was available many years ago in firefox but now that it's part of ES2015 other web browsers are supporting it as well. I don't have much to say about it. If you use a linter, you probably noticed the hints about 'magic numbers' already and yes, here we can just use 'const'.

Just like 'let' the scope of 'const' will be the nearest block, not the function.

let balance = -300;

console.log((function drawMoney(balance, desired) {
    if ((balance - desired) < -500) {
        return 0;
    }
    return desired;
})(balance, 250));

Here I have a magic number '-500' which actually has no real meaning to the person reading the source. This is bad code but easy to fix.

With a simple 'const' definition I can tell other people what I actually had in mind:

console.log((function drawMoney(balance, desired) {
    const OVERDRAFT_LIMIT = -500;
    const NO_MONEY = 0;

    if ((balance - desired) < OVERDRAFT_LIMIT) {
        return NO_MONEY;
    }

    return desired;
})(balance, 250));

Just like in any other programming language, a constant assignment cannot be re-assigned. Thus the wording:

const foo = 'bar';
foo = 'foobar';

This will throw 'Uncaught TypeError: Assignment to constant variable'. But this is limited to the assignment only.

In some programming and scripting languages you are limited to what you can assign to a constant. In ES2015 you aren't. Assign whatever you want:

const config = {
    host: 'localhost',
    port: 4711
};

However, there's a catch, because the following does work:

config.host = 'some.remote.server';

If you want to force more strictness here (and it might be a useful case), you can force the objects property to be read-only:

const config = (() => {
    let properties = {};

    Object.defineProperty(properties, 'host', {
        value: 'localhost',
        writable: false
    });

    Object.defineProperty(properties, 'port', {
        value: 4711,
        writable: false
    });

    return properties;
})();

You won't be able to change 'config.host'' or 'config.port' anymore but now it looks aweful. However it's better than nothing.

'const' is a good new feature of ES2015 and I like it a lot. It's very useful, can eliminate potential bugs and will make your code a lot easier to reason about.


Defaults

Default parameters in ES2015 are nice because you can create more robust implementations. Let's see an old example that would simply fail.

(function(cars) {
    cars.forEach(function(car) {
        console.log(car);
    });
})(['Audi', 'BMW']);

Actually this will work just fine because I provided the expected type for this function. I provided an array with two elements. It can iterate that and just print out the values.

(function(cars) {
    cars.forEach(function(car) {
        console.log(car);
    });
})();

Now, somehow, I forgot to provide an array and this will simply die with 'cannot read property forEach of undefined'.

(function(cars = []) {
    cars.forEach(function(car) {
        console.log(car);
    });
})();

In ES2015 I can provide defaults for parameters so I can assure that my function will at least run without an error.

Of course I still may check pre-conditions here and the advantage of this construct is that I know what type I have to deal with. I e.g. can call 'length' on 'cars' even though nothing was provided as an argument by the caller.

(function(cars = []) {
    if (cars.length == 0) {
        throw "I expected at least one car :P";
    }

    cars.forEach(function(car) {
        console.log(car);
    });
})();

Here's such an example where the caller doesn't provide any useful argument.

But I, as the callee, can still check on the 'length' of the array though none was passed as an argument.

(function drawMoney({balance, desiredAmount}) {
    console.log(balance);
    console.log(desiredAmount);
})({balance: -300, desiredAmount: 200});

...and because I have some history with Ada I, sometimes, like to have named 'parameters'. In JavaScript you can do whatever you want. The example above just works as expected. The caller, however, needs to know what to provide.

(function drawMoney({balance, desiredAmount}) {
    console.log(balance);
    console.log(desiredAmount);
})();

In this example the caller forgot to provide the expected 'object' as an argument. This will lead to "Uncaught TypeError: Cannot match against 'undefined' or 'null'". Your application will die.

(function drawMoney({balance, desiredAmount} = {}) {
    console.log(balance);
    console.log(desiredAmount);
})();

In ES2015 you can use defaults to prevent your application to exit unexpectedly.

However, in the above example both 'balance' and 'desiredAmount' will be 'undefined'. And I'm not so sure this is useful at all. But let's look at a possible solution.

(function drawMoney({balance, desiredAmount} = {balance: 0, desiredAmount: 0}) {
    console.log(balance);
    console.log(desiredAmount);
})();

Here I provide sane defaults which I could use to implement useful pre-conditional checks. This might be useful in such a limited use-case but in real life applications you often have to deal with quite a bit more arguments or parameters. So this approach might turn into an unreadable mess.

But in ES2015 you have the tools to create a solution for this problem as well and you probably have seen this 'pattern' in other languages as well. Let's have a look:

function Car(properties = {}) {
    let defaults = {
        color: 'white',
        ac: false,
        gearbox: 'auto'
    };

    let configuration = Object.assign({}, defaults, properties);

    return configuration;
}

Here I merge 'properties' with 'defaults' and let Object.assign copy it to a new Object.

This might look odd at first because it's not really a language feature that supports the handling of default arguments or parameters and yes, it's not! because a human being has to read the first few lines of the function body to know what arguments the function expects. This is by far not ideal.

I'm honest here; I liked this approach at first but after I thought about it, I tend to prefer the following solution which is baked into ES2015 and it's called destructuring assignment notation.

(function drawMoney({
    balance,
    desiredAmount
} = {
    balance: 0,
    desiredAmount: 0
}) {
    console.log(balance);
    console.log(desiredAmount);
})({balance: 1, desiredAmount: 2});

This will use '0' and '0' for 'balance' and 'desiredAmount' if you don't provide the expected object as an argument. But there's a catch! And it's an evil catch. ES2015 will try to match your arguments, so if you provide just one of the default 'argument', it won't work anymore.

(function drawMoney({
    balance,
    desiredAmount
} = {
    balance: 0,
    desiredAmount: 0
}) {
    console.log(balance);
    console.log(desiredAmount);
})({balance: 2});

I expected 'balance' to be '2' and 'desiredAmount' to be '0'. But 'balance' is now '2' and 'desiredAmount' is 'undefined'. So this approach is very dangerous. It doesn't look very good either.

So, yeah, I will stick to the 'Object.assign' approach if I have to handle more than a handful of arguments and parameters.

'defaults' are a very nice addition in ES2015. This can prevent a lot of unexpected bugs but in my case it won't save the many pre-conditional checks. Just some of them. It's a step forward though.


Rest And Spread

'rest' parameters in ES2015 can be useful but I'd personally rarely use them. ...foo simply means that you can treat ...foo as an array. But it's not an array. Technically though it is. That's it. the ...foo parameter must always be the last one.

Let me show you an example:

function displayCars(somethingElse, ...cars) {
    cars.forEach(function(car) {
        console.log(car);
    });
}

displayCars('bla', 'Audi', 'BMW');
displayCars('bla', 'Audi', 'BMW', 'Mercedes');
displayCars('bla', 'Audi', 'BMW', 'Mercedes', 'Ford');

The first call will display 'Audi', 'BMW', the second 'Audi', 'BMW', 'Mercedes' and so on.

But now the confusion begins. Let me show you an example call that doesn't raise an error and can't be caught by 'try':

displayCars();

That will simply not print any cars. You might wonder why it won't fail because of the:

cars.forEach

But then again think about that cars is simply an array. But it's not. Here is an example how to call a function with the rest parameter in its function signature with an array of data:

let cars = ['Audi', 'BMW', 'Mercedes'];
displayCars('bla', ...cars);

That will finally work. The three ... are called spread operator in this case. Meeh! let's experiment a bit:

displayCars('bla', cars);

This will print:

    Array [ "Audi", "BMW", "Mercedes" ]

So cars as an argument simply 'destructurises':

Array [ "Audi", "BMW", "Mercedes" ]

into:

    "Audi", "BMW", "Mercedes"

So the function displayCars called like:

    displayCars('bla', ...cars);

is actually called like:

    displayCars('bla', 'Audi', 'BMW', 'Mercedes');

Arrow Functions

When I use callbacks in JavaScript it always feels dirty when I do something like 'var me = this;' to get access to 'this' inside the callback. And it's even prone to errors so that's the reason you can now use a better approach.

It's called 'arrow functions' and you can even shorten your 'jQuery ready' init code with it though it doesn't look too pretty if you ask me.

First I show the old variant:

function IP(elem) {
    return {
        prefix: 'Your IP is: ',
        show: function() {
            let me = this;
            $.getJSON('https://httpbin.org/ip', function(data) {
                $(elem).html(me.prefix + data.origin);
            });
        }
    };
}

Here I have to use the me = this 'hack' to achieve what I need.

Here the new variant using an arrow function:

function IP(elem) {
    return {
        prefix: 'Your IP is: ',
        show: function() {
            $.getJSON('https://httpbin.org/ip', (data) => {
                $(elem).html(this.prefix + data.origin);
            });
        }
    };
}

This is the 'new' variant. I use the arrow function, which is always anonymous, to stay in the same scope as before. This is a simple change but a very effective one. I just love it.

$(() => {
    let ip = new IP($('#ip'));
    ip.show();
});

And I can even simplify the jQuery 'dom ready' code :).

But as always there is at least one catch I came across. I was about to believe that I can replace all function()'s with arrow functions but I was very wrong. The IP function I have still has at least one "function" notation as a value of the 'show' property and while it's technically possible to replace this function() with an arrow function...

function IP(elem) {
    return {
        prefix: 'Your IP is: ',
        show: () => {
            $.getJSON('https://httpbin.org/ip', (data) => {
                $(elem).html(this.prefix + data.origin);
            });
        }
    };
}

However, I will have the problem that the this context isn't what I expected. In this case this will be Window.

So how can we make it sexy again?

function IP(elem) {
    return {
        prefix: 'Your IP is: ',
        show() {
            $.getJSON('https://httpbin.org/ip', (data) => {
                $(elem).html(this.prefix + data.origin);
            });
        }
    };
}

With the short notation of functions inside objects I can have a short representation of what I call 'beautiful' with a 'this' which is what I expect it to be.

That's more or less all you need to know about arrow functions. Use them where you see fit.


For Of

Hurrr...for ... of loops are simple. But combined with generator functions they can turn into something more complex.

The 'old' way:

let makers = ['Audi', 'BMW', 'Mercedes', 'Ford'];

for (let index in makers) {
    console.log(makers[index]);
}

The 'new' way:

for (let maker of makers) {
    console.log(maker);
}

Of course you can do something like this:

makers.forEach((make) => {
    console.log(make);
});

...though you cannot return from this; it will loop all elements; no matter what you do :); you can use .every, or .some, of course...

Or even shorter with an arrow function:

makers.forEach(make => console.log(make));

Iterators With Generators

Assume the following object:

let myCar = {
    color: 'black',
    make: 'BMW',
    model: '3 Series',
    mileage: 89000
};

How would you iterate its properties? Probably like this:

for (let key in myCar) {
    console.log(myCar[key]);
}

You cannot use 'for .. of' here but you can convert your 'object' to be compatible with 'for .. of'.

This way you have full control on how your object is iterated. In case of the previous example you don't have any control on how the client is going to iterate your object. So you implement an iterator and control exactly how your object will react on iterations.

By implementing an iterator you also gain the ability to destructurise your object.

Here's an example:

let mySuperCar = {
    color: 'white',
    make: 'Mini',
    model: 'Cooper S',
    mileage: 4588,
    [Symbol.iterator]: function * () {
        let properties = Object.keys(this);
        for (let property of properties) {
            yield this[property];
        }
    }
};

for (let property of mySuperCar) {
    console.log(property);
}

That's much better. However, I had to use 'function' instead of an arrow function; you have to write 'function * ()', 'function* ()' or 'function *()'.

So with the iterator in place you cannot only iterate it with 'for..of' but you also gain the ability to destructurise your object:

let [ , make] = mySuperCar;
let [ color, , model ] = mySuperCar;
let [ color, make, model, mileage ] = mySuperCar;

...and so on.

But now you probably wonder if the old way to iterate an object still works on your object, right?

Well, I'm sorry but it does :)! Live with it; there is no beautiful way to hide it. You can use Object.defineProperty if you want to enforce tighter control on your properties.


Classes

ES2015 has syntactic sugar for 'classes' and you might think: 'oh great! now I can write java in JavaScript'.

Nope.

class Car {
    constructor(make, model) {
        this.make = make;
        this.model = model;
        this.started = false;
    }

    start() {
        this.started = true;
    }
}

class BMW extends Car {
    constructor(model) {
        super('BMW', model);
    }
}

let bmw = new BMW('3 Series');
bmw.start();
console.log(bmw.started);

...there are still no private, public etc... for member variables. There are ways to hide information but my overall opinion on 'classes' in JavaScript is to better avoid it. I personally prefer a more functional approach to this and JavaScript fits perfectly into it.

This is all you need to know about classes in JavaScript as of now.


Maps

Maps are new in ES2015...imagine a map as a key => value store.

let countryCodes = new Map();
countryCodes.set('uy', 'Uruguay');
countryCodes.set('de', 'Germany');
countryCodes.set('fr', 'France');

This creates a map with 3 entries. I don't have much to say about this:

console.log(countryCodes.get('uy'));

This will print 'Uruguay'. This is simple, right?

Of course you can iterate through 'maps':

for (let [countryCode, countryName] of countryCodes) {
    console.log(`${countryCode} => ${countryName}`);
}

The template string is another new feature of ES2015 which is quite handy.

You can also check if some key exists inside a map:

console.log(countryCodes.has('de'));
console.log(countryCodes.has('us'));

Displays 'true' and 'false'.

And to get rid of an entry, you can delete it:

if (countryCodes.has('fr')) {
    countryCodes.delete('fr');
    console.log(countryCodes.has('fr'));
}

This displays 'false'.


Objects

Object creation got a bit easier in ES2015.

In the past you probably wrote:

function Car(make, model) {
    return {
        make: make,
        model: model,
        isGoodCar: function() {
            return true;
        }
    };
}

Now you can shorten it a bit:

function Car(make, model) {
    return {
        make,
        model,
        isGoodCar() {
            return true;
        }
    };
}

let bmw = new Car('BMW', '3 series');

Destructuring And Cherrypicking

Assume the previous object:

let bmw = new Car('BMW', '3 series');
let {make} = bmw;
let {model, make} = bmw;

This is cherry picking from the object. The order doesn't matter but the name does.

Destructuring arrays also works:

let carMakers = ['Audi', 'BMW', 'Ford', 'Mercedes'];
let [ , b, , ] = carMakers;

'b' contains 'BMW' now.

And if you want all elements but the first:

let [ , ...allOther] = carMakers;

'allOther' now contains:

["BMW", "Ford", "Mercedes"]

Promises

In ES2015 you can make use of 'promises'. This feature is already available for quite some time in modern web browsers but now with ES2015 you can start to count on it.

Promises are like callbacks but with better syntax and better error handling. It's really just that.

In the following example I'm pretending to upload imaginary pictures. The 'upload' function will be asynchronous but when I call it, you will notice that it looks synchronous. As I said, it's just a better way to use callbacks; a much cleaner way if you ask me. It's easier to read.

function upload(pictureName = '') {
    console.log('uploading: ' + pictureName);
    let url = 'https://httpbin.org/delay/3';
    return new Promise((resolve, reject) => {
        let req = new XMLHttpRequest();
        req.open('GET', url);
        req.onload = () => {
            if (req.status == 200) {
                resolve(pictureName);
            } else {
                reject(Error(req.statusText));
            }
        };
        req.onerror = () => {
            reject(Error('request failed for: ' + pictureName));
        };
        req.send();
    });
}

As you can see you need to create a new instance of 'Promise' and you simply have to to tell this promise when your code succeeded:

resolve(pictureName);

or if your code failed:

reject(Error(req.statusText));

The client code:

let pictures = [
    'picture1.jpeg',
    'picture2.jpeg',
    'picture3.jpeg'
];

for (let picture of pictures) {
    upload(picture)
        .then((response) => {
            console.log('uploaded: ' + response);
        })
        .catch((error) => {
            console.log(error);
        });
}

And you might get the following output:

uploading: picture1.jpeg 
uploading: picture2.jpeg 
uploading: picture3.jpeg
uploaded: picture2.jpeg 
uploaded: picture1.jpeg 
uploaded: picture3.jpeg

You might have noticed that the request to upload the pictures are in order (as expected) but the execution of the uploads aren't in order anymore. This is because your code ran asynchronous.

In your implementation, though, it looks like it runs from the top to the bottom which is good as you can reason about the implementation much easier now.

This is a big improvement to the callback hell we were used to before. In practice you will create a lot of functions with 'new Promise' inside and it's not perfect as well but it's at least an improvement.

In ES2017 we will get 'async' and 'await'. But until then you can use promises.


Conclusion

ES2015 brought some useful set of new features to the table and these ones are what I consider worth learning.

If you want to have a complete list of all the language features, try the following link:

http://www.ecma-international.org/ecma-262/6.0/

I hope this text was useful.