Debugging is mostly Easy
Consider this CoffeeScript code, where we use splats:
do keyword in CoffeeScript which allows you to create a closure and immediately invoke it.
So for this CoffeeScript code:
Take a look at this contrived example:
CoffeeScript solves both of those problems very elegantly; all your variables are declared with
var automatically, meaning they aren’t in the global
window scope in the browser. Moreover, CoffeeScript automatically wraps all your code in a closure
So when you write CoffeeScript like this:
Overall, I believe that tools that enforce programmers to write code with less bugs without requiring any effort on the programmer’s part a good thing and CoffeeScript fits that description pretty nicely. I simply wrote the logic of my program and CoffeeScript automatically made it better.
While this is not a big issue when you are the only person working on the codebase, when someone without prior CoffeeScript experience has to work with your code, or when you have to look at other people’s CoffeeScript code, it does add some friction. And since CoffeeScript syntax is very terse and this terseness seems to be encourages in the community, somewhat past my comfort zone, it becomes an issue.
For example, this is a pretty standard way to write a basic
Something like this becomes surprisingly hard or at least not particularly clear in CoffeeScript as the community seems to be trying to optimize not for clarity of code but actually the minimum number of keystrokes, as if it is a metric that matters to anyone. Take a look this StackOverflow question and the provided answers. While I believe this is mostly a faliure of documentation, it’s still an issue that using CoffeeScript introduces
Morevoer, as CoffeeScript does not have a formally defined grammer but is a product of the venerable Jeremy Ashkenas (and the contributors), you are bound to run into edge cases of the grammer where things seem to somehow work but to only break with a new version of the language.
What would you expect to happen with this following CoffeeScript code:
Well, depends on the language of the CoffeeScript compiler you are using, turns out as the language is still being defined.
Although, according to the language creator (and yours truly), it should more reasonably compile to:
The difference subtle in character count but is huge in functionality. And if you think this is a contrived example, it’s not. This is a regression (in some loosely defined terms) that was introduced in the 1.5.0 version of the compiler that broke many people’s apps, as is obvious from this Github issue.
Of course, this would never happen to you, the responsible developer who tests every single of their front-end code and never updates any component without proper testing. Joking aside, while this single update conveniently broke many people’s Express apps in obvious ways, that’s not a chance you can take with every single line of your code. In other words, while a minuscule possibility, it is possible to introduce a bug that would manifest itself in more subtle ways just because a new version of CoffeeScript decides to compile your uber-terse code in a different way now.
Back to the Future
Take a look at this CoffeeScript:
Whereas this CoffeeScript:
So, for those watching at home, you might realize that CoffeeScript has its own version of a
for ... of ... loop that it translates to a
for ... of ... struct.
So now, as a CoffeeScript developer, you have to both remember how your
Similarly, Harmony might also introduce a new
rest syntax that is slightly similar to how CoffeeScript uses the
So this CoffeeScript:
Aside from the fact that I am personally not a fan of using
That Whole Compilation Thing
One of the greatest tenets of the web development is that there’s essentially no compilation step; for the most part you can simply just change lines of code and refresh the page and voila, it’s live. In fact, nowadays, it’s not even uncommon to see web developers directly working in the browser as Chrome practically provides a relatively usable editor inside the browser, it even supports changing your code in runtime.
So, with CoffeeScript, especially if you are developing a static site, you somehow have to introduce a bunch of new tools to get that “refresh-and-go” feeling you so like. Of course, this is all pretty easy for a developer worth its salt (I personally simply do a
watch with a 1 second refresh) but that is of course just one piece of the puzzle.
None of these are complex steps but they are steps nonetheless that you should take into account.
Should you use CoffeeScript?
I admittedly mostly touched on the pain points of CoffeeScript and that is because most of the time, things just work and there is very little to think or write about. CoffeeScript is really a beautiful language with an almost adorable syntax that gets out of your way and works in expectedly pleasant ways with its destructing and optional parameters.
At this point, I also need to mention that just like any other community, CoffeeScript community mostly takes form of the personality of its creator, Jeremy Ashkenas. And you should relieved to know that Mr.Ashkenas simply is a true gentleman who cares about his craft as well as the people who use his tools.
While software engineering might look like the ultimate objective industry where you can make every single decision rationally (“hey, we are dealing with zeros and ones and they are numbers and numbers are the cornerstones of objectivity!”), the truth is far from it.
In the end, the decision is yours. I’ll leave it with three simple questions that you should ask yourself (and your co-workers) about using CoffeeScript on a big code base.
- Are you more productive using it?
- Does it lead to a more managable codebase?
- Does it lead to a smaller number of bugs?