CoffeeScript Quirks

CoffeeScript Quirks

CoffeeScript is a solution without the problem.

— Unknown ironic source.

CoffeeScript is awesome, until it’s totally confusing, and it’s illogical, which can lead to unexpected and subtle bugs. If you’re one of the CoffeeScript haters please skip this post; for others, I’ll share a few notes on the CS quirks that I’ve observed.

For example, let’s say we have a counter and need to assign a value of index subtracted by one to it:

numberOfRadios = index -1

But the line above is not the same as:

numberOfRadios = index - 1

Did you notice that there’s a space after the minus sign in the second example? It took me awhile to track down this type of bug. The reason for this behavior is that the first line will be converted by the compiler to the function invocation and that is probably not what you wanted.

Try the minus one snippet on It outputs the following JavaScript code:

var numberOfRadios;

numberOfRadios = index(-1);

numberOfRadios = index - 1;

Another pitfall, that leads to writing despondently inconsistent code (by us developers), is caused by the fact that parentheses are optional for function calls.

This example involves if conditions in which we want to compare the value of the expression model.get() or the operand typeof to some strings:

a() if @model.get 'groupType' is 'radioGroupTabs'
a() if typeof @model.get 'condition' is 'function'

CoffeeScript is treating the entire thing as an argument and the results are pathetic. Duh. ;-( Here is the native JavaScript code:

if (this.model.get('groupType' === 'radioGroupTabs')) {

if (typeof this.model.get('condition' === 'function')) {

Placing parens over the function still does us no good. Look at this CoffeeScript code:

a() if @model.get ('groupType') is 'radioGroupTabs'

And its JavaScript output:

if (this.model.get('groupType' === 'radioGroupTabs')) {

The workaround involves using () around function calls, or flipping the order in the if statement so that the function invocation is the last bit of code in the if statement:

a() if (typeof @model.get 'condition') is 'function'
a() if 'function' is typeof @model.get 'condition'
a() if (@model.get 'groupType') is 'radioGroupTabs'
a() if 'radioGroupTabs' is  @model.get ('groupType')

The code above compiles to what we wanted originally:

if ((typeof this.model.get('condition')) === 'function') {

if ('function' === typeof this.model.get('condition')) {

if ((this.model.get('groupType')) === 'radioGroupTabs') {

if ('radioGroupTabs' === this.model.get('groupType')) {

Is it all good now? Not really, because I personally think this approach leads to inconsistencies: parts of CoffeeScript code that must have parentheses, while in other places they are optional.


Reading blog posts is good, but watching video courses is even better because they are more engaging.

A lot of developers complained that there is a lack of affordable quality video material on Node. It's distracting to watch to YouTube videos and insane to pay $500 for a Node video course!

Go check out Node University which has FREE video courses on Node:

[End of sidenote]

Try these if conditon snippets yourself on

The next note explains the most common beginner’s mistake in CoffeeScript; that is to use an a instead of an a() for function calls. However, super inside of a class, must be called without parentheses in order to pass the arguments to it.

Moving on to the single hash (#) comments which are just skipped over by CoffeeScript. Again, this can lead to unexpected consequences.

For example, a straightforward if statement has a few lines of code:

unless A 
  blah blah

But if we comment out all of the lines inside of if, the whole thing will fail miserably at the compilation step (at least thank you for that, CoffeeScript!):

unless A 
  # b()
  # blah blah

Just by adding an empty else we can mitigate the failure:

unless A 
  # b()
  # blah blah

c() # the code continues here

Try this snippet yourself on

Last but not least, there is another CoffeeScript pitfall related to jQuery events that don’t propagate when the event handler returns false. Of course, CoffeeScript philosophy makes every function an expression (the last statement is evaluated if there is no return statement present).

b = ()->
  false # usually this result is less obvious and buried deep down in code
$a = $ 'input'
$ ()->
  console.log 'this happens all right'

$a.parent().click ()->
  console.log('this never happened')

Of course, in real life the b() function is not so obvious and it’s buried somewhere deep within Backbone and Angular model methods. And the event isn’t propagating up the DOM tree (return false). Therefore, we’ve lost the second event handler without even realizing t. Buyers beware of this elusiveness! :-)

Try the event propagation bug yourself on

This is the end of my list. If you know of any additional CoffeeScript idiosyncrasies, please send them my way. :-)

Further CoffeeScript reading:

Best Regards,
Azat Mardan
Microsoft MVP | Book and Course Author | Software Engineering Leader
Azat Mardan avatar
To contact Azat, the main author of this blog, submit the contact form or schedule a call at and we can go over your bugs, questions and career.

3 thoughts on “CoffeeScript Quirks

  1. Pingback: CoffeeScript FUNdamentals: The Better JavaScript

  2. Joshua Conner

    Placing parens over the function still does us no good. Look at this CoffeeScript code:
    a() if @model.get ('groupType') is 'radioGroupTabs'

    This works, though:

    a() if @model.get('groupType') is 'radioGroupTabs'

Leave a Reply

Your email address will not be published. Required fields are marked *