Coursekit is now Lore.
What’s the Story?

A Skeptic’s CoffeeScript Experience

When my co-founder Jim first came across CoffeeScript, I was skeptical. I had picked up all I knew about JavaScript through hard-earned battle scars. I had won the battle, but I wasn’t ready for a new one. It didn’t make sense to apply a new layer of abstraction, with its own warts and idiosyncrasies, on top of a language that had a lifetime of them on its own.

But its syntax *was* much closer to what I’d consider ideal, so like a good nerd, I gave it a run around. It’s been incredible.

My initial fears were way overblown.  I was worried that CoffeeScript would just complicate JavaScript, but it actually made it far simpler. From its home page, the golden rule of CoffeeScript is “It’s just JavaScript.” That fundamental underpinning (and its superb execution) keeps CoffeeScript from going too far. The JavaScript it produces is extremely readable, if a bit more verbose than what I would write myself, and I can very quickly match up every line of JavaScript to its corresponding line in the CoffeeScript. There’s no magic. While debugging isn’t as immediately straightforward, it was quick to adjust to, and hasn’t really slowed me down since the first couple of days. On top of that, I know that if CoffeeScript development slowed or stopped, I’d still be left with a maintainable JavaScript codebase. That’s huge.

But I didn’t like it just because it didn’t suck — CoffeeScript pulls off two huge things that it took some time to appreciate. The few semantic changes do a great job at polishing away the crappy parts of JavaScript (as Crockford put it, “Lisp in C clothing”) and leaving only the good parts. On top of that, the syntax makes programming in an event-driven model (the way that JavaScript is almost always used) far more delightful — CoffeeScript’s syntax fit the semantics of the language and real-world usage way better than JavaScript.

Like many people, my first experience with JavaScript was marked by a general feeling of “Why doesn’t this work the way it looks like it should?” Step by step, I progressed. There was a phase where I redeclared any variable I wanted to use in an inner scope in the outside scope, no matter how many levels down. There was the day I found jQuery. There were the few months when I declared that I had found the answer to everything: if it doesn’t work, wrap it in an anonymous function that calls itself.

Somewhere around that point in my journey, I read JavaScript: The Good Parts, and everything started to click. From then on, I actually liked JavaScript. It has a number of great things that are rare to find in popular programming languages: true first-class functions, dynamic objects, and a solid core set of data structures. Maybe more importantly — it’s everywhere, at least in the browser.

$(function() {
   
   $('.div1').click( function() {
       var self = this;
       $('.foo').click( function() {
           alert($(self).text());
       });
   });
});


This only slightly contrived example is actually pretty nice in Javascript, especially compared to similarly trivial examples in languages like Java. It’s still a bit clunky though — there’s a fair amount of extra syntax, and that downright unpleasant `var self = this;` CoffeeScript strips that out.

$ ->

    $('.div1').click ->

        $('.foo').click =>
            alert $(@).text()


In this example, there’s one big semantic change: the introduction of the fat arrow (=>). It binds the value of `this` at the point the function is declared, letting you kill the `var self = this;` in the JavaScript example, and pre-empting a whole class of potential bugs.

More than that, there are a few syntactic advantages. The two biggest changes in the example involve functions: the arrows (-> and =>) replace `function() {}`, and there are no parentheses around the arguments in function calls (like the calls to click). I think the lack of `function` is a huge win, and recognize that the use of significant whitespace and lack of parentheses come down to personal choice — in isolation. But in combination, these changes free functions to be the lightweight primitives they are.

In the end, we decided use CoffeeScript instead of JavaScript everywhere at Lore, and it’s one of the best decisions we’ve made. If this sounds good to you, we’re hiring.

— Dan Getelman, CTO (@dget)


  1. ideasandform reblogged this from techlore and added:
    Dan on why we use Coffeescript in our new tech blog. Lore
  2. techlore posted this