There has been an interesting thread on Reddit with the title “DAE [Does Anyone Else] think CoffeeScript is ridiculously overrated?” [via @k33g_org]. This post provides some perspective on that opinion.
CoffeeScript is a modern version of JavaScript: Check out its excellent website for a quick overview of what it looks like.
- Completely new syntax: CoffeeScript comes with its own syntax that looks a lot like Python: it uses indentation instead of braces, parentheses and commas are often optional, etc.
- Improves JavaScript: CoffeeScript helps with many of JavaScript’s more difficult parts – inheritance, shorter function syntax with optional binding of this, etc.
- Compiled to JavaScript, statically. When you write CoffeeScript, there is an extra build step involved, before you can run your web application: you need to compile it to JavaScript. You will thus have to do your debugging in JavaScript, but extra emphasis has been placed on making the generated code as readable as possible. [2]
CoffeeScript is influential:
- Will be part of Rails. CoffeeScript will be shipped with Ruby on Rails 3.1.
- Influences ECMAScript.next. It can be seen as a field test of next-generation JavaScript features and informs the decisions made for ECMAScript.next. Especially Brendan Eich has mentioned it as a source of inspiration.
Caveats:
- Syntax. While I think that there are syntaxes that are prettier than the Java-inspired JavaScript syntax (Smalltalk and Lisp come to mind), it is what we have and it is not so bad that one cannot live with it. I don’t agree with the design choice of choosing a completely different syntax for an advanced version of JavaScript, because you now have to know two syntaxes: CoffeeScript’s for programming and, occasionally, JavaScript’s, for debugging. Obviously, there are people who hate JavaScript’s syntax and/or don’t want to stray too far from their favorite programming language. For those people, this is a feature, not a bug. I would have preferred a more JavaScript-ish approach where upcoming ECMAScript features are compiled to current-day JavaScript. This is what Google Traceur [1] does. Note that if JavaScript had macros, one could retrofit older engines with both new library functionality and new language features.
- Library versus language. Not all features have to be part of the core language. With JavaScript’s higher-order functions (functions/methods whose parameters are functions), libraries can do a lot. The following example shows that the language feature list comprehension is not much more beautiful than Array.prototype.map() plus shorter function syntax. This is CoffeeScript code that produces a list of square numbers:
list = [1, 2, 3, 4, 5]
squares = (Math.sqrt num for num in list)
In JavaScript code (plus shorter function syntax), this looks as follows:
var list = [1, 2, 3, 4, 5];
var squares = list.map((num) -> Math.sqrt(num));
- Not everything is an improvement. We are obviously entering the realm of taste, but I don’t think all of CoffeeScript’s features are an improvement over current-day JavaScript [3]. For example, I like having to declare a variable via the var operator (soon to be replaced by the improved let operator), because it makes it explicit where you start using it and helps with catching typos.
The future:
Related posts:
- Google’s Traceur: compile ECMAScript.next to JavaScript on the fly
- Translating CoffeeScript classes to JavaScript [examines the JavaScript generated by CoffeeScript]
- CoffeeScript versus paren-free JavaScript [I compare the two approaches of syntactically improving JavaScript and rate CoffeeScript’s new language constructs]
- ECMAScript.next: the “TXJS” update by Eich
- SourceMap on Firefox: source debugging for languages compiled to JavaScript