Let’s face it, ECMAScript 6 (AKA ES6) is finally here.
And everyone is using it.
Really?
Well, not yet, but everyone definitely wants to, and probably you do too.
It’s good to know that after years of messy coding with almost 100% freedom, your JavaScript code is finally going to look better, and maybe run faster. Think about the enormous amount of best practices you’re already familiar with from other programming languages, now applied on your unorganized JavaScript code. You’ll also have a relatively moderated learning curve, so once you start your transition, it won’t be long until the new syntax will be the main language for your dev team.
This post will cover a few of ECMAScript benefits, what is takes to make the switch into ES6, and problems you might encounter during this process.
The Reason Everyone talks about ES6, And Why You Should Too
Take a look at this code, this is pure JavaScript, and it’s all part of ECMAScript 6. Classes became an integral part of the language and with Classes, we can start using common design patterns we’re already used to.
class Shape { constructor (id, x, y) { this.id = id this.move(x, y)
this.x = x this.y = y } toString () { return `Shape(${this.id})` } }
If it’s not enough to convince you, watch how easily we now inherit a base class and override one of its methods. We can also define a static method which we can call without a specific instance
class Rectangle extends Shape { constructor (id, x, y, width, height) { super(id, x, y) this.width = width this.height = height } toString () { return "Rectangle > " + super.toString() } static defaultRectangle () { return new Rectangle("default", 0, 0, 100, 100) } } class Circle extends Shape { constructor (id, x, y, radius) { super(id, x, y) this.radius = radius } toString () { return "Circle > " + super.toString() } static defaultCircle () { return new Circle("default", 0, 0, 100) } }
We can then call those static references from any context using this code
var defRectangle = Rectangle.defaultRectangle() var defCircle = Circle.defaultCircle()
Of course, those are just a few of the changes made available on ECMAScript 6 (the full list of ECMAScript 6 features or here). ES6 brings many valuable upgrades we should adopt to our code, and the sooner the better. It allows us to support more complex web applications and design them better using architectures we’re already familiar with. Soon, all the major client-side frameworks will implement their libraries using ES6 (many already do), this means all the documentations and code samples will also be in ECMAScript 6. So, the sooner you start switching, the easier it will be for your entire team to make the full transition.
Problems Might Arise When Switching to ES6
Like almost everything which involves browsers, compatibility is something that must be taken seriously. Although ES6 is now a standard, not all browsers have fully finished implementing all its features, so starting to code without preparation will probably break your application.
In order to do the switch safely and keep your app backward compatible, you need to have a plan. This plan involves some infrastructure changes and more libraries you’re going to need, so make sure you have a few extra days to focus on the transition infrastructure, without changing any existing code.
Planning Your Switch
Remember the days when HTML5 and CSS3 were new? We couldn’t wait for the browsers to fully support all those cool new features, and we had to use them. This caused many websites to support some of the features only on certain browsers, “this works only on chrome” was a common sentence back then. When It comes to Javascript, this is not the case, it’s not a cool animation your app can do without, now our unsupported piece of code is a trivial part of our app, which won’t run unless the browser supports ES6.
Using a tool like Modernizr, or any other tool to check if the feature that we want to use is supported, is a bad practice and brings a lot of overhead.
If we want to forget about browser compatibility for good, we need a tool to convert our code into a fully supported one instead.
And this tool is called a Transpiler (translate and compile).
Your 2 Transpilers to Choose From
Points to Consider
- When we transpile our code, it means we generate a completely different source code from our files. The generated code is optimized for performance and not for readability. The debugging process can be a real pain since it’s not our code we personally wrote. In order to connect our written code with the generated code, we need source maps. Just like SASS or LESS compilers generate your output CSS files and the browser inspector tells you on each generated CSS line, which SASS line is mapped to, same goes here. Source maps are basically files used for mapping between your written code and your generated code. Currently, Chrome and Firefox can parse the source maps automatically and make it appear like you’re running the original code. Read my full article about source maps.
- Generating code from existing code could lead to larger source files, despite the efforts you put into your work to write clean, compact and structured code. Remember that those compilers are not JavaScript minifiers, they simply generate an ES5 file from your ES6 files.
Conclusion
ECMAScript 6 is going to revolutionize the way we write web applications.
Although it does seem like a lot of overhead to work with transpilers, it’s only a one-time work you need to take care of. The fact many fundamental libraries we use in production already started to implement the new releases using the new syntax, says it all.
Don’t expect browsers to support such major changes overnight. It didn’t happen with HTML5 and CSS3 and it’s not going to happen here (or with the next ECMAScript). Learn to embrace the change and adopt it gradually into your code.
Cheers