Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Variable Scoping
One of the worst aspects of JavaScript is the variable scoping. By default, every valid identifier that you reference in JavaScript is treated as a variable in the global scope. To make a variable locally scoped, you must declare it with the var keyword.
CoffeeScript removes the var keyword and implicitly binds all variables to the scope nearest their first use. If you first use a variable inside a function or method, then the variable will be a local.
At first glance, this looks like a great idea. As I've said before, one of the main criteria for judging a language is how little code you need to read to understand what an expression is doing, and by this metric this decision is a disaster.
Consider the following two function bodies in JavaScript:
function a(b)
{
c += b;
...
}
function a(b)
{
var c;
...
c += b;
...
}
In the first, you see that the first use of c in the function is not preceded by var, so you know that it's a global. In the second, you can see that the first use is preceded by var, so you can tell that it is a local.
Now consider a similar function in CoffeeScript. To make the same determination, you need to find the first use of c anywhere in the program. If it is a local, you must scan over the entire body of the code up to this point.
Flow Control
One of the nice things about CoffeeScript is a small modification to the flow control structures. These are now all expressions that evaluate to the result of the last expression that they contain.
This is not a new idea; languages as dissimilar as Smalltalk and Erlang both include this idea. That's not a criticism: I fully approve of stealing good ideas from other languages; it's just a shame that most people seem more willing to steal the bad ones.
JavaScript inherits two forms of conditional from C. One is a statement; the other an expression. For example, you can do a conditional assignment in either of these ways:
if (a)
{
b = c;
}
else
{
b = d;
}
b = a ? c : d;
The second form is fairly common, in spite of being harder to read, because it is considerably more concise. In CoffeeScript, you would use this form instead:
b = if a then c else d
The if statement has become an if expression. If statements in CoffeeScript also gain one syntactic quirk from Perl: They can come at the end of expressions as predicates. For example:
c = b if b > 15
This sort of thing again fails the 'how little code do you have to read' test because, for example, if you know that b is 4, then you still need to read the assignment, and then get to the end and discover that it won't be executed. In contrast, with the condition first, you can skip to the end when you know that the condition won't be met.
Classes
Like Dart, CoffeeScript comes with a class-based object model. Unlike Dart, it's a thin layer on top of the Prototype model of JavaScript, rather than a replacement.
Classes in CoffeeScript use more or less the same syntax as objects: They start with the class keyword and then the class name, and then contain method declarations using the same syntax as methods on objects.
The implementation is quite simple. Each class compiles to a prototype, with all methods attached to it. This prototype inheritance chain is used for class-based inheritance, so you can replace a method on a class by modifying its prototype. For example:
class Example
constructor: (@name) ->
rename: (@name) ->
e = new Example("Old Name");
Example.prototype.rename = (newName) ->
alert(@name + " renamed to " + newName)
@name = newName
e.rename "A new name"
This replaces the method with your own version. In this case, it's just adding some debugging code, but you can make any other modifications that you want. This is also—obviously—possible in JavaScript to do the same, but it's good to see that the class model hasn't lost any of this flexibility.
Overall
JavaScript has some syntactic oddities, but so does CoffeeScript. Most of the savings in terms of lines of code that are quoted comparing JavaScript to CoffeeScript seem to be from removing braces in favor of indentation.
If you have a human visual cortex that has spent the last million years or so developing high-speed paths for detecting and recognizing symmetrical shapes to identify friends and predators, then this is probably not an improvement for you.
Some of the syntactic tweaks are nice, but they're also the kind of saving that makes very little difference in practice. Experienced developers don't think in terms of language syntax; they think in abstract algorithm representations and the translation to concrete syntax happens in the subconscious. Writing -> instead of function() {} may require slightly less typing, but it doesn't require any less thinking, and the typing doesn't distract from the next bit of thinking.
In general, if the typing speed is the bottleneck in your coding, then you either need more practice typing or you need to think more carefully about your code—generally the latter.
That's not to say that CoffeeScript is all bad. Having a standard class model for JavaScript is nice because it seems to be one thing that everyone implements their own version of.
Making all flow control constructs into expressions, however, is something that a lot of languages have done to good effect. There are several syntactic tweaks that I haven't mentioned, such as allowing assignment to ranges in arrays, but even taking these into account it seems that CoffeeScript makes as much in JavaScript worse as it makes better.