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:
- CoffeeScript is too difficult to debug.
- 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.
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'
CoffeeScript Is Hard To Debug?
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.
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.
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.
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!
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
Compelling article. While I hadn’t read Ryan’s article, after seeing a few articles by Rob Conery on CoffeeScript I just didn’t see a good enough reason to use it and I figured it would be a bit challenging to debug.
On another note, do you use CoffeeScript when writing Backbone.js apps? I’m working on my third Backbone app and I am finding it challenging enough debugging as it is without throwing CoffeeScript into the mix. Perhaps it’s not as big a deal as I think it it?
If you have some time I’d love to chat about how you structured your Backbone code when coding the Epic Win site. You can reach me on Twitter, @JustinBezanson.
One way I like to compare languages is by reference to a hypothetical language, L.
Imagine that L represents the best possible world for a developer, one in which every statement is clean, expressive, and clear. In L, making software do what you want is simply a matter of knowing what you want to do. By definition, you are maximally productive when using L, so long as you never make a typo and you know in advance what you want to do.
Now, compare L to a language at hand (say, P), and note the productivity differences:
* How much does P “raise the floor”? That is, how much productivity does P provide in the form of preventing errors (e.g. type checking, checking compile-time expressions for overflow, etc.)?
* How much does it “lower the ceiling”? That is, how much productivity does it subtract in the form of making you do extra work, provide XML manifest files, be more declarative than usual, etc.?
Then the best languages are ones that raise the floor as much as possible without lowering the ceiling. Languages that do that can catch a lot of silly mistakes, and they can help mediocre developers do just as well as productive developers.
Unfortunately, the reality is that languages that raise the floor a great deal often do so at the expense of lowering the ceiling. Java can be an enormous win over C++ for typical business applications, for example, but it cripples the productivity of your best developers. If you’ve ever worked in C# or Ruby, it feels like cutting through butter; working in Java feels like cutting through molasses.
In the more mature members of these languages, you typically find replacements for the lost productivity in the form of file templates/macros that you can use to start a new idea. Those are helpful, but they’re a band-aid and don’t address the real solution, which is to improve the language itself.
You didn’t address in the article, but a big part of the reason you see a lot of vitriol about CoffeeScript is that some people think it’s better to focus on improving JS rather than on inventing a whole new programming language. With JS, there are some very obvious behaviors that could be eliminated (sometimes at the expense of backwards compatibility). These would raise the ceiling without lowering the floor, and make JS a much bigger win than it is now.
There are also some very smart people working on this already (see: JS.next, ES.next, etc.). So, why not use that as a starting point, instead of saying “well, it’s a lost cause; onto a new language, everybody!”? Imagine if everybody gave up C# 1.0 because it didn’t have generics, or Ruby 1.0 because it didn’t have mixins; you wouldn’t have anything near what we have today.
My article was mostly a rant for my co-workers that struck a chord I guess, I’m really not the “anti-coffeescript” guy.
I think that’s what my article is about.
I don’t want “mostly”. My point was that it takes an extra brain cycle (though small) to get over this “mostly”.
> I think it is still fairly readable.
Again, I don’t want fairly. I want to debug EXACTLY what I or the original author wrote, and save the extra brain cycle shuffling between languages. I admit its minor, but so is are mosquito bites, and they are irritating.
I mentioned “I’m back to putting in console.log statements”. So, yes, my debugging has regressed to what is normal for you (I guess).
> I can still write “debugger” into my source and force the browser to break on a line.
Only in some browsers.
> The fact that I can’t view CoffeeScript in the browser and set a breakpoint and debug at that level is annoying
My point exactly. When I get a ticket with a bug, or I find one in my own code, I like to stay in the browser until I know what the deal is. It’s MUCH faster than switching between my editor and browser and refreshing and recompiling, etc. etc.
> there are places where ambiguities in the language can be accidentally introduced
So essentially you just rewrote my article 😛
The intro of my article said I just had some beefs to get off my chest, but that I _like_ writing CoffeeScript.
If I were debugging the CoffeeScript directly the language features wouldn’t bother me so much either, you just need a good style guide and adhere to it.
It’s unfortunate I went off on a tangent with the syntax, my real beef is debugging, but I’ve since learned from the comments section of my post that real engineers don’t have to debug, they just write specs that pass the first time in every browser.
@Kyle: For the record, I use CoffeeScript and think it’s a fine language. I’m just pointing out that the criticisms that were addressed in the article are somewhat deeper and more substantial than just “oh, the syntax is annoying” or “bad developers can write really dangerous code with CS”.
And yes, Dart is a silly answer to this problem.
Thanks for the article, I found it very informative.
I’ve used CoffeeScript for some small/personal applications.
Before using CoffeeScript, things like “this” binding, extend, etc were difficult for me to understand, coming from a Python/C# background.
It didn’t take me very long to love CoffeeScript. About the only thing I don’t like about CoffeeScript is that, like virtually all languages, it’s formed some pretty opinionated cults on both sides. You don’t have to like it. At the same time, liking or not liking it doesn’t make you a good or bad programmer. It’s a matter of taste and preference.
As a regular Ruby coder, I love CoffeeScript. It actually requires LESS context switching for me because the syntax and idioms are similar to my main language.
I have yet to have a serious debugging issue. When native debuggers are available (and it looks like they’re coming) I’ll be a lot happier, but thus far the amount of time saved using “for own” more than makes up for the minor inconvenience caused by the current state of debugging.
I really, really like CoffeeScript. I would have preferred “end” to close blocks rather than relevant whitespace but again, this is purely a matter of taste.
So, let me apologize in advance for a shameless plug, but I believe it’s on topic.
The hardest thing about dealing with CS and JS simultaneously is that CS doesn’t generate source maps to begin with, so even if the browsers themselves had better support for compile-to-JS languages, CS would still be behind. This is mostly being addressed via the epic Issue 558 in github. Various patches have been proposed, but there’s a bit of a chicken/egg dance going on, since the browsers don’t yet support source maps (although they’re close, too!).
I decided to just build my own tooling until the compiler catches up. Given a .coffee file and a .js file, it’s pretty easy to reverse engineer the transcompilations, at least enough of them to get down to small chunks of code (think 20 lines or less). Here is the tool that I wrote:
It’s an interim solution for viewing all the .coffee files in your project, and you can see the .js files side by side. Even though it’s a bit of a stopgap, I think the overall tool will be useful even as CS/browsers start upgrading their tooling.
Thanks for the excellent article.
Awesome! I will definitely have to check that out.
I’m not an expert on js, not even close, but it seems like CoffeeScript is writing JS in a classical sense and not the prototypical ?
Leave a comment