Node with benefits: Using Coffeescript in your stack
Coffeescript is more than just an elegant interface to javascript, it’s an effective and productive tool that helps keep a tidy and maintainable codebase. Here are some benefits I found using it specifically with Node.
Using coffeescript with Node is not a trivial statement. Oddly enough, while coffeescript was widely embraced by the Rails community a while ago (becoming the default interpreter for javascript on Rails 3.1), Node’s community is somewhat holding back. TJ Holowaychik, one of Node’s leading open sourcers and the creator of the Express framework, posted this reaction gif a couple of weeks ago, saying a lot.
The current debate about whether to use coffeescript or not revolves around opinions of it’s role and future in light of the upcoming ECMAScript 6 release. Also, native javascripters who didn’t take a deep dive into Ruby’s syntax may find coffeescript unfamiliar and stay away from it. Be that as it may, and after taking the Ruby plunge a few years back myself, I personally found great affection for coffeescript. Ruby (and Rails) have a great syntax which I adore, and javascript has great capabilities which I cherish, so why don’t we conjoin them together? I’m a strong advocate.
However, as my title suggests, in my point of view coffeescript is more than just a pretty wrap for javscript. As my Node projects evolved and got more complicated, I actually found coffeescript a great comfort and help in supporting my codebase, keeping it lean and readable, faster to produce, and — naturally —beneficial in avoiding some of javascript’s more hideous quirks.
Here are some features I really like, and example on how I utilize them in my Node environment:
Indentation & Avoiding “Callback Hell”
Although a little tricky to grasp at first, one of the features I like most about coffeescript is indenting instead of bracing, or to be more specific, avoiding the repetitive unattractive `function(){}` (or `if {}`) declarations that turns any code into an unreadable mess. This argument is reinforced in Node because of the wide use of callbacks in the event-driven paradigm.
“Callback Hell” is a terms used by developers (and criticizers of Node) to describe a flow that consists of multiple, dependent callback functions. In vanilla javascript, it can quite easily turn into something like this:
There are several solutions to this issue, although Promises and queues being popular and widely used, and ECMAScript 6 being the around-the-corner implementation (not stable yet), I personally prefer avoiding the use of dispatched promises or specially designed solutions for callbacks as much as I possibly can, in effort to keep my code as native and slim as possible. In this case I found coffeescript’s syntax really useful. Indentation and the shorthand for functions can now turn the code above (once consider a ‘hell’) into this a graceful and readable flow (could be considered a rainbowy-waterfall of teddybears), without using and third party negotiators. This real-world code example is clear, attractive, and easy to read and maintain.
Classes and Instances
Javascript’s approach to classes, instances and inheritance is somewhat throwing. Everything is possible, with several different styles even, but all in all could be considered awkward in comparison to other object-oriented languages. Enters coffeescript and it’s more standard, approachable interpretation for declaring classes, which comes very useful specifically in Node’s backend logic-heavy environment. Instead of declaring a class how we normally do in javascript, we can now achieve the same effect in a more traditional, well organized manner, like so:
Elegant bindings, Loops & Literal operands
Coffeescript is also doing us a great service when it comes to plain scripting and readability. Using it in your Node project will swiftly turn your code into an elegant codebase. If statements could be declared on the end of a term, turning messing one-lines conditions into a sentence. Operands could turn verbal to further enhance that effect. Scope binding, one of javascript’s most prominent characteristics, could be easily achieved and implanted. Loops also turn from hideous, over-blown blocks into elegant one liners. Combining all of these together in an holistic backend environment transforms your codebase completely.
The Bad Parts & a Conclusion
Like everything in this world, coffeescript also has some bad parts. I won’t elaborate on them, others do it nicely for me and anyone who chooses coffescript should be aware of them, however I do need to say this: although coffeescript is a graceful and even an imperative addition to your Node stack, it is absolutely vital to be fluent in vanilla javascript before turning to it. There’s a lot in stake when it comes to mastering your primary programming language, and in particular understanding javascript and it’s unordinary nature.
As to the question whether or not to use coffeescript due to the community difference of opinions, I have come to this personal conclusion: I like and benefit from coffeescript, therefore I will continue using it and contributing to it on private projects. When it comes to open source projects, I have to respect the community general state of mind (keeping in mind coffeescript really is more appealing to developers who may have had experience with Rails) and therefore keep it native and vanilla.
Coffeescript is a great tool but it should be used out of choice and appreciation. I recommend you give it a try in your next Node project, you might not go back.
