I’ve been coding in CoffeeScript for more than two years and have found it boosts my productivity significantly. Writing CoffeeScript allows me to write cleaner code with fewer errors, and debugging is a breeze thanks to source map support.

Lately, I’ve been experimenting with ES6 using Babel and I must say, I’m quite impressed. In this article, I’ll share my insights on ES6 from the viewpoint of someone transitioning from CoffeeScript, focusing on its strengths and what I believe it still lacks.

Syntactically Significant Indentation: Friend or Foe?

My relationship with CoffeeScript’s syntactically significant indentation has been somewhat complicated. When it works seamlessly, it feels incredibly efficient, offering a minimalistic syntax. However, encountering bugs due to incorrect indentation (which does happen) can be frustrating, making the advantages seem less appealing.

1
2
3

 if iWriteCoffeeScript
   if iAmNotCareful
      badThings = 'happen'

These issues often arise when dealing with nested statements within a code block, where accidental indentation of a statement can lead to problems. Fatigue can play a role, but I believe such errors are more frequent in CoffeeScript.

Initially, when I began using ES6, I wasn’t sure how I’d feel about the change. Surprisingly, it felt incredibly natural to revert to using curly braces. Modern editors enhance the experience by automatically closing braces, further simplifying the process. This shift felt like stepping into a familiar and organized world compared to the perceived “magic” of CoffeeScript.

1
2
3
4
5

if (iWriteES6) {
  if (iWriteNestedStatements) {
     let badThings = 'are less likely to happen'
  }
}

Personally, I advocate for eliminating semicolons. I believe that if they’re not essential, they should be removed. I find them aesthetically unpleasing and an unnecessary typing burden.

Class Support

ES6’s class support is truly remarkable, offering a familiar experience for those transitioning from CoffeeScript. Let’s compare their syntax with a simple example:

ES6 Class

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

class Animal {
  constructor(numberOfLegs) {
    this.numberOfLegs = numberOfLegs
  }
  toString() {
    return `I am an animal with ${this.numberOfLegs} legs`
  }
}

class Monkey extends Animal {
  constructor(bananas) {
    super(2)
    this.bananas = bananas
  }
  toString() {
    let superString = super.toString()
      .replace(/an animal/, 'a monkey')
    return `${superString} and ${this.bananas} bananas`
  }
}

CoffeeScript Class

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

class Animal
  constructor: (@numberOfLegs) ->

  toString: ->
    "I am an animal with #{@numberOfLegs} legs"

class Monkey extends Animal
   constructor: (@numberOfBananas) ->
     super(2)

   toString: ->
     superString = super.toString()
       .replace(/an animal/, 'a monkey')
     "#{superString} and #{@numberOfLegs} bananas"

Initial Thoughts

One noticeable difference is that ES6 remains more verbose compared to CoffeeScript. CoffeeScript’s support for automatic assignment of instance variables within the constructor is a convenient feature:

1

constructor: (@numberOfLegs) ->

This translates to the following in ES6:

1
2
3

 constructor(numberOfLegs) {
    this.numberOfLegs = numberOfLegs
 }

While not a major issue, this more explicit syntax in ES6 enhances readability. Another minor omission is the absence of the @ shortcut for this, a feature I enjoyed from my Ruby experience, though not a significant drawback. Overall, the experience feels comfortable, and I find myself preferring the ES6 syntax for defining methods.

Supercharged with Super

There’s a slight difference in how super is handled in ES6. CoffeeScript adopts the Ruby approach (“send a message to the superclass method with the same name”), while ES6 only permits a “naked” super within the constructor, following a more traditional Java-like approach where super refers to the superclass instance.

The Return of Return

CoffeeScript allows implicit returns for concise code like:

1
2
3
4
5

foo = ->
  if Math.random() > 0.5
    if Math.random() > 0.5
      if Math.random() > 0.5
        "foo"

However, there’s a small chance of getting “foo” back when calling foo(). ES6 enforces explicit returns using the return keyword:

1
2
3
4
5
6
7
8
9

const foo = () => {
  if (Math.random() > 0.5 ) {
    if (Math.random() > 0.5 ) {
      if (Math.random() > 0.5 ) {
        return "foo"
      }
    }
  }
}  

While generally beneficial, I still occasionally forget to include it, resulting in unexpected undefined returns. One exception is with Arrow Functions, which provide implicit returns for single-line statements:

1

array.map( x => x * 10 )

This can be useful but slightly confusing, as adding curly braces necessitates the use of return:

1
2
3

array.map( x => {
  return x * 10
})

However, the logic remains consistent: using curly braces implies multiple lines, making it essential to clearly indicate the return value.

ES6 Class Syntax Enhancements

While CoffeeScript offers some syntactical conveniences for defining classes, ES6 also introduces its own set of useful features.

Getters and Setters

ES6 provides robust support for encapsulation through getters and setters, as demonstrated below:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

class BananaStore {
  constructor() {
    this._bananas = []
  }
  populate() {
    // fetch our bananas from the backend here
  }
  get bananas() {
    return this._bananas.filter( banana => banana.isRipe )
  }
  set bananas(bananas) {
    if (bananas.length > 100) {
      throw `Wow ${bananas.length} is a lot of bananas!`
    }
    this._bananas = bananas
  }
}

The getter ensures that accessing bananaStore.bananas only returns ripe bananas. This is a significant improvement over CoffeeScript, where achieving similar functionality would require a getter method like bananaStore.getBananas(). ES6’s approach aligns with typical JavaScript property access, enhancing consistency and readability.

Setters are equally valuable, allowing data cleaning or exception handling for invalid input. This will be familiar to those with a Ruby background.

However, excessive use of getters and setters is discouraged. Use them strategically when encapsulation provides tangible benefits. For instance, directly exposing a simple boolean property like isEditable might be more efficient if it doesn’t compromise anything.

Static Methods

ES6 supports static methods, enabling the following unconventional approach:

1
2
3
4
5

class Foo {  
  static new() {
    return new this
  }
}

While purists might disapprove due to new being a reserved word, this works in modern environments. However, it’s not recommended for production code!

Unfortunately, the lack of support for static properties in ES6 requires workarounds for defining class constants, which can be cumbersome:

1
2
3
4
5
6

class Foo {
  static imgPath() {
    return `${this.ROOT_PATH}/img`
  }
}
Foo.ROOT_PATH = '/foo'

A ES7 Proposal aims to implement declarative instance and class properties for a more elegant solution:

1
2
3
4
5
6

class Foo {
  static ROOT_PATH = '/foo'
  static imgPath() {
    return `${this.ROOT_PATH}/img`
  }
}

CoffeeScript already handles this gracefully:

1
2
3
4
5

class Foo
   @ROOT_PATH: '/foo'

   @imgPath: ->
     @ROOT_PATH

String Interpolation: Finally Here!

JavaScript finally embraces string interpolation!

1

`I am so happy that in the year ${new Date().getFullYear()} we can interpolate strings`

Coming from CoffeeScript/Ruby, this syntax might feel somewhat odd. My Ruby background, where backticks execute system commands, initially made it feel unusual. The use of the dollar sign might seem slightly dated as well, but that could be subjective.

The chosen syntax was likely influenced by backward compatibility constraints, preventing the implementation of CoffeeScript-style interpolation. "What a #{expletive} shame".

Arrow Functions: Concise and Lexically Scoped

Arrow functions are a given in CoffeeScript, and ES6 closely mirrors their syntax. This provides a concise syntax and lexically scoped this, eliminating the need for workarounds required in ES5:

1
2
3
4

var that = this
doSomethingAsync().then( function(res) {
  that.foo(res)
})

The ES6 equivalent is cleaner:

1
2
3

doSomethingAsync().then( res => {
  this.foo(res)
})

Notice the omission of parentheses around the unary callback, a welcome change!

Enhanced Object Literals

ES6 introduces significant improvements to object literals, expanding their capabilities.

Dynamic Property Names

CoffeeScript 1.9.1 introduced a convenient way to define dynamic property names:

1
2

dynamicProperty = 'foo'
obj = {"#{dynamicProperty}": 'bar'}

This is a vast improvement over previous workarounds:

1
2
3

dynamicProperty = 'foo'
obj = {}
obj[dynamicProperty] = 'bar'

ES6 offers an alternative syntax, which, while not groundbreaking, is still quite nice:

1
2

let dynamicProperty = 'foo'
let obj = { [dynamicProperty]: 'bar' }

Nifty Shortcuts

Borrowed from CoffeeScript, this handy feature might be unfamiliar to some:

1
2
3

let foo = 'foo'
let bar = 'bar'
let obj = { foo, bar }

The obj now contains { foo: 'foo', bar: 'bar' }, a useful shortcut worth remembering.

Class-like Capabilities

Object literals in ES6 can now perform many class-like actions, including:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

let obj = {
  _foo: 'foo',
  get foo() {
    return this._foo
  },
  set foo(str) {
     this._foo = str
  },
  isFoo() {
     return this.foo === 'foo'
  }
}

While its practicality might be debatable, it highlights the expanded capabilities of object literals. However, defining static methods remains exclusive to classes.

For-Loops: A Potential Source of Confusion

ES6’s for-loop syntax might cause some initial confusion for CoffeeScript users due to the reversed meaning of for-of and for-in:

ES6

1
2
3
4
5
6

for (let i of [1, 2, 3]) {
  console.log(i)
}
// 1
// 2
// 3

CoffeeScript

1
2
3
4
5

for i of [1, 2, 3]
  console.log(i)
# 0
# 1
# 2

Should You Make the Switch to ES6?

I’m currently engaged in a large Node.js project using 100% CoffeeScript and remain satisfied with its productivity. The only feature I envy in ES6 is getters and setters.

However, using ES6 today still has its challenges. While the latest Node.js version provides near-complete ES6 features support, older versions and browser compatibility remain less ideal. Using Babel is an option but requires integration into your workflow.

Despite these hurdles, I anticipate ES6 gaining significant traction in the coming years, with even more exciting developments in ES7.

What excites me most about ES6 is how it elevates “plain old JavaScript” to a level of user-friendliness and power comparable to CoffeeScript. This is fantastic news for JavaScript developers, as ES6 breathes new life and excitement into the language.