Sunday, August 26, 2012

Is CoffeeScript better than Ruby?

If you are subscribed to our Arkency newsletter (we send an email every week or two with some interesting links and our comments), you probably noticed that there is an ongoing debate in our team - whether CoffeeScript (actually JS) has a good standard library.

I have recently watched an interview with DHH about his opinions on Single Page Applications.

DHH was explaining why they don't go the SPA way with their new 37Signals applications. They chose to generate JS and HTML on the backend and send it back to the client.

One of the DHH's arguments was that they prefer the Ruby stack (with Rails) than the experience of writing CoffeeScript application, with the server being just for JSON API.

Overall, I think that DHH makes some good points, but I don't agree with the assumption that it's better to work with the Ruby stack than with CoffeeScript. Sure, the patterns are not so mature as with a typical Rails app, so sometimes it takes more time to do the same thing, however their approach of sending JS is also not the most trivial one and it creates a complex architecture, IMO.

First, the syntax of CoffeeScript is better to me, than the Ruby syntax. This is subjective and I'm not expecting everyone to agree. To me, it's enough that the code is mostly shorter while still very elegant.

Second, the libraries. Yes, JS stdlib is almost non-existing. It's almost always better to avoid the existing stdlib and rely on sugarjs or underscore. Ruby is winning here. Now. With the growing JavaScript communities, we'll see a huge improvements very soon. The sugarjs library is already awesome and I don't feel I'm sacrificing anything by using it, compared to the Ruby libs.

You can improve the libraries, but it's hard to improve the syntax.

I may agree with DHH, that the SPA environment is not yet at the same level as Rails is now. Even DHH says that the situation happening with JS MVC is a huge shift. In my opinion (and not only mine), we see a revolution that can be only compared to Rails in 2004-2005. Back then, Rails also wasn't that mature, but we were able to use it and have a really well working applications (my first production Rails app was released in April 2005 and was used by hundreds of users every day).

Back to the title dilemma. Is CoffeeScript better than Ruby? 

We need them both. The trend of SPA will be growing and we can't use Ruby there. On the other hand, it's not easy to use CoffeeScript on the backend (nodejs based solutions are nowhere near the stability of Ruby solutions) and Ruby is a great choice in there. In most of the apps that I'm currently working on, I spend like 80% of my time with CoffeeScript on the frontend and 20% on Ruby on the backend. That's my answer :)


Donald Parish said...

Is ClojureScript better than CoffeeScript? After using Java, Ruby, I prefer Clojure to have single language for server and client, with the power of the Java libraries.

Andrzej Krzywda said...

Hi Donald,

ClojureScript is definitely on my list of things to try out. I'm not against FP, but one of the reasons it may not get that popular as Coffee (we will see, I have no idea) is that Coffee gives many people a more familiar environment - classes, objects, etc.

Chris Nicola said...

It seems pretty strange to try to compare the Coffeescript and Ruby languages when what it seems like you are really comparing here is the rich/smart-client approach of the JS MVC/MVVM frameworks vs the more server-side heavy approach of rails, django and .NET MVC

My own experiences with JS MVC frameworks has been pretty poor. Saying that the ecosystem is just immature is an understatement. So maybe they do get better and maybe there is a rails-like revolution that happens in the future, but that maybe isn't here yet and may never be. For me, none of that justifies hitching my wagon to these things today.

Today I follow the "rails-way" *mostly* (I don't use UJS much, and don't agree with sending JS responses) I also use Coffeescript for all my Javascript needs. I love both Ruby and Coffeescript as languages and I've found a way that they can both live harmoniously in my web development without any need to bring JS MVC frameworks into my life.

The bottom line is if you are choosing between these two very different paradigms based on a preference for Coffeescript or Ruby then I'd say something is wrong with that.

Andrzej Krzywda said...


Thanks for your comment!

"The bottom line is if you are choosing between these two very different paradigms based on a preference for Coffeescript or Ruby then I'd say something is wrong with that."

That's exactly the point.

Many Ruby developers choose to stay with the monolithic approach (no separate frontend) for the reason of not having to learn new technology stacks.

I chose to go the SPA way not because I love Coffee so much (I didn't when I made that decision), but because it makes much more sense from an architecture point of view.

I understand that some people worry whether the JS ecosystem is mature enough. After being involved in about 20 small-medium-size SPAs I can say it's mature enough.

This is my message - "we are ready to work with SPAs and a new technology stack, it's mature enough".

Anonymous said...

CoffeeScript is the worst thing to happen to JavaScript since the name was changed from the original "LiveScript". Can we please stop butchering JS and just accept it as a first class tool in the developer toolkit?

While CoffeeScript does give us some shortcuts and additional options, they do come at a great cost. CoffeeScript eliminates the need to: 1) know JS syntactical rules and conventions (CoffeeScript syntax is Python-esque), 2) "think" in JS (which is a great and extremely flexible paradigm), 3) gives novice developers a false sense of confidence given that the outputted/transcompiled JS is far more difficult to debug since the developer did not actually write it. Debugging CoffeeScript is a terribly intensive labor that requires a high level of native JS expertise. 4) Complexity. Calling functionality written in CoffeeScript from a plain JS can problematic and additional development rules need to be set to deal with this. Not to mention the command-line steps that are added to the normal workflow...

I.e. - I would not use CoffeeScript in an Enterprise environment for anything other than quick prototyping. Any decent JS developer can avoid creation of memory leaks or accidental closures (Which I think is the true purpose of this Closure Compiler toy).

But more importantly, on what planet does it make sense to compare CoffeeScript to Ruby?