One of my favourite discoveries of late has been Coffeescript. If you’re not familiar with it, Coffeescript is a simple language that compiles down to javascript, in theory saving you a reasonable amount of developer time. My first introduction to it was back when it was a rubygem but at that point I never really put in the effort to learn it until Chris Lloyd did a rocking presentation on it at Railscamp 7 in Canberra. Fresh with inspiration from actually seeing it in action, I decided to take the time to write some code and see how well it fits in with my workflow.

Coffeescript + Rails

From the way I see it, Coffeescript fits in rather well with the ruby ideology – it has syntax that is reasonably familiar to ruby developers (python / haml like indentation, ?-style calls to check for existence, shorthand syntax for anonymous functions) and more importantly it sits well for writing code similar (but not the same) as to how you would in ruby.

Coffeescript itself is now bundled as a javascript library (meaning you can either run it on node via the coffee command or, if you’re feeling really adventurous, you can embed coffeescript in to pages within a custom script tag and the coffeescript compiler). But, for most developers, having an intermediary layer within your application that handles this transparently for you makes a lot more sense.

The predominant options out there when I first start doing this (keeping in mind I was working on Big Help Mob, a Rails 3 project) were:

• CoffeeHamlFilter – A haml filter that makes embedding coffeescript within a page easier.
• Rack::Coffee – A piece of Rack middleware for transparently compiling coffeescripts to javascripts and serving them.
• bistro_car – a Rails plugin that handles bundles of coffeescripts (and converting them to javascript) but that has direct integration within rails.

Of these three, I ruled out CoffeeHamlFilter early on (since it embed the coffeescript directly into the page – something I didn’t want) and Rack::Coffee because I wanted something more deeply integrated in to rails (to a degree). This left bistro_car, the most popular choice of the three. Unfortunately, bistro_car seemed inflexible for the use case I wanted (namely, transparent compilation like Rack::Coffee but that played nicer with Rails) and more importantly it was a pain in the ass to get correctly working with Jammit which has become my asset packaging plugin of choice.

Introducing Barista

With all of this in mind, I set off to write my own plugin that fit a set of criteria, namely:

• Transparent compilation – the views shouldn’t need to know about coffeescripts, they only need to work with javascripts.
• Separation of coffeescripts from javascripts like bistro_car (e.g. coffeescripts in app/coffeescripts).
• Plays well with jammit (namely, take the compass / sass approach – Option to compile all files as part of my deploy, automatic compilation during development before each request).

The result – Barista – is a simple approach that is built around Rails 3 (although it could feasibly be ported to Rails 2.3 if needed) and supports these plus more. By default, it will take coffeescripts nested under app/coffeescripts and compile them into their equivalants in public/javascript (e.g. app/coffeescripts/x.coffee would become public/javascript/x.js).

More importantly, as I went along, I realised there was one feature I really, really wanted that as far I know none of the others had – Frameworks / packagable coffeescripts. So, as a part of barista, you can include compass-like frameworks in a gem (such as BHM Google Maps and Shuriken, two of my javascript libraries that take is approach) which makes adding a javascript library to your app a simple line in your Gemfile away.

If you’re interested at all, I suggest checking out either Barista’s GitHub page or it’s project page here on my blog. It tries to use sane defaults for most things and should just work out of the box.