While I agree with some others here that calling it a JavaScript framework is a bit of a stretch, there are legitimate reasons to do this in coffeescript as opposed to javascript.
In particular, the Rails-y way of doing things requires particular concise classical OO abstractions that are difficult to provide in a pure prototypal JavaScript way without introducing your own class library (which there are far, far too many of).
For example, if you look at the definition of the App.User here: http://towerjs.org/models, trying to do the same kind of thing where you can quickly declare a class that extends a base class and adding things to it can become quite awkward.
You'd have to manually construct the prototype chain (or use the library-specific class DSL) and have to repeat the class name in order to call the "field" method there.
TL;DR Rails uses mixins and classical OO extensively, CoffeeScript facilitates this, JavaScript makes it difficult.
Thank you for taking the time to explain that, I hadn't even thought about it like that, the venom in some of the other responses to people who are skeptical of coffeescript is really alarming.
In particular, the Rails-y way of doing things requires particular concise classical OO abstractions that are difficult to provide in a pure prototypal JavaScript way without introducing your own class library (which there are far, far too many of).
For example, if you look at the definition of the App.User here: http://towerjs.org/models, trying to do the same kind of thing where you can quickly declare a class that extends a base class and adding things to it can become quite awkward.
You'd have to manually construct the prototype chain (or use the library-specific class DSL) and have to repeat the class name in order to call the "field" method there.
TL;DR Rails uses mixins and classical OO extensively, CoffeeScript facilitates this, JavaScript makes it difficult.