After reading posts about it on here for maybe a year, I recently decided to try it for a small jQuery plugin. I enjoyed it so much that we immediately switched to writing all new code in CoffeeScript and have begun converting existing code as time allows.
The benefits over straight JavaScript are amazing—I’d been writing careful code that drew from the ‘good parts’ mentality and pre-declared all variables, etc. Now I hardly ever have to worry about it.
As I continue to write Rails code I wish I could skip commas in hashes. I didn’t really have an opinion on significant whitespace before (only briefly played with Python) but now I love it. It’s also the first time I’ve used splats, and I was delighted by the brevity it can achieve in combination with the erb-esque interpolation: http://cl.ly/2b371b380g3j071E2g0h
The integration with docco has rewarded my habit of trying to write good documentation. I’ve tried to enforce a policy that any new CS must be documented.
In the meantime, CoffeeScript tries to make debugging easy by compiling to straightforward, readable JS, with meaningful variable names, normal indentation, and all that. Patches to make the output clearer/cleaner for specific bits are always welcome.
To be clear, I think CoffeeScript is an impressive language/abstraction. I just get tired of people selling the Javascript output as always being "straightforward" and "readable".
Beware of what? It does look quite straightforward and readable to me. The JS actually helps me understand the CoffeeScript (note, I have never seen real CoffeeScript code before.) Even the class definitions and destructuring assignment further along are quite comprehensible. I don't even have to qualify that with "for what they do."
The only difference from a "hand-written" loop is that you would use `i` and `ln` instead of `_i` and `_len`, and something in context like `numbers` instead of `_results`.
There are a total of 9 references to the `_vars`. I think line noise in the compiled javascript is a legitimate counter argument to the claim that its strait forward and readable.
12 if you count the declaration. You'd have exactly the same doing it yourself, you can at most reduce it to 10 by declaring i and ln inside for().
You're also overlooking the fact that this can be considered an advantage: variable naming for these transient uses is very consistent. When writing JS you could have names all over, even a different one for every loop.
I've maintained the hoisted index variable and cached the length:
var i, foods = ['toast', 'cheese', 'wine'], foods_length = foods.length;
for (i = 0; i < foods_length; i++) {
eat(food[i]);
}
Prefixing variables with an underscore is not an advantage in readability because it lends nothing to the description of what the variable represents. Its another glyph that you have to visually parse before reaching possible meaning.
The reason why all declarations happen at the top of the current function body, instead of inline with the first assignment is because in JavaScript assignment is a statement, not an expression. You can't do this:
alert(var one = 2);
In CoffeeScript, (nearly) everything is an expression. So you need to be able to do this:
alert one = 2
By pushing up all the var declarations, all assignments can be themselves assigned, returned, or passed as arguments to function calls directly.
Aren't local variables scoped to be visible within the entire JavaScript function? I thought the recommendation to declare local variables at the top the function was a reminder (or to avoid accidental importing of global variables of the same name)?
I use coffeescript both clientside and serverside (node). Since semantically the coffeescript maps to javascript almost one-to-one, the only debugging difficulty is mapping line numbers in the error output to the location in the coffee file.
Client-side is zero problem because the chrome and firebug developer tools jump you right to the line in the JS file, and you can figure out where the error is there since the compiled coffeescript is very readable.
Server-side has a slight hassle since there's no clickable link, so the line numbers don't help much, but a quick look at the stack trace makes it pretty easy to find where in the coffeescript its referring to.
I might take this back later, but so far, not really. I thought it was going to be, I keep expecting to run into crazy debugging hurdles, but they just haven't showed up yet. Maybe I'm still at a naive point in my development, and just haven't done anything that would trip it up, but so far so good.
Hasn’t been so far. We’re using the barista gem, which dumps to a JS file.
Most of the problems we’ve dealt with have been due to using new syntax, figuring out when we need parentheses/how to pass anonymous functions, and so on.
Referring to the compiled output definitely helps, but we’re pretty familiar with JS at this point. Not sure how difficult it would be for those with less experience.
The benefits over straight JavaScript are amazing—I’d been writing careful code that drew from the ‘good parts’ mentality and pre-declared all variables, etc. Now I hardly ever have to worry about it.
As I continue to write Rails code I wish I could skip commas in hashes. I didn’t really have an opinion on significant whitespace before (only briefly played with Python) but now I love it. It’s also the first time I’ve used splats, and I was delighted by the brevity it can achieve in combination with the erb-esque interpolation: http://cl.ly/2b371b380g3j071E2g0h
The integration with docco has rewarded my habit of trying to write good documentation. I’ve tried to enforce a policy that any new CS must be documented.