In July of this year, a new specification for ECMAScript was finally approved, which marked the biggest update to JavaScript since its first release back in 1997. I’m happy to announce that today, Code School is launching a new ES2015 course for our JavaScript Path, ES2015: The Shape of JavaScript to Come, which teaches some of the most useful changes included on this update.

Some of the new additions include features that have already been adopted by the most popular JavaScript libraries and frameworks. So today, in celebration of our new course launch, I want to take a look at 2 of these features: Promises and Modules.

Promises

A Promise is a new abstraction that allows us to write asynchronous code in an easier way. They’re an alternative to the popular Continuation-Passing Style in JavaScript, where callback functions are passed as arguments for processing the result of asynchronous operations.

Here’s an example of async code using callbacks:

You might notice the first line of each callback function is checking for errors. This is the only way we can catch errors in this cascading style code. If we don’t check for errors this way and an error occurs — for example, on the call to sendNotificationsToServer — then there’s no way to access the error from outside that specific callback function.

Another issue with this code is it can quickly grow to what’s known as callback hell. We’ve all been there before at least once and, as you might remember, it’s not a happy place to be.

Here’s a new version of the previous code, rewritten using Promises.

Much better, right?

Multiple implementations of the Promises/A+ specification have been available through third-party solutions, like Bluebird, Q, and RSVP. Both AngularJS and Ember.js borrowed from some of these libraries in order to provide their own implementations — Angular’s version is based on the Q library, while Ember uses RSVP.

Since Promises are now part of ES2015, we can expect these frameworks to start moving away from third-party solutions and toward using native Promises as soon as most modern browsers have support for it.

Modules

The common solution for modularizing JavaScript code used to rely on sharing global variables. As most developers should be aware, using global variables increases the chances of unexpected side effects and potential naming conflicts.

The lack of a standardized module system in previous versions of JavaScript led to third-party vendors proposing and implementing different solutions. The 2 most popular are AMD (Asynchronous Module Definition) and CommonJS. Despite being able to solve a lot of the issues regarding modules and dependencies, AMD and CommonJS each have their own syntax and can’t be used interchangeably. With the goal of providing a standard for working with modules in JavaScript, ES2015 standardized a module system that is now an intrinsic part of the language.

If you’ve recently worked on apps using Ember or Angular2, for example, the syntax for the new module system should look familiar. Here’s an example of what a router file from an Ember application could look like:

The first 2 lines on this file are responsible for importing existing modules: the Ember module (installed via npm) and the module found under the ./config/environment.js file. The last line exports the newly configured Router object, making it available to the module system. All the code in between is completely trapped inside of this module and does not pollute the global namespace.

Promises and Modules are just 2 of the many new features of ES2015 that have already been adopted by libraries and frameworks since its official release, and there are a lot of other great updates. If you’re ready to rock JavaScript and take your skills to the next level, be sure to play our new ES2015 course, ES2015: The Shape of JavaScript to Come.