A Case For Using CoffeeScript

A Case For Using CoffeeScript

If you’re interested in CoffeeScript, then I’m sure by now you have read Ryan Florence’s blog post titled “A Case Against Using CoffeeScript”. In this post, Ryan explains that he uses CoffeeScript at work, and he likes the language, but in his opinion it is too difficult to comprehend and too difficult to debug. My response to this, in the immortal words of Dwight Schrute, “false!”

Before we get started, let me just say that this article is more about disagreeing with some of the statements made in Ryan’s post, its purpose is not to “sell” you on CoffeeScript, but merely point out that CoffeeScript is not something to be scared of. If you want somewhere to show you how awesome CoffeeScript is, I would recommend checking out the official CoffeeScript site and CoffeeScript is for Closers by Brandon Satrom.

Let me start out by saying that I think Ryan is making two completely unrelated assertions in his post:

  1. CoffeeScript is too difficult to debug.
  2. CoffeeScript is too difficult to comprehend.

I feel that the first issue definitely has some validity, but the second really holds no water for me at all.

Too Difficult To Comprehend?

To say that CoffeeScript is too difficult to comprehend seems silly to me. Every language has features in it that, when used poorly, can create horrible unreadable code. If  a developer wants to leverage a language in a way that causes unreadable code, there isn’t a language in existence that will stop them. Just saying that code is “bad” or “unreadable” should be a red flag in most language arguments, since these adjectives are usually a matter of personal preference, but too often delivered as fact.

A big part of his argument revolves around “one liners”. As if CoffeeScript is a horrible language because it allows you to do a lot on one line. And by giving developers this ability (gasp!) they will write horrible code and make terrible choices! I hate to break it to you, many languages give you the ability to do a ton of work in a single unreadable line. Python? Check. Ruby? Double check. C#? With LINQ, absolutely! Java? Can you say “fluent” interfaces? Scala? Absolutely. And unfortunately, I can write some pretty horrible one-liners in JavaScript, especially with everyone’s favorite library jQuery.

Reasonable developers will write reasonable code. Bad developers will screw up any language. I guess CoffeeScript gives developers more chances to write crappy unreadable code than some languages, but I don’t think that JavaScript is one of them.

CoffeeScript’s “Bad” Parts

Yes, CoffeeScript has a few warts. But is its ability to call methods without parentheses a “bad” part? I don’t know, ask a Ruby developer then ask a Java fan (do those exist still? I kid. I kid.). I’m sure you’d get two different answers. Given the example that Ryan had:

dfd = $.ajax
  url: url
  format: 'json'
  method: 'get'

I’m sure that many developers would find that hard to read, while other developers might not be too offended by it. In this case though, CoffeeScript still allows you to put curly braces around the object literal or parentheses around the method call, but does encourage you to be terse. CoffeeScript isn’t perfect, but the alternative is JavaScript, and so I think if we wanted to get into that war, I believe that CoffeeScript would come out on top.

And don’t take that as me saying JavaScript is bad, because it isn’t, it is a great language. What I am saying is that if we want to start comparing which language has more peculiarities, I think that JavaScript would come out on top.

CoffeeScript Is Hard To Debug?

This second part of his argument is one that I think needs a bit more attention, but unfortunately it is the part that he touches on the least. I’ll be completely upfront, I’ve found that CoffeeScript can definitely be more difficult to debug than JavaScript in some cases.

I have run into a few situations where I’ve written a chunk of code in CoffeeScript and I’ve received some very odd messages from the CoffeeScript compiler. This has actually been the biggest source of frustration writing CoffeeScript, is that there are places where ambiguities in the language can be accidentally introduced and you’ll get an error saying something along the lines of “unexpected statement start”. Then you have to hunt down the cause of this error.

As far as CoffeeScript being compiled to JavaScript causing problems with debugging, well, I haven’t been overly encumbered by it. Sure, the more expressive statements in CoffeeScript can generate a fair chunk of JavaScript, but that is precisely the tradeoff for making CoffeeScript more expressive, it is hiding a lot of the work that it is doing behind the scenes. However most of the statements you write in everyday CoffeeScript, with the exception of a few curly braces and semi-colons,  compile almost 1 to 1 with their JavaScript counterparts.

But I think that it is the generated JavaScript that really scares people. They think of a ton of generated JavaScript and they cringe at having to debug it. But I think that it is rarely an issue, for a few different reasons:

  1. CoffeeScript doesn’t rename variables – If I put a watch in my JavaScript debugging tool for a particular variable, then that variable will get inspected, just as if I was using it in JavaScript (because in the end I am!).
  2. CoffeeScript generates mostly readable JavaScript – Despite the big chunk of code that Ryan’s comprehension example produced, I think it is still fairly readable. The example combined a comprehension, string interpolation, a boolean check, and assigned the results to an array. The resulting JavaScript is just a loop with an if statement.
  3. Console.log – I can use console.log in my CoffeeScript in the exact same way I use it in my JavaScript, and it works just fine.
  4. Debugger – I can still write “debugger” into my source and force the browser to break on a line. No, I don’t have to hunt and peck through JavaScript source to find where a line of CoffeeScript compiled to, this jumps me right to it. (If you have never written the “debugger;” statement into your JavaScript, you should try it one day)

What I think the problem really comes down to is tooling. If CoffeeScript was natively supported by the browser, you wouldn’t be asking for tools to view the generated ASTs, you would want a debugger. The fact that I can’t view CoffeeScript in the browser and set a breakpoint and debug at that level is annoying, but it isn’t annoying enough that I want to give up the expressiveness that CoffeeScript provides me.

Why Would I Use It?

Now that I spent all this time telling you that it doesn’t suck, I should probably tell you why you might actually want to use it! On a personal level I think that it has a cleaner syntax. I like its roots in Ruby and Python and reading CoffeeScript feels better to me. But I think the real power lies in its expressiveness.

It gives me features like classes, string interpolation, comprehensions, an existential operator, reasonable “for” loops, chained boolean expressions, everything is a value, predicative boolean expressions, etc… without taking away any of the flexibility and power that JavaScript gives me. For example, it has classes, but they are truly just syntactic sugar on top of JavaScripts prototypical inheritance mechanisms. I can even build up objects using prototypes in CoffeeScript just like I would do in JavaScript.

The list goes on and on. I could write a whole blog post about it, but the CoffeeScript website lays it out for you far better than I ever could.

If It Makes Your Life Better, Use It.

I know there are concerns about whether CoffeeScript will be around in 5 years. And honestly, I don’t know the answer to that question, but its inclusion in Rails 3.1 by default can’t hurt! I know that future versions of JavaScript will be better for CoffeeScript having existed. CoffeeScript is open source, and people today are writing a reasonable amount of code in it. I can’t imagine that in the future the CoffeeScript compiler will just up and die, if anything it will leverage future constructs in JavaScript and you will start to see the languages converge more.

When I want to use a tool, I always look at it and weigh the risks of using the tool versus the benefits. At the end of the day I think that the benefits that CoffeeScript gives me outweigh the risks, if you don’t agree, then don’t use it. But if it makes your life easier, and you’re not risking the farm by using it, then by all means have at it!

More Insights

View All