Why I won't use CoffeeScript (sadly)
Update: I might change my mind now. Why? I just discovered a js2coffee converter. Furthermore Denis Knauf told me about a CoffeeScript.eval
function. And as Denis said: “it is time to use Coffeescript as a javascript with Ruby-like syntax not a Ruby-like programming language”.
tl;dr: I would have loved to program client side using a Ruby-like syntax. But in the end, CoffeScript raised more disavantages than advantages.
Recently I read this entry on HackerNews. The most upvoted comment praised (within other) CoffeeScript. Recently I used a lot of javascript. After trying Sproutcore, Cappuccino, looking at backbone.js & javascriptMVC, I’ve finally decided to make my own minimal javascript MVC framework.1
I had to fight the horrible syntax of javascript. It was like experiencing a back-in-time travel:
- Verbose Java-like syntax,
- Strange and insanely Verbose Object Oriented Programming,
- No easy way to refer to current instance of a class (
this
doesn’t work really well), - etc…
It was so annoying at a point, I had thinked about creating my own CoffeeScript.
I’d finished a first draft of my MVC javascript framework. Just after I learned about the existence of CoffeeScript, I immediately created a new git branch to try it.
Here is my experience:
- I had to install
node.js
and usenpm
just to use CoffeeScript. It wasn’t a big deal but it wasn’t as straightfoward as I expected either. - Existing javascript file are not coffee compatible. I had to translate them by hand. There were no script to help me in this process. Thanks to vim, it wasn’t too hard to translate 90% of the javascript using some regexp. The
--watch
option of coffee was also really helpful to help in the translation. But I had to write my own shell script in order to follow an entire directory tree. - An unexpected event. I made some meta-programming in javascript using
eval
. But in order to work, the string in the eval must be written in pure javascript not in coffee. It was like writing in two different languages. Really not so good.
Conclusion
Advantages:
- Readability: clearly it resolved most of javascript syntax problems
- Verbosity: I gained 14% line, 22% words, 14% characters
Disadvantages:
- Added another compilation step to see how my code behave on the website.
- I had to launch some script to generate on change every of my javascript file
- I have to learn another Ruby-like language,
- meta-programming become a poor experience,
- I must convince people working with me to:
- install
node.js
,npm
and CoffeeScript, - remember to launch a script at each code session,
- learn and use another ruby-like language
- install
The last two point were definitively really problematic for me.
But even if I’ll have to work alone, I certainly won’t use CoffeeScript either. CoffeeScript is a third party and any of their update can break my code. I experienced this kind of situation many times, and it is very annoying. Far more than coding with a bad syntax.
Digression
I am sad. I wanted so much to program on Web Client with a Ruby-like syntax. But in the end I think it is not for me. I have to use the horrible javascript syntax for now. At least I would have preferred a complete ruby2js
script for example2. But I believe it would be a really hard task just to simulate the access of current class for example.
Typically @x
translate into this.x
. But the following code will not do what I should expect. Call the foo function of the current class.
->
class MyClass
foo: ->
alert('ok')
bar: ->
$('#content').load( '/content.html', ( -> @foo(x) ) )
# That won't call MyClass.foo
The only way to handle this is to make the following code:
->
class MyClass
foo: ->
alert('ok')
bar: ->
self=this
$('#content').load( '/content.html', ( -> self.foo(x) ) )
Knowing this, @
notation lose most of its interrest for me.