I have been using CoffeeScript for several years now and don’t plan to stop. For me, the big advantage of CoffeeScript is that I find it helps developers write less-buggy code. To list just two examples:
if (someVar) which should really be written as
if (someVar != null) or even
if (typeof someVar !== "undefined" && someVar !== null) if you want to be completely proper. I don’t want all the developers on my team to need to be JS ninjas who remember the latter (or need to remember to use a helper function we write for this purpose).
- CoffeeScript’s significant whitespace makes code easier to read. Strip all those braces and many of those parentheses away, use proper indentation all the time, and your code reveals itself. Easier-to-read code = less-buggy code. It also eliminates bugs caused by a developer writing an if statement without braces, perhaps because at first it was intended to be a one-liner but later it became a block and the developer forgot to add the braces.
You see where I’m going with this. I can imagine a lot of people reading this might scoff at such concerns, that they’re experts and don’t make such newbie mistakes and don’t need the language to handhold them (or anyone else on their team). Well, hooray for you. I think the reality, though, is that we all make stupid mistakes, whether it’s coding late at night or coding while thinking about the problem rather than the syntax we’re typing. CoffeeScript helps cut down on the stupid mistakes.
And there are very few ES2015 features that CoffeeScript lacks. I was chatting with a developer at a meetup recently who was telling me how he switched from CoffeeScript to ES2015 because of the destructuring; he apparently never noticed that CoffeeScript already has destructuring. Many of ES2015’s features, like the fat arrow, are adopted from CoffeeScript. About the only features I can find that CoffeeScript doesn’t support are the new import/export syntax (irrelevant for Meteor, and for other frameworks like Ember you can just wrap your import and export lines in backticks) and tail-call optimization, which I had never heard of before ES2015 came on the scene. You can read someone smarter than me discuss the specific features here. CoffeeScript’s feature set hasn’t changed much in years mainly because it doesn’t have to.
As with anything, it’s a tradeoff. I greatly prefer CoffeeScript’s syntax, and I think it helps my team avoid bugs. I’m fortunate that I have a team that agrees with me; I totally understand the mindset of someone already learning ES2015 and not wanting to learn yet another thing. And I think the risk of limiting your contributors to an open-source project is a real concern (though in that case you might just want to stick to old ES5). At the moment, both CoffeeScript and ES2015 compile down to ES5, and that will be the case for years to come until browser support for ES2015 features is more widespread; but by then, I expect CoffeeScript will compile down to ES2015.