Arguments Against CoffeeScript
Kingsley W

In Defense of CoffeeScript

(for Meteor apps, at least)

Once upon a time, in The Land of Curly Brackets…

As someone who learned computer science fundamentals in “The Land of Curly Brackets” (C++), I may be risking blasphemy here, but screw it, I’ve never been much for dogma. Indentation- and whitespace-dependent languages are pretty, damn it. I guess I can’t claim total loyalty to C-like syntax because my engineering education did lead me to write a fair amount of MATLAB code, but nevertheless, I do have a soft spot for these languages that curly-bracket loyalists love to hate. And yes, JavaScript is especially ugly. Is CoffeeScript the answer to pretty it up?

The Good, the Bad, and the Coffee

As a newcomer to CoffeeScript, I see its potential (for good, but also bad). The implicit scoping issue frightens me, and there are a few other pitfalls to be aware of too. The good parts, however, seem incredibly useful. For example, defining large object literals is so much easier in CoffeeScript — I don’t have to worry about forgetting commas when adding or removing properties. When objects or functions get large, I do sometimes wish there was an explicit closing keyword like “end”, but you can always just throw a “# end functionName/objectName” in there, or explicitly use the opening/closing brackets, or maybe it’s time to refactor your function because it’s doing too much. ;)

Go Pre!

I see CoffeeScript as a JavaScript preprocessor in the same way that Less, Sass, and Stylus are CSS preprocessors, and Jade and Haml are HTML preprocessors. Yes, you will have to deal with the generated CSS/HTML output at some point, but in my case, I still much prefer writing styles in Stylus and markup in Jade when I can. The great thing about Meteor is that we can use all these tools wherever they make sense, mixing and matching on the fly. Write one file in JavaScript and another in CoffeeScript, write some stylesheets in CSS and some in Less and some in Stylus if you want to (not sure why you would, but you could). And fully Meteoric Sass support will be coming soon (LibSass is quickly closing the Node/Ruby gap)!

The Language Gap

I pride myself on being somewhat of a generalist, so the “having to know two languages” argument doesn’t bother me much. And as I said above, I see CoffeeScript as more of a preprocessor, not a language. Also, I seriously doubt anyone comes to CoffeeScript without first knowing some JavaScript. That being said, writing all your server code in one language (C#.NET in my experience) and then all your client code in JavaScript does suck. It always felt very clunky, and I hated it. As web developers, we’re all too familiar with this. With Meteor, the experience is vastly superior, of course. There’s far less context switching when writing client and server code, and I don’t see CoffeeScript as being a hinderance here. Use it where it makes sense, and don’t use it where it doesn’t. In his blog post, Ry Walker compared using CoffeeScript to using Underscore: “For the same reason I use Underscore, I use Coffeescript. My code is more readable.” Nick Wientge made the argument that he often ends up having to add “explicit return statements, parentheses and curly braces to make [his] CoffeeScript more readable — which kind of defeats the entire purpose of writing CoffeeScript in the first place!”. Fair enough, but like I said above, use it where it makes sense. So maybe CoffeeScript isn’t always more readable, but it’s still damn useful (like Underscore). Nick also made the argument that when you inevitably have to write some JavaScript, “you will suck at it”. So does using CoffeeScript make you a shitty JavaScript programmer? I’m no JS ninja, but I’d say no, as long as you treat it like what it is — a tool to make writing JavaScript easier.

The Plot Thickens…

Looking ahead, things might get even more interesting once more transpiled languages are supported in Meteor. Imagine writing code in Dart or even Python/pyjamas or Ruby/Opal and having Meteor automatically handle generating the JavaScript for you. Maybe that’s a stretch, but if I’ve learned anything about web development over the years, it’s that trying to predict what’s coming next is an exercise in futility (but it can still be fun!).