Why You Should Be Writing ECMA Script 6 Now

If you are reading this article then you have probably at least heard of ECMA Script 6, the next version of JavaScript, and are curious about what it means for you or your organization. You might be wondering how ES6 is different, if it will affect your existing applications, or if it will affect your ability to write new ones that make heavy use of JavaScript.

Those are valid concerns, however, there is another reason to care about ES6 right now that simply isn’t on most people’s radar.

I’ll get to that.

How is ES6 different?

The jump from ECMA Script 3 to ECMA Script 5 brought with it some very nice features to JavaScript, but It wasn’t revolutionary. There was a deliberate effort not to introduce any new syntax into the language. It was a pretty natural progression from 3 to 5 if you were a developer.

ES6 is different because it introduces new syntax. A lot of new syntax in fact.

These changes are a very welcome, and very needed update to the language that will help to meet the demands of ever larger and more complex applications written in JavaScript. However… writing ECMA Script 6 will be fundamentally different than all previous versions before it.

Don’t believe me? Just look at these two code samples and see for yourself.

Here is a traditional module and class as defined in ECMA Script 5:

//Module and class in ES5
var MyModule;
(function(MyModule){

function Person(name) {
    this.getName = function () {
      return name;
    };
  }

Person.prototype.sayHello = function sayHello() {
    console.log("My name is " + this.getName());
  };

var version = '1.0';

MyModule.getVersion = function(){
    return version;
  };

}(MyModule || (MyModule = {})));

And here is the same thing written in ECMA Script 6:

//Module and class in ES6
export class Person{
  constructor(name){
    this.getName = () =>; name;
  }

sayHello(){
    console.log('My name is ' + this.getName());
  }
}

var getVersion = () =>; version;

export {getVersion}

//Later on, in another file...
import * as MyModule from 'myModule'

That’s more than just a little different, and we haven’t even scratched the surface of new features available in ES6.

How soon is this going to happen… really?

Soon. Very soon actually.

The draft proposal for ECMA Script 6 should be finalized in the next couple of months. And while you might be thinking it will still be a long time before browsers fully support the new spec… you would be wrong.

In fact, at the time of writing the major desktop browsers all support large chunks of the spec already:

1. IE Technical Preview – 70%

1. FireFox 37 – 69%
2. Chrome 41 – 48%

And yes you read that correctly. IE Technical Preview is leading the charge with 70% of ES6 features supported. Crazy right?

What about my existing apps?

The good news is that your current applications will continue to work just fine. This isn’t like upgrading to a new version of the .Net runtime, or JVM.

Browsers will continue to support previous versions of the ECMA Script syntax because unlike racy celebrity photos, it really would break the internet.

So why should I care?

There are a number of really great language-centric reasons to start writing ES6 now, but there isn’t enough room in a single blog post to enumerate them, or go into the nuances of how they will make your life better.

No, the primary reason you should start writing ECMA Script 6 right now, is because the primary drivers of change and innovation in our industry are already doing it!

Hear me out.

The argument isn’t “all the cool kids are doing it.”

The argument is that a large number of the top libraries people use to build applications these days are all going to be written in ES6 in the near future.

That means that the language and concepts that they use to write and speak about will all conform to this brave new incarnation of JavaScript. All the examples and documentation are going to start to revolve around ES6, and if you aren’t familiar with it, then you will be at a severe disadvantage when trying to do anything new.

As an example, Ember.js 2.0 is going to fully embrace ES6 modules, and Angular 2.0 is literally being written in a superset of ES6 called AtScript.

How do I write in a language that isn’t fully supported yet?

The good news is there are a lot of really smart people who have mostly solved this problem already using what are known as transpilers. They allow you to write ES6 code and then compile it into ES5 or even ES3 compatible JavaScript to be used in older browsers.

Google’s Traceur compiler and 6to5 are the most feature complete transpilers on the market today.

Google’s AtScript and Microsoft’s TypeScript are slightly different beasts because they are supersets of the language, adding type checking and annotations that can be used to further improve tooling support and maintainability. At the end of the day, they can also be used to compile down to ES5 compatible code.

Wintellect has used TypeScript on large scale Angular applications with great success, and I am looking forward to seeing how AtScript improves the developer experience working in Angular.

Conclusion

ECMA Script 6 is going to be here any day, and more and more of the production libraries and frameworks we use to create our applications are going to be written using this new version of JavaScript. Instead of waiting on the sidelines, we can start using ES6 now with the help of transpilers, and enjoy many of the benefits without worrying about browser compatibility.

So what are you waiting for?

Start writing the future… today!