coffeescript

Three Months of CoffeeScript

by Joey deVilla on November 7, 2011

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:

Meanwhile, the CoffeeScript looks like this:

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:

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:

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 comments }

Salmagundi for Monday, August 22, 2011

by Joey deVilla on August 22, 2011

Welcome to another Salmagundi — a selection of some interesting techie stuff on the web!

In his article Your Code is My Hell, all-round Ruby/Rails guru Avdi Grimm warns Ruby and Rails developers about a creeping exceptionalism that has been rearing its ugly head as of late. Many Ruby/Rails developers seem to be under the impression that simply because Ruby and Rails do a lot to make programming easier, they can simply ignore things like good coding, good object design, design patterns and the SOLID principles and all those other practices and disciplines that good coders follow and exercise. Ruby’s a great programming language and Rails is a great web development framework (and I’m quite glad to return to them), but they’re not a free pass to code carelessly!

Nick Quaranto from Thoughtbot explains why he loves CoffeeScript, by way of the movie 300, in CoffeeScript: Spartan JavaScript. “Writing JavaScript properly, and in an OO manner, requires you to be verbose,” writes Quaranto. “What I like best is that CoffeeScript is simply…spartan.” He covers the good as well as the bad (but it’s mostly good). If you’d like to try it out, visit the CoffeeScript site to get started.

Here’s another one from Avdi Grimm (he’s got lots of good suggestions — you should check his blog regularly if you’re a Ruby/Rails developer): The Procedure/Function Block Convention in Ruby. He’s got a clever idea for when to use “curly bracket” blocks (he suggests to use the for functional blocks) and when to use “do…end” blocks (he says to use them for procedural ones.

And finally, if you use Git, you’ll want to read Benjamin Sandofsky’s article, Understanding the Git Workflow. “If you’re fighting Git’s defaults,” he writes, “ask yourself why.” He suggests that your workflow should be:

  1. Create a private branch off a public branch.
  2. Regularly commit your work to this private branch.
  3. Once your code is perfect, clean up its history.
  4. Merge the cleaned-up branch back into the public branch.

This article also appears in the Shopify Technology Blog.

{ 0 comments }