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
NayaRead shows a summary and links to the original article. The full article is hosted on shopify.engineering.