Or: How I learned to stop worrying and love the drip.
It didn’t work.
Young coffee-script was cute, but in its infantile stage the energy needed to bend it to practical ends far outweighed any savings it seemed ready to provide. That was 2011, and oh! How wrong I was.
For the prosecution, the case against CoffeeScript usually come down to four points:
- Coffeescript is hard to read
- It requires an extra compile step
- It’s hard to debug
CoffeeScript is designed so that nearly anything can be used as an expression–a feature that’s as handy as it is an enormous enabler of bewildering code. I doubt I’m alone in confusing the
in comprehension (iterate over array) with
of (objects), and I’m pretty sure there are clearer ways to express conditions than:
doctorGoes = if oranges == apples then true else fruit == 'apple'
Still, many of these expressions have their own utility, and CoffeeScript is far from alone in allowing developers to write obfuscated code.
It’s true: browsers don’t speak coffeescript. But neither do they speak SASS, LESS, or minify scripts on their own. In this day and age, it’s hard to imagine a build process that doesn’t involve at least one layer of asset preparation. Coffeescript tasks for grunt–or better yet, [Yeoman]–turn compilation from a persistent annoyance into an utterly forgettable experience.
Even with compilation reduced to a non-issue, there’s still the case
Isn’t this a great time to start considering how preemptive tests might help reduce the need for reactive debugging?
class Reason because: (@thatsWhy) -> @ whyCoffeeScript = new Reason whyCoffeeScript.because("It's awesome").thatsWhy
That’s right. Just defined an extensible function, added an accessor to its prototype, and chained it all together quicker than Tim Horton can dial up a cup of joe.