Categories
Uncategorized

Three Months of CoffeeScript

coffeescript

Guest Post by Kamil Tusznio!

Kamil’s a developer at Shopify and has been working in our developer room just off the main “bullpen” that I like to refer to as “The Batcave”. That’s where the team working on the Batman.js framework have been working their magic. Kamil asked if he could post an article on the blog about his experiences with CoffeeScript and I was only too happy to oblige.

CoffeeScript

Since joining the Shopify team in early August, I have been working on Batman.js, a single-page app micro-framework written purely in CoffeeScript. I won’t go into too much detail about what CoffeeScript is, because I want to focus on what it allows me to do.

Batman.js has received some flack for its use of CoffeeScript, and more than one tweet has asked why we didn’t call the framework Batman.coffee. I feel the criticism is misguided, because CoffeeScript allows you to more quickly write correct code, while still adhering to the many best practices for writing JavaScript.

An Example

A simple example is iteration over an object. The JavaScript would go something like this:

var obj = {
  a: 1, 
  b: 2, 
  c: 3
};

for (var key in obj) {
  if (obj.hasOwnProperty(key)) { // only look at direct properties
    var value = obj[key];
    // do stuff...
  }
}

Meanwhile, the CoffeeScript looks like this:

obj =
  a: 1
  b: 2
  c: 3

for own key, value of obj
  # do stuff...

Notice the absence of var, hasOwnProperty, and needing to assign value. And best of all, no semi-colons! Some argue that this adds a layer of indirection to the code, which it does, but I’m writing less code, resulting in fewer opportunities to make mistakes. To me, that is a big win.

Debugging

Another criticism levelled against CoffeeScript is that debugging becomes harder. You’re writing .coffee files that compile down to .js files. Most of the time, you won’t bother to look at the .js files. You’ll just ship them out, and you won’t see them until a bug report comes in, at which point you’ll be stumped by the compiled JavaScript running in the browser, because you’ve never looked at it.

Wait, what? What happened to testing your code? CoffeeScript is no excuse for not testing, and to test, you run the .js files in your browser, which just about forces you to examine the compiled JavaScript.

(Note that it’s possible to embed text/coffeescript scripts in modern browsers, but this is not advisable for production environments since the browser is then responsible for compilation, which slows down your page. So ship the .js.)

And how unreadable is that compiled JavaScript? Let’s take a look. Here’s the compiled version of the CoffeeScript example from above:

var key, obj, value;
var __hasProp = Object.prototype.hasOwnProperty;
obj = {
  a: 1,
  b: 2,
  c: 3
};
for (key in obj) {
  if (!__hasProp.call(obj, key)) continue;
  value = obj[key];
}

Admittedly, this is a simple example. But, after having worked with some pretty complex CoffeeScript, I can honestly say that once you become familiar (which doesn’t take long), there aren’t any real surprises. Notice also the added optimizations you get for free: local variables are collected under one var statement, and hasOwnProperty is called via the prototype.

For more complex examples of CoffeeScript, look no further than the Batman source.

Workflow

I’m always worried when I come across tools that add a level of indirection to my workflow, but CoffeeScript has not been bad in this respect. The only added step to getting code shipped out is running the coffee command to watch for changes in my .coffee files:

coffee --watch --compile src/ --output lib/

We keep both the .coffee and .js files under git, so nothing gets lost. And since you still have .js files kicking around, any setup you have to minify your JavaScript shouldn’t need to change.

TL;DR

After three months of writing CoffeeScript, I can hands-down say that it’s a huge productivity booster. It helps you write more elegant and succinct code that is less susceptible to JavaScript gotchas.

Further Reading

This article also appears in the Shopify Technology Blog.

7 replies on “Three Months of CoffeeScript”

Hey, nice write-up. I’m a little puzzled, though, by the the claim

> it’s possible to embed text/coffeescript scripts in modern browsers

Last I checked, text/coffeescript wasn’t supported natively by any browsers; you have to use the coffee-script.js library, which uses Ajax magicks to load .coffee files. Perhaps that’s what you meant, but in that case you can drop the word “modern”; coffee-script.js works fine under IE6.

The problem with Coffeescript is that once you get used to it, it gets difficult to read plain JavaScript code since your mind has got into a certain pattern.

Trevor, you’re absolutely right. coffee-script.js needs to be included in order to run text/coffeescript scripts in the browser.

“Batman.js has received some flack for its use of CoffeeScript, and more than one tweet has asked why we didn’t call the framework Batman.coffee. I feel the criticism is misguided, because CoffeeScript allows you to more quickly write correct code, while still adhering to the many best practices for writing JavaScript.”

I don’t think your response addresses the naming issue. Perhaps it is 10x better with coffeescript, that doesn’t mean that it should be called Batman.oranges.

I don’t see the problem with NOT calling it *.coffee; should http://spinejs.com be spine.coffee? I haven’t learned coffeescript myself, but given that even Brenden Eich has shown interest in coffeescript, I think giving projects that use it flack for still using ‘js’ is a bit nitpicky. Entirely my opinion of course ;)

[…] Three Months of CoffeeScript — Global Nerdy Kamil’s a developer at Shopify and has been working in our developer room just off the main “bullpen” that I like to refer to as “The Batcave”. That’s where the team working on the Batman.js framework have been working their magic. Kamil asked if he could post an article on the blog about his experiences with CoffeeScript and I was only too happy to oblige. […]

This didn’t work for me:
coffee –watch –compile src/ –output lib/

I used this, which worked fine:
coffee –watch –compile –output src/ lib/

Cheers!

Comments are closed.