CoffeeScript woes

I recently wrote a piece comparing CoffeeScript, TypeScript and Dart.  For the UI component of Wellmo, we decided upon using CoffeeScript.  While this has been a great leap from JavaScript, we’ve had our share of setbacks.  Here’s a few issues that are good to know about when using CoffeeScript.

Fat vs thin

This one has definitely bitten everyone who has used CoffeeScript one time or another.  Keeping track of what this is pointing to and when you need to use the fat arrow => instead of the thin arrow -> is sometimes a tricky business.  You’re tempted to use the fat arrow always for simplicity, but then you’re paying a price in performance.

Accidental returns

CoffeeScript automatically returns the result of the last statement within a function, just like Ruby.  Personally I like this feature, but it has caused some surprises.  We use promises extensively, and when a function in a promise chain returns a promise, that promise is automatically added as part of the promise chain.

We’ve had a few cases where a function that shouldn’t have any meaningful return value accidentally returns a promise.  This in turn is inadvertently injected into a promise chain where it shouldn’t be.  This took a while to figure out, and is something to watch out for.  If a function does not have any meaningful return value, you may want/need to add a null on the last line to prevent accidental returns.

Almost-optional parenthesis

Another trait borrowed from Ruby is optional parenthesis.  While this is another feature I like in general, it is a poor fit for JavaScript, where functions are first-class citizens.  The problem is that parenthesis are optional, except if there are no arguments.  Without arguments or parenthesis, it’s a function reference, not a function call.  I can’t count the number of times I’ve been bitten by this one.

We’ve even considered mandating usage of parenthesis in all code, but I don’t really like such mandates either.

JavaScript woes

While CoffeeScript fixes many of JavaScript’s bad parts, many are still present and you need to be aware of them.  After all, It’s just JavaScript!  Just recently we discovered that a model that we thought contained a number actually contained a string, which was being automatically coerced.

Developing language

After using other languages, it came as a slight surprise that CoffeeScript is still a language in development.  We had a mysterious issue where the same code built successfully on some machines, but not on others.  We discovered that catching errors without naming the error was introduced in 1.6.3, while one of our developers still had 1.6.2.

Conclusion

Web development is transforming as we speak. There are a lot of altJS languages cropping up, all with their strengths and weaknesses.

Many of the problems I listed above are inherent of JavaScript, and not hidden because CoffeeScript is ultimately a thin conversion layer between the languages.  This is one of CoffeeScript’s biggest strengths and weaknesses.

I doubt we’ll be using CoffeeScript in ten years’ time, but at the moment it’s a very viable alternative.  You just need to be aware of the pitfalls.  Even with its shortcomings, I still consider it the correct choice for our application.

About these ads
This entry was posted in Coding, CoffeeScript and tagged . Bookmark the permalink.

5 Responses to CoffeeScript woes

  1. Pingback: CoffeeScript vs. TypeScript vs. Dart | Code for Hire

  2. Vilis says:

    Would you use CoffeeScript today, if you were starting an app from scratch?

    • Sampo N. says:

      For our current project, yes. I do believe it is a good balance of cleaner syntax, less noise, and hiding of JavaScript’s bad parts, yet providing full flexibility and power. But it’s by no means a perfect language (largely due to its heritage).

      For other types of projects I might consider other alternatives. See the end summary of the CoffeeScript vs TypeScript vs Dart article for some ideas.

  3. Do you think TypeScript has a brighter future than CoffeeScript? What about Dart? How do you think the future with be for the three languages you’ve reviewed in the past article?

    • Sampo N. says:

      TypeScript is an evolution over JavaScript. That’s why it has a much lower barrier of entry. I believe it may well pick up, especially if the ECMAScript standard progresses in its direction. However it will forever bear some of the icky remnants of JavaScript.

      Dart is a revolution. I’d really want it to succeed – from what I read (which was admittedly very little), it seemed like a very well-thought-out language. But it has a much higher barrier to get it rolling.

      I don’t see CoffeeScript’s fate as poor either. It’s filling a need. Maybe that need will disappear in the future, and people migrate to other languages. Or maybe CoffeeScript will also evolve into something new.

      Both TypeScript and Dart are verbose languages with a rigid syntax, made to be easily accessible. CoffeeScript is very terse. There’s a trend on trying to find more succinct languages, especially among expert coders.

      Consider Java and Scala: For a team of ten excellent coders, Scala may be more efficient. But if you have a thousand mediocre coders, I’d place my bets on Java. I think the development of this trend – one way or the other – will have a markable effect on what languages will be used in the future.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s