CoffeeScript – overrated?

There has been an interesting thread on Reddit with the title “DAE [Does Anyone Else] think CoffeeScript is ridiculously overrated?” [via @k33g_org]. This post provides some perspective on that opinion.

CoffeeScript is a modern version of JavaScript: Check out its excellent website for a quick overview of what it looks like.

• Completely new syntax: CoffeeScript comes with its own syntax that looks a lot like Python: it uses indentation instead of braces, parentheses and commas are often optional, etc.
• Improves JavaScript: CoffeeScript helps with many of JavaScript’s more difficult parts – inheritance, shorter function syntax with optional binding of this, etc.
• Compiled to JavaScript, statically. When you write CoffeeScript, there is an extra build step involved, before you can run your web application: you need to compile it to JavaScript. You will thus have to do your debugging in JavaScript, but extra emphasis has been placed on making the generated code as readable as possible. [2]

CoffeeScript is influential:

• Will be part of Rails. CoffeeScript will be shipped with Ruby on Rails 3.1.
• Influences ECMAScript.next. It can be seen as a field test of next-generation JavaScript features and informs the decisions made for ECMAScript.next. Especially Brendan Eich has mentioned it as a source of inspiration.

• Syntax. While I think that there are syntaxes that are prettier than the Java-inspired JavaScript syntax (Smalltalk and Lisp come to mind), it is what we have and it is not so bad that one cannot live with it. I don’t agree with the design choice of choosing a completely different syntax for an advanced version of JavaScript, because you now have to know two syntaxes: CoffeeScript’s for programming and, occasionally, JavaScript’s, for debugging. Obviously, there are people who hate JavaScript’s syntax and/or don’t want to stray too far from their favorite programming language. For those people, this is a feature, not a bug. I would have preferred a more JavaScript-ish approach where upcoming ECMAScript features are compiled to current-day JavaScript. This is what Google Traceur [1] does. Note that if JavaScript had macros, one could retrofit older engines with both new library functionality and new language features.
• Library versus language. Not all features have to be part of the core language. With JavaScript’s higher-order functions (functions/methods whose parameters are functions), libraries can do a lot. The following example shows that the language feature list comprehension is not much more beautiful than Array.prototype.map() plus shorter function syntax. This is CoffeeScript code that produces a list of square numbers:

      list = [1, 2, 3, 4, 5]
      squares = (Math.sqrt num for num in list)
  

  In JavaScript code (plus shorter function syntax), this looks as follows:

      var list = [1, 2, 3, 4, 5];
      var squares = list.map((num) -> Math.sqrt(num));
  

• Not everything is an improvement. We are obviously entering the realm of taste, but I don’t think all of CoffeeScript’s features are an improvement over current-day JavaScript [3]. For example, I like having to declare a variable via the var operator (soon to be replaced by the improved let operator), because it makes it explicit where you start using it and helps with catching typos.

• ECMAScript.next [4] will fix most of JavaScript’s shortcomings: modules (which are currently not in CoffeeScript), classes, shorter function syntax, etc.
• Paren-free JavaScript. Brendan Eich has suggested a more compact syntax for JavaScript called paren-free JavaScript [3]. It provides some of CoffeeScript’s conciseness, but without radically changing the syntax. The key insight is that parentheses are not necessary if an expression is bracketed by a keyword (such as if) and a brace. Thus, blocks for if and loops would have to be mandatory to enable this syntax, but that is what most style guides suggest, anyway.

      if year > 2010 {
          syntax++
      }
      
      for i in iter {           // i is a fresh let binding!
          frob(i)
      }
      
      while lo <= hi {
          let mid = (lo + hi) / 2
          // binary search blah blah blah
      }
  

• Compile CoffeeScript in your browser. There are two ways to run CoffeeScript directly in the browser:
  • Running CoffeeScript In-Browser

    One of the ways to run CoffeeScript (other than processing on the server or using the command line to pre-compile) is to run CoffeeScripts, directly, in-browser.

    This simply means that you can write coffeescript inside the HTML document. It has the disadvantage of being near impossible to debug as the running code will be encased in a very large javascript eval statement.

  • CoffeeMaker

    It runs on most modern LAMP servers (I use it on my localhost development server, XAMPP) and compiles CoffeeScript on the client but caches and stores it on the server.

• Firefox SourceMap [5] allows you to debug an input language that is compiled to JavaScript in its source code.

1. Google’s Traceur: compile ECMAScript.next to JavaScript on the fly
2. Translating CoffeeScript classes to JavaScript [examines the JavaScript generated by CoffeeScript]
3. CoffeeScript versus paren-free JavaScript [I compare the two approaches of syntactically improving JavaScript and rate CoffeeScript’s new language constructs]
4. ECMAScript.next: the “TXJS” update by Eich
5. SourceMap on Firefox: source debugging for languages compiled to JavaScript